MeerK40t ruida support?

It looks like some of the nicer lasers for sale come with a ruida controller instead of M2nano. I finally realized while working with @keen on New to K40: Start Here that I don’t see open source support for ruida controllers.

I recently ran into some documentation of the Ruida protocol

Is this something you’ve thought about supporting for meerk40t? Or would it be too much of a pain?

There is a Ruida forum and of course LightBurn that supports Ruida.

1 Like

@HalfNormal am I missing open source components there?

RDworks and Lightburn are the only software I’m aware of that currently support Ruida controllers.

@mcdanlj Those two sites are the gold standard for Ruida support. No need to duplicate support here.

1 Like

When I wrote the first open source scanner driver for Linux, including pouring over and annotating pages and pages of hex dumps from a SCSI analyzer to understand how it worked, there were proprietary drivers for Windows, so by the same logic there was no need for me to duplicate support. My work helped launch SANE. I understand that not everyone here has the same interest I do in open source. But I consider all hardware that cannot be driven except by proprietary software as disposable. Even if I choose to use proprietary software to drive it from time to time, if there’s no open source alternative, it’s disposable and therefore a toy not a tool.

I’m not really doing a survey to learn whether other people active here are interested in open source support for Ruida controllers. I was only trying to ask @Tatarize whether supporting Ruida controllers was something he had thought about. Since some K40-class machines do include Ruida controllers, and the name is “MeerK40t”, it doesn’t seem like a crazy question to me. Doesn’t create any obligation for anyone, @Tatarize or otherwise, to do any work to support it. But I don’t think it’s a bad or stupid question.

1 Like

No offense to your search for open source software. The Ruida a controller has been out for quite some time now. Lightburn is the only software that has done any work to take advantage of its hardware. Unfortunately it is not open source. I apologize if you have taken any offense to the statements other than saying after all this time there are only two sources that address the Ruida a controllers.

I’m trying to update @keen’s document with a bit more information. I already, before asking this question, added to that document the information about RDworks and LightBurn, which was not in what @keen had written so far.

In addition to that information that I hunted down during my editing process, I wanted to be complete. Meerk40t is new software, and @Tatarize is working on it very actively. If you haven’t been following it, you wouldn’t know that. But he’s made a point of making it somewhat modular, and there are K40-class machines with Ruida, so asking about his current state of implementation and intentions is reasonable for the purpose of updating summary documentation that we’re trying to make complete.

This question was directly asked about MeerK40t in the Meerk40t category, and was not related to RDworks or LightBurn.

My expectation when I asked it was that we might just wait and let @Tatarize speak for himself instead of jumping in front of him and answering on his behalf.

But… I went and looked at the Meerk40t source code, which in says:

LhymicroInterpreter provides Lhystudio specific coding for elements and sends it to the backend to write to the usb
the intent is that this class could be switched out for a different class and control a different type of laser if need
be. The middle language of generated commands from the LaserNodes are able to be interpreted by a different driver
or methodology. 

So adding Ruida support, while I don’t see it there today (I read source code in the mean time), isn’t an unreasonable idea for Meerk40t at some point in the future, if the existing protocol documentation is good enough.


The data for Ruida is actually quite good and the reverse engineering there is much more mature than the reverse engineering for Lhystudios boards. In fact I did a lot heavy lifting in figuring out how that works to the point that there’s internal discussions of building Arduino boards that run Lhymicro-gl and include some additions like PWM z-bed control and some other outputs since the underlying scheme is simple and basically ascii-byte-code to control hardware signals.

So yeah, while building MeerK40t I kept a lot of things in my mind and one of them was Ruida support etc. I made a point to keep the backend very distinct and isolate the coding there so that all the front end code will work fine if you switched over to a different backend. In fact, the program currently allows for multiple backends. While strictly speaking there’s only M2 support, and that isolation allows multiple M2 boards to be controlled at the same time, the idea is to make sure I could let people switch to using Ruida or GRBL or whatever else. Since it does not do any low level stuff that is restricted to one particular type of board. It’s explicitly agnostic as to what type of laser it’s running and how the interpreter is converting the middle language commands into data the laser accepts.

I read the Ruida reverse engineering stuff and it’s actually quite solid and reasonable and highly able to be implemented quite easily. The problem here isn’t the code, it’s the hardware. While I could basically do the same thing the ThunderDriver is doing for Visicut or whatever other implementations are doing by converting that into commands that the Ruida understands and code up all connections between the front and back ends. The sticking issue is that: I do not own a Ruida.

