I had this thought written out on a comment in a separate community but

(Dat Chu) #1

I had this thought written out on a comment in a separate community but I didn’t post it because I would like to get your input on the matter. I feel that Chilipeppr is the right solution to move the current CNC state-of-the-art forward. The reasoning being:

Trying to do everything on G-code is a bad idea. It’s like insisting on writing an application in assembly. It will be super fast when you get it done but machine time is cheap and human time is expensive. Buy a $500 computer and it will crank out all the translation you ever need.

Trying to do everything (web server, gcode translation such as caming, rendering, interface with hardware, …) locally on tiny machines (Rpi+/BBB) is a bad idea. You most likely have a machine that is capable of running a CAD program. Use the same machine to run a JS front end like Chilipeppr and all the heavy lifting is done. Let the Rpi and BBB spend its computational resource interfacing with the controller board (e.g. Arduino, shields, tinyg, …) and provide realtimeliness.

Am I way off on my stance on the matter? What is it that Chilipeppr + TinyG cannot do that LinuxCNC (and other LinuxCNC on RPI/BBB) can do?


I believe that trying to shove a huge stack onto an embedded system is simply not the way to go. I also think we should not have tiny 16-bit/32-bit processors do more than they need to because it’s too painful.

I think more of the logic should move upstream to a full-fledged powerful system like your laptop/desktop and a super easy-to-code environment like the browser. Make the embedded device run the most barebones app you can muster. Don’t try to put a full stack on a Raspberry Pi even Have it be barebones. Put the heavy full stack in the browser.

I agree with you that human time is the most expensive thing in the equation. Hardware is cheap. Coding for browsers is 20x cheaper than coding for embedded systems.

Case in point, you want to do a drag knife on the A axis that follows the angle of the Gcode. If you have the firmware do that or the LinuxCNC stack do that, you are ending up with a custom solution for that specific platform. This almost means that G2/G3’s shouldn’t even be done on the firmware. For you to achieve your drag knife you’ll need to know line by line angles and calculate them. I think all of that should be done at the browser layer, where a simulator can show you the run, and then you simply send down small little G0/G1 movements on the XYZA.

AND, by doing this in the browser, your amazing drag knife widget can be used by everyone regardless of controller/firmware/raspi/BBB/etc. It truly finally is an operating system and we’ll start to get better tools from the community. We don’t have good tools yet. Why isn’t there a drag knife app yet? Why isn’t there a pick and place yet? It’s because it’s really hard to write those and not enough momentum from any one platform. By getting one platform, we’ll have the critical mass where a developer finally wants to do it.

ChiliPeppr represents the platform that is the best model given today’s powerful desktop/laptops and the power of the browser (which 2 years ago wasn’t ready). Make the final leg into the CNC controller be as small and simple as possible. Ala, Serial Port JSON Server.

(Dat Chu) #3

I fully agree. I wonder about real time flow control. Let’s say I want to make my machine 6 axis by cobling together two 3 axis controller. Wouldn’t the buffer require some form of real-time support?


We’ll have to figure out the real-time stuff. I have a need for real-time as well. I think talking to two serial ports at the same time is interesting and will solve lots of uses cases, but i need pulse control on my lasers and when the pulse fires i need to time it just right with the CNC move. One thing i’m looking at is to have the hardware have a link in those cases. Maybe an Arduino watches something on the CNC controller. I do know that TinyG has the upcoming Kinen interface and the v9 boards support MISO/MOSI with 2 Chip Selects so that could be a way to queue up a command on an Arduino and then execute it the moment a Chip Select is hit.


In terms of 6 axis, have you looked at extending TinyG? That supports additional axes. I think if axes truly are realtime with Gcode, that’s the simplest solution. If it’s other real-time stuff the solution is a work in progress.


In thinking more though, it could be possible to have two Serial Port JSON Servers talk to each other and have the next command queued and trigger them at the same time, but that still feels like it could get mushy and hard to code. A master/slave model feels not bad. There’s also the idea of syncing clocks and asking a command to be triggered at an exact clock cycle. Seems hard to code though.

(Dat Chu) #7

My first reaction to supporting 6 axis is also to have a controller that works.TinyG is definitely enough for my purpose of cutting with a knife :).

The issue with real-time is indeed a hard one if we want <100ms lag. Hitting the network would then become impossible. MISO/MOSI seems like a solution worth exploring. Anyway, off to test out my Go Scale on a real machine now :).