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]

@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. 😞

[kkaempf]

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

[kkaempf]

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

Network is fixed now :tada:

[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]

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