I would create a program that might be 98% of what somebody who owns a Ruida needs. And if the laser is slamming into the gantry 2% of the time that’s actually an issue. And it’s not one I could address, because bug checking software-hardware interfacing without hardware is a problem.


I will say Visicut is an open source project and does have support for Ruida through the ThunderLaser fork which may or may not have been integrated back into the main code for LibLaserCut. But, also there’s some other smaller projects that basically are just backend code already for example: could be adapted quite quickly to serve as a backend. And that’s basically everything. And it’s a couple tiny bits of code.

However, his licensing is wrong and my code is MIT licensed and I can’t include GPL code without needing to be GPL myself


I ran into that general problem, multiple times, with the first device driver I ever wrote. And that was far simpler.

Sometimes it’s a problem even when you have the hardware. The first time I wrote a Linux SCSI driver I gave up and never posted it because my hard drive always hung. A few years later I connected a known-good controller to it, and… the drive hung. Turns out it had a firmware bug on the drive. (So, it turns out I could probably have accelerated Linux support for one particular chipset by something like two years if I’d just posted it as a WIP and let other people try it out. I felt bad about that later.)

If I get a device with a Ruida controller, I definitely volunteer to try to do the 2% — you know your own driver model and understand the general Ruida operational model, and I have written and debugged device drivers. :slight_smile:


Looks like he’s starting over on his Ruida backend based on insights he gained, so not merged yet.

Didn’t look into licensing though; GPL “infecting” MIT so not useful for you, or something else wrong?

I could also just write the code on spec. Odds are good I could ask about licensing and a lot of folks well happily release their stuff in something that compatible with MIT. It’s still useful for me. Knowing how stuff works matters, but they are just technical information like documents. I can’t use any of the code, anything that is specifically copyrighted has the copyrights reserved unless the code using it is also GPL. Though I only really need the technical specs. And those seem to exist in a number of places and in enough detail to code an implementation myself.

I could certainly code that up for the 98% and from the way people seem to be doing this stuff I could also write a variant of my project of GRBL emulation to emulate a Ruida machine. I guess the effect there would be that I could launch a device that would appear to be a Ruida to RDWorks but it would just be talking to MeerK40t. It’s how the GRBL Emulator works. Which basically just lets programs like Visicut or LaserWeb or LightBurn control the Lhystudios-M2 board that is pretending to be a GRBL. And the protocol for GRBL is much more robust and involved than Ruida’s and would weirdly let RDWorks control MeerK40t and thus the M2Nano. But, it would also allow for some reverse engineering since RDWorks likely knows the protocols pretty well.

The chips on the Ruida seems like a DSP hooked to some ram, and eeprom, and a reasonable processor. So it’s kinda a fully fleshed out computer in the same way the M2Nano isn’t. Which means it can have some higher order commands (in the exact way the M2Nano cannot). Which is likely why it does stuff draw the lines themselves. Likely implemented Bresenham in firmware.

Implementing a parsing emulation server and translating stuff would help if there’s something else in the protocol that isn’t covered in some documentation.

1 Like

Have you considered aproaching Ruida directly. I know they are working with LightBurn, sharing code and command structure with them. They might possibly be willing to provide you with what you need.

1 Like

@Tatarize I am thinking that it would be easy for you to test code on a Ruida controller on someones machine remotely. You could remote into the computer and/or the Ruida can be used via Ethernet and run the laser with the user. I would be willing to do that with you.


There is always the option of raising some funds via community drive to get you a Ruida controller as well. They are not that expensive.


Actually there’s a lot of coverage for the Ruida, it has software around that works for it already and it’s mapped out nicely. What I actually want is a Moshiboard, or a bunch of solid wiresharks for it.

The issue is I don’t think many people still have those boards. They are getting pretty rare but use much the same scheme as M2 Nano.

I’ll plan on making a Ruida emulator. So you could use RD-works connecting to a fake server that’s really just MeerK40t that will control a standard stock controller. While this is clearly not a workflow anybody would like ever have, it would allow men to fairly nicely make sure I have the ruida format parsed out well enough to write a backend driver for it. Should be a dummy listener and parser and figuring out the rest of it by messing around with RDWorks.


i’ll have to look but i might have a moshi collecting dust in my garage :slight_smile:

1 Like

Yeah, wireshark and performing some predetermined things should be able to map most of that out. I’ve looked and clearly it’s also a CH341 hooked to a 8051 processor so it’s going to be the same byte-code to flip switches on the laser scheme that the Lhystudio boards use. There’s strong reasons to think the Moshi stuff internally will be like an early prototype version of the bytecode streaming stuff done in the M2. Since it can’t do any actual processing itself, other than flipping states on the chips.

1 Like