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. 
)
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.
2 Likes
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. 
3 Likes
OK, no coding outside of the Maker Forums or I cut your pay in half 
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: https://edutechwiki.unige.ch/en/Ruida
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.
3 Likes
I’ve been watching Russ Sadler putting a Ruida controller on a K40, upgrading some of the motion elements(X axis bearing and 2nd Y axis bearing) putting a super lightweight laser head and a larger X axis motor. He got it to 1000mm/s in his first tests.
Just wondering if anything further became of the Meerk40t Ruida server driving M2Nano board and if there’s a benefit which raises the performance above say an esp32 GRBL or other 32bit controller/firmware? The Ruida upgrade itself for the K40 is over $300 on Cloudray’s site.
In general, I like the Ruida. It seems like a pretty strong board for lasering, much more so than a gcode board which works but it mostly adapted towards it. The Ruida server driving the M2Nano board has in recent months gotten really popular. There’s guides for using and a number of people are using lightburn and MeerK40t to control their stock controller. More than I would have expected. The M2 Nano board itself will absolutely max out with the steppers above 750mm/s or so and can’t send the ticks above that speed. Gcode would likely fail before that, depending a bit on the board in question.
The M2 Nano would actually probably perform better than the Esp32 GRBL just because it is likely a better board. There’s also not too much need for speed in rastering beyond about 400mm/s, you’re better off skipping some more scanlines than going faster.
A lot of people seem to insult the M2 Nano but it’s mostly a character bytecode streaming device like a Klipper for 3D printers, and generally rasters faster than most gcode boards.
4 Likes
It’s worth noting that FluidNC (and grbl-esp32 before it) is based on FreeRTOS and can take good advantage of the multiple cores of the ESP32-C1 series.
- I monitor the FluidNC discord chat and it’s obvious that Bart, Mitch and others have a good eye on the idea of getting it ported to other multi-core architectures.
But it’s not really a fair comparison between that and the Rudia controllers, they are really different beasts aimed at different use-cases and with different price-points.
I think a better comparison is between Rudia and RRF.
RRF is still being strongly developed by David Crocker for Duet3d and other boards, It has been ported to the STM32 and LPC architectures as well as the Arm Coretex cpu’s that Duet3D use on their boards.
You can set a maximum accelleration and jerk for it, of course. But it also supports input shaping (using an accelerometer to reduce ringing modes), which is quite neat.
CNC and Laser support in RRF these days is pretty good, it supports CAN bus and various different types of motor driver, and when combined with a one of the larger PanelDue touch controllers would make a much more interesting comparison. Especially since it’s open source and well documented + supported, rather than a sealed ‘magic box’.
3 Likes
I hadn’t known FluidNC was using FreeRTOS but was figuring it was a from-scratch firmware given all the design goals. Definitely something to watch.
Hmm, I knew RRF was around but never gave it much thought since I’ve really not run into anyone saying much about it. Until now. It does indeed look interesting and I do have a bunch of LPC based boards like the SKR v1.4 turbo. My Ender3 needs some help so maybe I’ll give it a try:
I’m also looking to do a K40 upgrade to the X axis(400mm linear rail) and 2nd Y axis(300mm linear rail) and an acrylic version of his lightweight laser head. So maybe after that I should try RRF on the K40 and see what it can do with TMS2209 drivers and the stock motors.
1 Like