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
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.
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.
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.
@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.
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.
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.
Found it tucked in an antistatic bag so it should be viable. Do you need the dongle also? If interested Message me your shipping info and how you would like it sent, preferably on your shipping account. Free is never free is it?
I also found this image where someone had mapped out part of a Moshi board. I downloaded it quitre a while ago and unfortunately I can’t recall where I found it though >.< Hope this helps you sort things out!
I’ve seen that diagram before it’s largely how I know the chip and setup etc. And that the scheme used is going to be very close to the M2 Nano. Like I wouldn’t be surprised if the Nano wasn’t a largely stolen design. Yeah, I would need the dongle. Moshidraw might even be easily fooled into working with a dongle and anything that has a CH341 chip to wireshark that into spilling most of its secrets. I’ll def pm you.
Got the board from Joseph. Running some wiresharks on it. It’s very dissimilar to the M2 nano. It has memory, and the sends are not A0 they are A6 and A7 which is a direct memory write. It has weird routines like set A7 to this value then read (AC01) then reads that byte. It has a bunch of weird 3 byte command structures that sometimes group into like 6 or 7 command bunches. The running theory is that the M2 nano streams a bytecode interpreted by the firmware in the CPU to flip the bits. And the Moshi is literally streaming the bit flip binary, or it could be basically literally CPU commands in binary. And it’s just constantly pinging for the state, so it sends status requests several times a second. And the status byte is idle when finished and busy while it’s running, and shows that in moshi draw.
My dream of slapping something together in a few hours is doomed. I could likely just ask the chip for the any firmware it has and it would hand it over.
And this answers the question what a very primitive form of the M2 scheme would be.Though really the M2 is a bit more simple because it does the entire thing without any memory. It just runs that from the CPU cache.
Made a github for the effort, including some of the major findings.
Turns out the format is higher level than I expected. It’s got a header, body, and footer and stores the values of the positions in absolute positions. And you merely give it the series of locations it should go to. This means it knows how to turn a character into a particular laser speed directly, how to draw lines with a built in line draw algorithm. And it stores its current location within the local space at all times.
It has a weird hash/command trigger thing that I do not understand. It sends 1 command bit, then 2 int_16le absolute positions. But, in raster mode it sends 1 command bit, then 1 int_16le absolute position. When this triggers the laser to high, this command is always above 128 (when not turning on it’s still sometimes high for some reason). And the command byte values shift, like they don’t use the same value each time. They differ by some methodology each command byte is partly randomish and part bits that flag the laser on or off or gives the number whether it has a new x position or new y position.
Also, I don’t know if anybody has these boards anymore. So it’s turned out to be way more alien than I hoped. And this damned hash/command byte is messing with my head. Might still end up doing this, but there’s still some notable encoding weirdness. If I crack how that command byte works, I could likely code up a functional backend in a day or two. — But I might just table the project.
Got a cursory Ruidaserver working. Likely could map out more of the local commands as such.
I bothered to get that to work. Turns out it has no hidden gotchas. I can send it commands as part of a thingy and it does those thingies. I mean it’s not really working yet, but it’s like a couple hours of debugging from solid. @Domm434 I got it working!
Test the operation of Meerk40t and eliminate the cause of the laser head wandering around the working field of the laser machine as it spoils the material used for engraving / cutting.
Also, can you present a better test case for replicating this, and maybe raise an issue on the issues for this critical issue (anything that spoils material or is a real danger to the user is a critical issue).
