Monport Onyx R ; Z seemingly switched with U axis

jnse · June 24, 2025, 10:48pm

This thing has a Ruida KT322NZ controller.

Everything works for the most part, and this is somewhat of an oddity, which I think might be a bug in lightburn (or rather, a workaround for a different laser not applicable to the onyx R, but which can’t be disabled, as far as i can tell)

In the ‘Move’ window, the reported Z position is actually the U axis position.

The U axis position shown in the move window is 0.0 (which is fine, there is no U axis in this machine).
The Z axis position shown in the move window is 10000 (which is wrong, that’s actually the position the controller reports as the U axis.. (ish? see below) )
X and Y are fine.

When I sniff and decode the serial comms going over usb, when i click ‘get position’ in lightburn, the laser actually reports the correct position for Z, but it seems lightburn chooses to ignore it, and the reported U position is what it’s showing for Z:

Get position request (X)
Get position response (X) = 190.096
Get position request (Y)
Get position response (Y) = 83.702
Get position request (Z)
Get position response (Z) = 9.925
Get position request (U)
Get position response (U) = 9779.889

Oddly enough, the up/down arrow keys in the move window, and the focus button do control Z correctly - so it does the right thing when SETTING the position - but not when reading it back.

It does not however, behave correctly when I enable Z axis control and set a non-zero material thickness in a layer. That just causes the laser to hang.
But when I bang bits into the laser by hand, sure enough I can make it set a position for Z just fine.

jkwilborn · June 25, 2025, 10:04am

@ednisley has one of these controllers, maybe he can help you out. I have a 6442g and I’m not sure what to advise…

ednisley · June 25, 2025, 11:09am

That Z suffix suggests a difference from my plain old KT332N (EC). A casual search for KT332NZ produces no results, so it’s either proprietary or the new hotness.

I think the N suffix means the network is enabled and the (EC) has something to do with the usual “China Export” mark elsewhere on the sticker, but that is guesswork based on hints.

The Machine Settings have entries for both U and Z axes, but the controller has only a U axis terminal block on the back that goes to the stepper driving the platform leadscrews. AFAICT, the Z axis settings have no effect on anything.

The machine panel has two buttons controlling the platform, both marked U, and shows the U axis in the display:

Does changing the Enable U Axis setting make any difference?

I think you have a different KT332N controller which will require intervention from the good folks at @LightBurn before it works properly.

jnse · June 25, 2025, 6:54pm

Right, yeah, i figured there isn’t much I can do, and that it’s probably a quirk of this controller unaccounted for in the current implementation. But I thought I’d mention it anyway for future releases/fixes (although I guess i’m screwed anyway if linux support is being dropped in the next release).

Anyway, looking at the axis connectors on the controller, there’s indeed just ‘U’ a u connector, but no Z - but in machine settings I have U homing and everything else turned off, yet it does correctly home Z on startup. It’s almost as if sometimes they use ‘U’ when they mean ‘Z’ and vice-versa.
That said, whatever you want to call the axis, doesn’t change the fact that there /is/ a position readout that changes when the laser head moves up/down, which is NOT visible in the lightburn move panel, and it /is/ possible to send commands to set the absolute position height of the laser head, but that functionality is not working in lightburn.

Here’s some more info on what I actually mean:

With the laser head all the way UP to the limit switch, get position returns this for U and Z:

Get position response (Z) = 0.0
Read (raw):
00000000  D4 09 8D 49 89 89 89 89  |...I....|
00000008  89                       |.|
Read (unswizzled):
00000000  DA 01 04 41 00 00 00 00  |...A....|
00000008  00                       |.|
Get position response (U) = 9779.889
Read (raw):
00000000  D4 09 8D 59 89 8D EB 25  |...Y...%|
00000008  89                       |.|
Read (unswizzled):
00000000  DA 01 04 51 00 04 62 2D  |...Q..b-|
00000008  00                       |.|

Now, it is entirely possible that I mislabled these in my little communication sniffer/decoder program, I went in logical order, with 0x21=X, 0x31=Y, 0x41=Z, 0x51=U - if it’s 0x41=U and 0x51=Z fine, whatever, it’s kind of besides the point, because, now watch what I get when I move the head all the way down:

