so I’ve noticed that, when I enable Z-Axis but disable relative moves, the Laser cutter will not start cutting when it should move the table due to the set material thickness
Enabling relative moves, and setting in OR out moves, just doesn’t move the table at all, but continues cutting.
Both are, obviously, not desirable.
Since you’re gonna ask: the Ruida controller I have in here does not support Z-axis, only the U axis.
However, I am very much able to move the table up and down with the corresponding buttons in lightburn (and the pad of course), and the auto focus works as well.
Additionally, I have two different offsets for the auto focus: the offset of the head and the auto focus pen. So, when I start the auto focus, the table starts at 10mm (this is one of the offsets I have set).
This means that I should be able to perfectly move the table up or down, even with non-relative moves.
My guess is that there’s some bug hiding behind the Z/U-mapping that’s in LightBurn, like requesting or waiting for a Z move, but not realising that U needs to be moved, whereas the buttons have the logic set correctly.
I have just installed the omtech autofocus kit into my omtech 2028, it only has the U axis and I have the same problem.
The bed moves as it should and focuses correctly when using the machines control panel and also moves and focuses using the lightburn move control panel.
The z offsets in the layers do not move the z axis though.
Exactly the same issue then, I have also installed the autofocus kit after the fact.
The “Get Position”-Button even returns the correct “Z”-position after autofocus.
Clearly a bug, and quite a simple one to fix presumably.
If you are using a Ruida controller that uses U instead of Z, that’s not supported by LightBurn yet. I actually tried to get this working a while ago, but it seems the firmware commands for moving the Z axis don’t have exact mappings to the ones for the U axis, at least, not that I’m able to find.
It’s on our radar, but not a high priority as most users don’t bother with Z at all.
Yep, I was suspecting so - it’s weird, because ALL other Z-related buttons work perfectly fine, just the material thickness related commands don’t work at all. Even “Get Position” returns a Z value, not a U value. That’s why I was suspecting a few workarounds from your end already in place, and was hoping that maybe you just missed a spot
