Ruida software focus

[TheAssassin]

This PR is a work-in-progress to add support for software-controlled focus to the Ruida driver by moving the Z axis to the specified value.

Software focus is optional; users may prefer setting the focus manually with their controller. This is mainly important for devices such as the OMTech Polar which does not have such a panel (only a single start/pause button). But it may come in handy for other devices, too, as one could possibly use this feature to, e.g., move the focus inside of the material to optimize cuts. For the OMTech Polar, this is not relevant at this point, as the focal distance with the original toolhead assembly does not allow for that (the air assist nozzle nearly touches the material).

[jnweiger]

@TheAssassin I had an old dump lying around, where I exercised moving the the Z axis and the X-Axis manually with the Jog buttons in Lightburn (or maybe it was RDworks, not sure).

Today, I succeeded in decoding the dump. Repeating the same button press, moves the machine further, but the command is identical. So they are meant to be relative moves. This is the first time, I see the long 5 byte format used for relative moves, which is otherwise only used for absolute moves. But why not...

Zup 1mm, spped 10

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 0f 7f 7f 78 18 =>[-1.0] (:mm)

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 0f 7f 7f 78 18 =>[-1.0] (:mm)
--------------------

Zup 5mm, speed 10
    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 0f 7f 7f 58 78 =>[-5.0] (:mm)

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 0f 7f 7f 58 78 =>[-5.0] (:mm)
--------------------

Zdown 5mm, speed 10
    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 00 00 00 27 08 =>[5.0] (:mm)

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 00 00 00 27 08 =>[5.0] (:mm)
------------------------------

Zdown 1mm, speed 10

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 00 00 00 07 68 =>[1.0] (:mm)

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 02 Direct_Move_Z_rel  02 00 00 00 07 68 =>[1.0] (:mm)

-------------------------------
Xaxis right, 1mm, speed 100

    1: c9 02 Speed_C9_02 00 00 06 0d 20 =>[100.0] (:speed)
    1: d9 00 Direct_Move_X_rel  02 00 00 00 07 68 =>[1.0] (:mm)

    1: c9 02 Speed_C9_02 00 00 06 0d 20 =>[100.0] (:speed)
    1: d9 00 Direct_Move_X_rel  02 00 00 00 07 68 =>[1.0] (:mm)

-----------------------------------
Xaxis right, 1mm, speed 10

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 00 Direct_Move_X_rel  02 00 00 00 07 68 =>[1.0] (:mm)

    1: c9 02 Speed_C9_02 00 00 00 4e 10 =>[10.0] (:speed)
    1: d9 00 Direct_Move_X_rel  02 00 00 00 07 68 =>[1.0] (:mm)

----------------------------------

jnweiger/ruida-laser@259772d

[TheAssassin]

Thank you @jnweiger. Unfortunately, D902 does not do anything as far as I can tell. Only 800B makes the Z axis motor move. The value sent along appears to be absolute as well; sending a command to move to 0 makes it return to the origin position.

I guess to find out what LightBurn does, someone needs to capture the communication between it and the device. But I won't get around to doing so in the near future. For now, I'm happy it works this way. We can, if needed, add either command with a special device-specific setting, though ("OMTech Polar mode" for instance, this is what LightBurn uses, too, so there's a chance that all the other Ruida devices just accept the other command while the Polar does not).

[jnweiger]

I guess to find out what LightBurn does, someone needs to capture the communication

That is what I did. And I saw the table moving up and down nicely.

So I'd rather say we have a difference between Thunderlaser and Polar.

• Your Polar moves its lenses, my Thunderlaser moves its table. So maybe that are two separate concepts, and the respective motors go to different ports of the controller?
• Maybe your controller is different?
• Maybe there are different workmodes (or whatever) that can be selected.

[TheAssassin]

Your device seems to have a RDC6442G while the Polar has a RDC6442S. I cannot tell what the difference is however. I suggest you wait for me to complete the patch and try it out then. Maybe you can test the code you found to work with yours, too, by adapting the source code. For now, due to the lack of another device, I must assume that the code I have is the one to use as this is covered by empirical evidence.

[jnweiger]

I'd rather implemment a controller type detection (just as lightburn does it) and send the correct commands for each. Unless we understand more about the special "OMTech Polar mode" in lightburn, I'd say, that d902 is standard for the z-axis :-)

