Support for Ruida boards, Bodor BCL 1309-XM, Thunderlaser Nova35

[mgmax]

There is an experimental (?) driver for Ruida Thunderlaser devices developed in FabLab Nürnberg: https://github.com/fablabnbg/liblasercut/tree/ruida https://github.com/kkaempf/LibLaserCut/tree/ruida (Older version: https://github.com/t-oster/LibLaserCut/pull/134 ) I contacted them (again) about merging it.

[kkaempf]

See #134 :stuck_out_tongue_closed_eyes:

[tatarize]

I've mapped out all the commands and properties for Ruida controllers. My ends are a bit different, namely I'm writing an emulator so I can control my laser cutting software from within RDWorks or Lightburn. I don't have a Ruida device so testing a driver is impossible for me. But, things always get easier when you know what they mean.

https://edutechwiki.unige.ch/en/Ruida

[kkaempf]

I think we can close this issue now ...

[tatarize]

It'll automatically close if/when #180 is merged.

This actually looks quite good. The stuff that needs to be configurable is configurable. I will say that some other version of the lasers do use a different magic number and have a couple different commands. I don't see any of the more cryptic commands being used, but the version would work fairly fine. But, it looks like you hard-coded the lookup table for the swizzle. The hardcoded values here use 0x88 but 0x11 and 0x38 are used for some devices.

The byte swizzle table can be generated on the fly:

    @staticmethod
    def swizzle_byte(b, magic):
        b ^= (b >> 7) & 0xFF
        b ^= (b << 7) & 0xFF
        b ^= (b >> 7) & 0xFF
        b ^= magic
        b = (b + 1) & 0xFF
        return b

And since you're still using the table lookup it should be just as fast. I do think this will work though, but if other want to test this even if the lack the board my laser control software "meerk40t" does full solid emulation of Ruida controller. And "ruidaemulator" run in the console will start listening on port 50200 and 50207 and if you point this driver to localhost it should translate the commands as to what they mean (I mapped out all of the commands). But, this should at the minimum cover a very reasonable subset of these lasers and let you gauge support and need for tweaks to support other lasers.

Writing a driver from the default Visicut format to Ruida is just writing something that should work fairly consistently. I might have opted for giving the names for the commands you're issuing rather than the hex values:

                stream.hex("ca0100");
                stream.hex("ca02").byteint(part_number); // start_layer
                stream.hex("ca0113"); // blow on
                stream.hex("c902").longint((int)speed);

This seems a bit like setting a static that says CA0100 means END_LAYER and then using the enum form (or static final for java).

                stream.hex(END_LAYER);
                stream.hex(PART_LAYER_NUMBER).byteint(part_number); // start_layer
                stream.hex(AIR_ASSIST_ON);
                stream.hex(SPEED_LASER_1).longint((int)speed);

Which could help a bit with the readability. I don't think there's directly a way to set the per-part configuration of air assist though CA0112 and CA0113 could trigger them on and off on a per-part basis. Which I might end up doing in meerk40t when I bother to write the ruida driver for it.

[kkaempf]

Thanks for the 'swizzle' algorithm, added.

I agree to the use of symbolic names instead of hex strings. But this is an improvement I'd do after it was merged upstream.