Get position response (Z) = 16.741
Read (raw):
00000000  D4 09 8D 49 89 89 09 8D  |...I....|
00000008  E1                       |.|
Read (unswizzled):
00000000  DA 01 04 41 00 00 01 04  |...A....|
00000008  68                       |h|
Get position response (U) = 9779.889
Read (raw):
00000000  D4 09 8D 59 89 8D EB 25  |...Y...%|
00000008  89                       |.|
Read (unswizzled):
00000000  DA 01 04 51 00 04 62 2D  |...Q..b-|
00000008  00                       |.|

The value for the 0x51 axis (what I call U) did not change, whereas the value for the 0x41 axis (what I call Z) now shows 16.741mm instead of 0 - which is about right, as this is roughly the limit of it’s movement. The device settings shows a maximum configured travel length of 17mm

However, the lightburn move windows shows Z:10000.0, U: 0.0 – The 16.7mm readout which is obviously being sent to lightburn, as i’m intercepting the traffic, is not visible within the lightburn UI anywhere.

That said, pressing the up/down arrows in the move window works perfectly, even if i use a lower distance setting, so obviously lightburn is aware of the axis, and can make the head travel to any position.

Here’s the script I’m using to intercept and interpret the data: https://linkerror.com/stuff/trace.py.txt

ednisley · June 25, 2025, 7:34pm

Have you changed the Enable U Axis setting? It might make whatever is now Z become U (or the other way around), although I have no idea which value would apply.

Are the buttons on the machine display labeled U or Z? That might hint at what should be going on inside.

I’m using the Ethernet port and could, if I learned a lot more than I know now, eavesdrop on those packets. For now, it’s a mystery.

jnse · June 25, 2025, 8:26pm

Amusingly, the only option I have is “Enable Z axis”, not “Enable U axis”
And it doesn’t seem to make any difference at all. Neither does the ‘incremental z moves only’ option. What “Enable Z axis” /does/ do is enable the ‘material height’ option in the layer options, which, if i set it to anything non-zero, the laser just kind of stops doing anything when submitting a job. - I’ll have to dig a bit further into the packets to see what lightburn is sending in that case.

Unknown, as my laser did not come with the normal ruida controller panel that presumably ships with the controller normally, like the one you have. All it has is a single start button and an emergency stop.

From what I understand from the documentation I’ve seen so far, the ethernet protocol is similar with some extra frame headers, so it shouldn’t be that hard to modify the script to use it. One of these days I probably ought to get the ethernet port on mine going, and then I can take a stab at that as well.

ednisley · June 25, 2025, 8:57pm

Which suggests the controller firmware is customized for Monport and having it work with LightBurn was a nice byproduct.

It looks like a nice machine, though: go have some fun with it!

jnse · June 25, 2025, 9:26pm

Oh, I’ve been Like I said, this is just a minor annoyance. The machine was quite nice for the price at the time, it was about $1k less than other brands with similar features a year ago or so, although there’s better options now. It’s wild how fast the laser market/hardware changes. I did have some issues when I first got it - I had to replace a broken relay (replaced it with a better quality one), and my Y axis was wired backwards if you can believe it - But trivial to fix, for me anyway - and debugging that was a fantastic way to familiarize myself with the hardware If you look at it as a mostly-assembled laser ‘kit’ then it’s a decent deal, if you’re looking for a ready to use consumer grade thing, then maybe not.

I’ve been working on deciphering the protocol, with the aim of writing a simple command-line tool to control the laser, and I think I’ve figured out the basics - ultimately, I’d love to write a gcode-to-ruida converter which should provide some minimal contingency for linux users after lightburn drops support, and the current working versions eventually succumb to bitrot, since there’s already plenty of tools out there which output g-code files. And that in of itself is also a bit of fun for me If only I had infinite time, and didn’t, you know, also have to make a living. hah

ednisley · June 25, 2025, 10:07pm

That’s exactly how I think about mine: it was the cheapest & easiest way to get a collection of parts that worked pretty much like a laser. I lusted after a Lasersaur, but realized I’d never ever get it finished …