New driver for "Ruida" class lasercutters, like ThunderLaser

[kkaempf]

Initial PR

• can write to File
• can write to USB

Known bugs

• cannot write to Network

Fixes #105

[tatarize]

Overall I think this will work, and it's pretty much by definition better than nothing but stronger testing with actual hardware may be called for, and the specific versions of ruida this works for (namely those with magic number 0x88 should be more closely specified, unless that limitation is lifted.

[mgmax]

Very well readable, I really enjoyed the ByteStream that hides the low-level stuff. There are some minor issues that you should check, and then I am happy to merge:

1. Please implement saveJob() so that the automatic regression test of LibLaserCut (test-output/) and the "Export Laser Code to file" menu entry in VisiCut work.

2. Regarding the upcoming integration in VisiCut, you should check whether the serialized XML files for device settings and power settings look nice (no junk variables, etc.). If adjustments are needed (marking fields as transient, etc.), it is best to do these now to not break compatibility with saved settings later.

At least for an earlier version of the driver, the config file
https://github.com/fablabnbg/visicut-settings/blob/master/devices/Nova_32_35_32_fablabnbg.xml
has some irrelevant variables (ruida boundingWidth, ...) that should be marked as "transient" to remove them from serialization.

3. If the network part doesn't work yet, please check that some warning is shown to the user to make it clear that network is not yet implemented.

[tatarize]

@kkaempf
I was planning on writing a ruida driver for meek40t eventually, though I'd probably opt for the more complex plotter/controller setup. Where you basically delegate out how you control the laser and then get a bunch of basic commands and when you issue commands or state changes it just converts that into .rd code. The notable benefit of that is, if you wanted you could basically use the class as an interface to talk to the laser in code. So you could code up a quick script that would get your ruidacontroller tell it to connect. Then issue some goto(x,y) and mark(x,y) commands and set the different relevant settings on the device. Call things like with pure functions and have the code do the mediation. So you could just call a function to have it list all the documents or set the large amount of memory parameters.

Then simply use that object that converts commands to laser-controller commands and sends it, to deal with the driver hooks needed for this driver. Though for pure functionality converting straight into code you generally think works is pretty good.

writeJobCode(LaserJob job) is okay but really rather than coding these bits of stream.hex() and commenting things like blow on I'd really just have command controller.air_assist(True) and controller.set_speed(currentSpeed) and controller.vector_mode(). You could then have a class somebody else could easily reuse. I did that for the lmc-galvo (ezcad2) driver I wrote a bit back (https://github.com/meerk40t/meerk40t/blob/main/meerk40t/balormk/lmc_controller.py). Basically insulate the programmer from knowing how ruida code works. I mean I can read all the code there down to the ACK packets only because I went through and reverse engineered all the commands. But, packing all the stuff into a class you call with some commands and it talks to the laser for you. Rather than constantly rewriting this driver.

Currently my ruida offerings is an interpreter for all ruida code where it translates code from lightburn or rdworks and has it control an M2 Nano.

[kkaempf]

So many good ideas, so little time.

I'm basically a Java illiterate and it required years (mostly due to Covid making the lasercutter inaccessible for me) and several attempts to bring the Ruida driver to an acceptable state. I will finish it to the point where it gets merged into LibLaserCut.

I will continue to fix bugs. But any larger improvements/rewrites need to be done by someone else. 😞

[mgmax]

Almost done! Good :-) Please see my comments for some minor improvements.

If the network driver is not usable, then it would be better to somehow disable it (at least stop with an error message if someone tries to use it, or similar). Doesn't make sense to ship half-broken stuff.

[kkaempf]

there's still a problem with the network driver, but everthing else is implemented/fixed. wink

Network is fixed now 🎉

[mgmax]

I found one network issue, and some very minor things. Close to the target :-)

[tatarize]

When it gets down to testing. Do note that MeerK40t has a built in RuidaEmulator you run "ruidacontrol" or "ruidadesign -v" and send it data and it'll tell you exactly what all the commands are and what they do and draw whatever you sent it (if using ruidadesign). At least for 0.7.x versions. The protocol is pretty expansive but I reverse engineered the whole thing so I know what everything does, and the emulator pretends to be a Ruida device (networked) on the 50200 and 50207 ports (the -07 port is because there's an android app that works as a remote control). Ruidacontrol lets me you control your K40 or other device with RDWorks or Lightburn, and when this driver works Visicut too.

[mgmax]

looks good, will merge in a few days

[mgmax]

You can now cheerfully update the https://github.com/t-oster/VisiCut/wiki/Supported-Hardware page and then throw a large celebration party. 🎉 🎈 🎈 🎈 🎈
Happy to see the fablabnbg changes (mostly) merged back in. ❤️