Whats in a firmware? (Controller VS Controller)

[mcdanlj (Michael K Johnson)]

@RFLULLING

I see on the Laser side, Ruida and M2. What else is there? I would like to expand this.

The K40 Intro linked from the top bar talks about this a bit. Most CNC controller hardware can be used with a laser, and controllers that can run one of the open source firmwares that speak gcode are released faster than we could maintain a list… But the K40 Intro definitely lists several that are purpose-built for controlling lasers.

@RFLULLING

-I have read a post conversation by the Admin where M2 was described as little more than a direct slave. Ruida was described as closed source all in one stand alone complete with image processing and gcode extrapolation. Does this sound about right?

There’s more than one admin, but… @Tatarize who wrote Meerk40t has a video that explains the M2 nano in great detail. The M2 takes direct stepper commands. In 3D printing, Klipper has this kind of architecture, and now Marlin also has a direct step mode which can be driven by step-daemon.

Ruida controllers have a proprietary protocol that has been reverse-engineered (by, or partially by, @Tatarize as I understand?). Ruida controllers do not process gcode.

@RFLULLING

-I have read that GRBL, for the most part is like M2 on the laser side, being a slave.

I think that “slave” is being over-used here, and would like to suggest that other terminology might be clearer.

• M2 Nano has the computer sending direct motion controls to the stepper motor. It’s almost the same as old CNC designs that had the stepper driver controls wired directly to pins on the parallel port (remember those?) but connected via USB and using a very very simple protocol.

• gcode is a much higher level language for describing movements. It is well over half a century old and is the industry standard for CNC motion control. A gcode interpreter has a lot of leeway to interpret the gcode in a way that matches machine constraints. For example, it might know the maximum acceleration the machine is capable; a machine might be stationary, then be given a command to move to a new location in two or three dimensions at maximum speed, and it might apply acceleration limits separately in each of three dimensions to make the move. Different implementations have different capabilities; for example, early 3D printers used firmware that didn’t implement the G2 and G3 arc commands because all the modeling tools broke shapes down to small straight segments anyway; recently, as fast 32-bit controllers with a lot of processing ability and memory have become common, controllers have implemented G2 and G3 arc commands and slicers have started to use them.

• Mach 3 is control software that runs on a PC and expects to do direct stepper control. Mach 3 (and 4), as well as the nearly ubiquitous LinuxCNC, interpret gcode and send direct stepper control commands. In the early days this was typically done with the parallel port (see above) but now is often done via USB or ethernet. So this is conceptually similar to M2 Nano but utterly different in implementation and typical purpose. (These controllers are often used to drive industrial milling machines, for instance.)

@RFLULLING

-GRBL seems to come in many versions. I have not found a specific source, a developer home page. I would like to understand better about this firmware before discounting it. Also what exactly is its most advanced form? Some day it doesn’t work on 32bit, and other places I have read it does?

grbl is canonical for grbl and was the origin of many open source firmware implementations; some were just porting it to new hardware, like @cprezzi’s grbl-lpc and Bart Dring’s Grbl_ESP32, and others have gone on to live a life of their own, like the Marlin firmware primarily used on 3D printers.

Relatively recently, grblHAL seems to be the “2.0” of grbl development that is unifying support for many hardware architectures in one source code base. This includes 16-bit and 32-bit architectures.

@RFLULLING

Would I be mistaken in thinking that Laser based controllers are specialized for use in laser systems only? But that a CNC controller can be reconfigured for used with a laser also, just as it can be reconfigured for use with just about any tool head, spindle or router?

That’s a good start. There’s overlap; you can have a CNC controller with labeling covering use for laser and other domains.

@RFLULLING

Developers like Duet and Marlin seem interested in becoming a jack of all, master of none. Allowing users to operate just about any kind of configuration, be it Laser, Pen, Knife, Spindle, Router, or even multi head 3D tooling:

It’s clear that Marlin development is primarily driven by 3D printing. That said, laser control is much simpler than 3D printing control.

@RFLULLING

32bit debate:
Obviously a 32bit controller if set up right can be faster, have massive buffers, and other advanced built in tools. But one that I have not seen much conversation over, the drivers. I guess the old school drivers are enough for most, or maybe the market moves slower in CNC? Meanwhile in 3D printers we have TMC5160, a nice 60V 20A driver that puts most others to shame in term of capability like Silent Step and micro step extrapolation to 128. The catch is that it needs a 32bit controller. I think there are some intrepid users who have done some advanced things with these chips at the hardware level. But most of us aren’t that good.

32bit isn’t really a debate any more…

The TMC controllers have taken the world by storm, it is clear. The connection to 32-bit is tenuous, probably it’s just calculations to take advantage of 128-way microstepping… But that hardly matters because there is very little reason to get a 16-bit controller at this point. 32-bit controllers are cheap now.

@RFLULLING

-So far I only know a handful of controllers that can out support these drivers, and mostly plug and play.
Do you know of any?

“these drivers” meaning TMC? There are lots and lots of controllers, and at least many of the TMC chips can still be driven by step/dir/enable signals and were even produced to be pin-compatible with some prior chips, but they also enable a serial protocol connection that requires explicit firmware control, and plenty of firmware supports that.