Benefits of Ruida controller?

As I window shop for laser cutters, I keep seeing Ruida controllers come up. The main technical comparisons I see for Ruida are with M2nano, not with a gcode controller. I haven’t found a technical comparison between Ruida and one of the open source gcode controller. Obviously the protocol is different; Ruida is proprietary and gcode is not. But what are the differences in capability?

A Ruida controller is based upon a DSP chip. It is miles ahead of a Gcode controller in terms of capabilities. It can engrave at a much faster rate, has built in overscan adjustments, can run headless, can connect via ethernet or USB, just to name a few things. I would highly recommend getting a laser with a Ruida DSP controller. Stay as far away from the M2 Nano as possible, it is the worst of the controllers out there (I know @Nedman uses one, but he is a masochist…lol).

1 Like

There are gcode boards that can run headless and can connect by usb and/or wifi and/or ethernet. (E.g. I have a Grbl-ESP32 board that is a dual-core 240Mhz with USB and wifi and microsd controller which could run headless. Smoothie can do that too, and I’m sure many others.)

Given that, it sounds like the primary distinguishing benefits of the Ruida over gcode controllers involve engraving rather than cutting. Is that right?

(None of the lasers I am window shopping for comes with m2nano; I’m looking bigger than K40 if I’m going to do it at all. :slight_smile:)

Other features that a DSP controller like the Ruida have are things like mechanical backlash compensation and smoother motion planning (Much larger look ahead buffers, better planning algorithms) What kind of budget and what are you planning on doing with the laser?

1 Like

I have no plans at all. I’m just window shopping at this point, now that I realized that my shop reorganization made a space into which I might someday put a laser cutter. (It’s near the one outside wall, so I could run an exhaust line outside.)

I’d expect to be primarily cutting not engraving. Acrylic and wood shapes, likely things like cases and shapes for math education. My metal work and 3d printing are primarily functional (physically or educationally) not decorative. I’d also use moly or cermark to mark metal, like marking 1-2-3 block matching sets for machining.

I don’t know whether I’ll ever do it, and I don’t have my finger on the trigger to buy. I just was bothered by not understanding concretely what the benefits of a Ruida controller were.

I have no budget identified. If I did buy one, I wouldn’t cheap out on cooling; I figure if I ever get a CO2 laser, a CW-5200 is part of the acquisition cost.


Yes, the Ruidas have a nice performance, but I don’t like that they are closed source. And they only work headless, I mean you always send the file to the controller and then it’s run. No real time controll from a PC (which I prefer). On the other hand, the workflow is easyer this way.

1 Like

Here is a bit of info from a Lightburn forum. Oz gets it wrong in one place by saying the BBB(Beaglebone Black) can’t do realtime control of motion planner/stepper motors. The BBB has 2 dedicated 200MHz embedded microControllers( they are called PRUs by TI ) which can and are used for this exact task.

I have a BBB combined with the CRAMPS board running a delta 3D printer controlled by Machinekit(LinuxCNC/EMC2) which has all the motion planning and backlash control capabilities. Not many use it on laser cutters though.

I would also love to hear how the Grbl_Esp32 boards( Bart Dring’s ) might be compared to Ruida controllers. GRBL on 32bit boards provides much more code space for improvements like improved motion planning, buffering/look-ahead and backlash control.

1 Like

Thanks for that link! Very helpful.

I had a Replicape for my BBB that was going to control my corexy printer until the Replicape died with a known common failure while I was still setting up, and I decided to cut my losses and move on to another controller. But they used the PRU for motion control on both their old custom firmware and then after moving away from it to klipper. Normally klipper does motion control on a SBC and motion planning on a full system, but on the BBB the motion planning is done on the main CPU and the motion control is done on PRU (I think it uses only one but I might be mistaken). Having skimmed through the ruida emulation referenced in MeerK40t 0.6.0 released! it does seem like it would not be hard to have the PRU implement the RDworks protocol and I’d expect it to be able to give similar results. Since the BBB has 7 hardware PWM ports (where you can set frequency and duty cycle and then let the system do its thing), and the 200MHz PRUs can be mapped to control them, I’d expect that the BBB could indeed easily handle the power level motion planning Oz mentions.

I have thought about using MachineKit for my CNC mill build but put that on hold for other projects for a bit. I’ll get there eventually. I continue to be surprised at how hostile LinuxCNC is to MachineKit, unless something has changed since the last time I looked.

I have one of Bart Dring’s Grbl_Esp32 boards (well, actually, two of them) and dedicating one of the 240Mhz tensilica cores to motion control and the other to comms and motion planning seems like it would make sense. But I keep spending personal coding time upgrading MakerForums instead of writing new firmware. :stuck_out_tongue:


OK, no coding outside of the Maker Forums or I cut your pay in half :wink:

As part of my exploration for Ruida Emulation and backend on MeerK40t I did bother to reverse engineer all the commands, the protocols (mostly already done), and all the parameters. And coded up some pretty reasonable documentation for the whole thing:

The MeerK40t emulation will also tell you what all the things actually do and what the commands being issued are called, even the ones RDWorks doesn’t tend to produce. Some aspects I’d need to ask somebody with the machine to mess with and figure out. I’m not really sure how the power ramping works. But I did map out the entire protocol.

A lot of people somehow poopoo the M2Nano, but the streaming protocol is actually pretty impressive and useful. Very few of the supposed limitations there are real. And with better software they’ll tend to fade away. I daresay using a similar methodology it would be possible to have an arduino uno raster better and faster than even top of the line gcode boards.

I didn’t get around to doing full command conversions for the ruida device, where you’d end up controlling the M2Nano with the same ruida commands but that’s mostly possible. There’s a few PWM commands that don’t have a 1:1 conversions (especially things for the secondary laser controls), but I’m planning on revisiting that emulation later and making it entirely reasonable to just control the M2Nano as if it’s a Ruida. It’s a much cleaner laser encoding built for actually doing lasering rather than CNC and adapted to laser. You get a lot faster processing and much more command dense coding.

I also tended to have plans to do gcode-emulation for MeerK40t but I’m going to finish ruida first because it’s simply a lot cleaner and easier to do.