https://www.ruidacontroller.com/rdc6442s/ says:

RDC6442G VS RDC6442S

    6442G: Standard / 6442S: Double Head Linkage

[TheAssassin]

Well, LightBurn has an explicit switch that you need to enable for the Polar to work properly. I'm not sure a controller detection will do the trick.

Anyway, I'd ask you to try this implementation once merged first.

[TheAssassin]

This branch is ready for review. I cleaned it up sufficiently for inclusion in LibLaserCut.

Edit: we need to adjust the driver test, we're emitting new commands now. I'll fix that.

[TheAssassin]

Diff of the driver output:

--- de.thomas_oster.liblasercut.drivers.Ruida.out.dec	2024-04-15 02:51:54.351759407 +0200
+++ de.thomas_oster.liblasercut.drivers.Ruida.out.new.dec	2024-04-15 02:51:54.399760594 +0200
@@ -17,6 +17,8 @@
 Laser_1_Min_Pow_C6_31 Layer:0 100%			c6 31 00 7f 7f 
 Laser_1_Max_Pow_C6_32 Layer:0 100%			c6 32 00 7f 7f 
 Layer_Speed Layer:0 1000.0mm/s				c9 04 00 00 00 3d 04 40 
+Axis velocity 5.0mm/s					c9 03 00 00 00 27 08 
+Move Z absolute 0.0mm					80 0b 00 00 00 00 00 
 Laser_Freq Laser1 00 0.5kHz				c6 60 00 00 00 00 00 03 74 
 Layer_Color Layer:0 R 39%, G 0%, B 0%			ca 06 00 00 00 00 00 64 
 Layer_Setup_End Layer:0 00				ca 41 00 00 
@@ -46,6 +48,8 @@
 Laser_1_Min_Pow_C6_31 Layer:1 100%			c6 31 01 7f 7f 
 Laser_1_Max_Pow_C6_32 Layer:1 100%			c6 32 01 7f 7f 
 Layer_Speed Layer:1 1000.0mm/s				c9 04 01 00 00 3d 04 40 
+Axis velocity 5.0mm/s					c9 03 00 00 00 27 08 
+Move Z absolute 0.0mm					80 0b 00 00 00 00 00 
 Laser_Freq Laser2 00 0.5kHz				c6 60 01 00 00 00 00 03 74 
 Layer_Color Layer:1 R 39%, G 0%, B 0%			ca 06 01 00 00 00 00 64 
 Layer_Setup_End Layer:1 02				ca 41 01 02 
@@ -86,6 +90,8 @@
 Laser_1_Min_Pow_C6_31 Layer:2 100%			c6 31 02 7f 7f 
 Laser_1_Max_Pow_C6_32 Layer:2 100%			c6 32 02 7f 7f 
 Layer_Speed Layer:2 1000.0mm/s				c9 04 02 00 00 3d 04 40 
+Axis velocity 5.0mm/s					c9 03 00 00 00 27 08 
+Move Z absolute 0.0mm					80 0b 00 00 00 00 00 
 Laser_Freq Laser3 00 0.5kHz				c6 60 02 00 00 00 00 03 74 
 Layer_Color Layer:2 R 39%, G 0%, B 0%			ca 06 02 00 00 00 00 64 
 Layer_Setup_End Layer:2 02				ca 41 02 02 
@@ -116,6 +123,7 @@
 Mov_Abs 2.133mm 4.165mm					88 00 00 00 10 55 00 00 00 20 45 
 Laser_1_Max_Pow_C6_02 100%				c6 02 7f 7f 
 Cut_Abs 2.235mm 4.165mm					a8 00 00 00 11 3b 00 00 00 20 45 
+Axis velocity 5.0mm/s					c9 03 00 00 00 27 08 
+Move Z absolute 0.0mm					80 0b 00 00 00 00 00 
 Work_Interval 01 06 20 365.0mm 365.0mm			da 01 06 20 00 00 00 02 6d 00 00 00 02 6d 
 Stop							e7 00 
 EOF							d7 

