MeerK40t ruida support?

I was more thinking that you could have it, let me go look and verify it is actually a Moshiboard.


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? :slight_smile:
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!

1 Like

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.

3 Likes

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.

3 Likes

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!

4 Likes

13 posts were split to a new topic: Using Meerk40t to help create Ruida laser management software?

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.

For which Driver?

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).