[mgmax]

Happy to see that the Ruida driver is growing :-)

Here are my thoughts from looking at the code for a few minutes:

• Please rebase / resolve merge conflicts.
• The code uses absolute "0" to reset Z (?) but in other places it claims that the offset depends on the device. Is that correct?
• Does the focus value behave as intended in the VisiCut UI? To have same behavior as the Epilog Zing, focus=0 should be "at the top level of the material" (assuming the material depth is set correctly) and focus=-1 should be "inside the material, 1mm below the top". I'm happy to discuss changes; in the end VisiCut/LibLaserCut should provide some suitable abstraction to the user where all lasercutters with focus behave the same. Probably we will need to make some changes regarding the checkbox "focus initially on top of material".
• Do old setting XML files from previous VisiCut versions still work, now that the class has been renamed?
• Did you test the code on a real device?
• What about backwards compatibility, do we want to have some kind of "disable focus" switch?

[TheAssassin]

Please rebase / resolve merge conflicts.

I'll try once again, but git is giving me a hard time for no apparent reason. This would be an easy manual merge, though, it's merely one line.

The code uses absolute "0" to reset Z (?) but in other places it claims that the offset depends on the device. Is that correct?

0 is the initial homed value of the axis. In case of the OMTech Polar, that means that the tool head is moved all the way up (it's not the table that is moved, it's the assembly of the lens with the air assist nozzle). The "formula" is needed to then calculate a suitable reference value for the focus: it is known that the honeycomb bed is in focus at a value of 17mm, i.e., when the tool head is moved down by that amount. That means that the correct value for a given thickness is 17mm - thickness. This applies just to this specific device.

In order to provide a generic solution for all Ruida devices, I leave the decision of the applicable focus value to the person configuring the laser profiles. I don't think we can find a proper default that'll apply to all kinds of devices.

Does the focus value behave as intended in the VisiCut UI? To have same behavior as the Epilog Zing, focus=0 should be "at the top level of the material" (assuming the material depth is set correctly) and focus=-1 should be "inside the material, 1mm below the top". I'm happy to discuss changes; in the end VisiCut/LibLaserCut should provide some suitable abstraction to the user where all lasercutters with focus behave the same. Probably we will need to make some changes regarding the checkbox "focus initially on top of material".

Please note that VisiCut inserts 0 as the default focus value. Also, please note that the OMTech Polar's lens assembly is just 0.5-1mm above the material.

Let's imagine we'd have a setting "bed offset" in the machine settings and we'd configure it to 17mm. That'd mean that 0 corresponded to the bed surface. Given the device's properties, VisiCut's generated programs would generally crash the toolhead into the material for every material that has not been configured correctly.

The OMTech Polar does not have any manual jogging by default (one can retrofit a control panel but it's not easy and it costs extra money). It depends on the user configuring a correct software focus. That was the motivation for me to add this to LibLaserCut.

Other devices that have manual or automatic focus features and have a workflow that includes setting the focus on the material surface, 0 will work as usual. On the OMTech Polar, this is not the case.

The checkbox "focus initially on bed surface" should just die. It's not a problem to focus on the material thickness for most devices I know and it's the established workflow. This workflow further reduces/removes the risk of crashing the toolhead into the workpiece, too. Any kind of special handling is not necessary in my opinion.

Do old setting XML files from previous VisiCut versions still work, now that the class has been renamed?

Haven't tried, honestly. VisiCut makes it really hard to keep things compatible due to the enormous amount of automagic reflections. We'll have to tackle this in another PR, though. Personally, I wouldn't mind breaking old settings, though.

I already suggested we make software focus a configurable feature. That'd be enough of a reason to keep the old settings class then. Only when people choose to switch, they'll have to manually transfer all their settings.

Did you test the code on a real device?

Of course. As mentioned in a couple of places now (even here), I developed this feature on (and for) an OMTech Polar.

What about backwards compatibility, do we want to have some kind of "disable focus" switch?

Wrong approach IMO. As mentioned above, I'd rather have an "enable software focus" switch that is off by default.

[TheAssassin]

Conflicts resolved. Compatibility issues still exist, though, and need more discussion.