Hello there,
as a reseller of LB we sell a quiet a few licenses and use LB in our lasersystems a lot - but we have a more and more customer asking about z-axis control for galvo lasers.
We always told them that this feature would come at some point… is there any information about when it will be possible to control Z ?
Cheers =)
It’s actually relatively trivial to support Z height control, but the problem is that the moment I do that basically everyone will complain that you can’t change the Z height during a job, like Z height per pass, or Z offset, like you can on DSP controllers.
The reason that won’t work is that EZCad machines don’t accept external motor movement as a command in their “streamed” job handling, so we would have to run jobs more like we do with rotary, where we send, wait, move the axis, and repeat. LightBurn is not set up to do that, so it’s going to mean some very significant changes to the code to support it.
I don’t have a timeline for this, but it is planned. I’ve done the work already for basic Z height control, jogging, and focus, but not the Z moves in a job.
Hello Oz!
But i just meant the basic Z-height control. Will you release it when all work is done or will the basic z-height control come first ?
At the moment we sell most systems with EZ3 because of missing Z-Height Control, they are mainly all closed systems with saftey covers where you cant reach the column to adjust the height manually.
I understand your problem with the dynamic Z.
Are the BSL controller better for stuff like that ?
We have some sample boards and consider to switch from JCZ o BSL … but did not test them yet.
Mainly just because the customer can use Lightburn and also the BSL App when he needs more axis control (like X or Z).
And they also support multipoint field correction which is also a thing which is important for industrial user, never managed to use a 25-point .cor in Lightburn with success.
Thank you for you work !
The 25-point CORFile has a very different format than the normal one, which is why it’s not supported yet. They take the points and generate the correction table on the fly, so we’ll have to figure out how to do that.
BSL cards do allow for a motor movement sequenced into a job, however LightBurn doesn’t support that yet because it will change how things like the rotary system works, and I want to do it for all devices at the same time, instead of having to support both methods simultaneously.
BSL cards don’t allow me to programmatically zero an axis - I can send it a “home” command, but I can’t just say “where you are right now is zero”, so they have some limitations of their own.
My intention was not to release Z jogging and control for galvos until I was also able to support Z movement within a job, but I’m willing to be argued with about it. 
Hello Oz, thank you for your detailed answer.
With the BSL cards, can’t you wait for a port signal change and then reference the current value (whatever that is) as NULL?
A “hardware” ZERO actually only makes sense when used with limit switches.
You can probably set a software zero within Lightburn at any time or not? So whatever reference value you have - or is there no reference from the controller side ?
I’m not a programmer and if I talk nonsense please don’t take it against me =)
I understand that you want to release everything at the same time, but layer shifting within a job is not supported in Ezcad2 (only in Ezcad3) so just being able to move the Z axis at all would be a significant benefit for the user.
I am convinced that this missing function causes many people to buy systems with Ezcad3 and not use Lightburn.
We do the same thing here, we currently have to deliver 35% of our systems with Ezcad3 even though we don’t actually want it but the customers want a Z-axis that can be adjusted in the software.
Sooooo please free us from the evil ones and release it ! =D
Any news or timeline on this ? 
I know there was a lot of time consuming work on the new framework the last months but maybe there is some process already when it comes to Z Control ?
I think with BSL cards they just assume zero is where they are on power up. With JCZ cards, I can send them a command that tells them “where you are right now is zero”, so I don’t have to track it internally.
I could just track it internally for both, but with the JCZ cards it’s handy when in repeat marking to be able to keep resetting the zero position, so I don’t have to “rewind” the motor after a few runs.
I have Z axis moves working for JCZ cards (and could do it pretty easily for BSL as well), but I need time to make the changes to allow for streamed commands with JCZ, or the deluge of support emails asking where the Z-move per pass option is will be obnoxious.
I also don’t actually have a machine with a controlled Z axis connected to the card, so I have to keep modifying one to verify the code, and I need to figure out where I want to add the Z move buttons to the UI. Suggestions?
Hi Oz,
I understand the issue with the zero point. I assume that with JCZ cards you’re getting step feedback, so you always know where the motor is. But wouldn’t it be more straightforward to implement a software zero that maps to the current real position (as you mentioned), whether the controller provides that position or not?
From my perspective, using a controller-based zero (like the actual hardware origin) is fine, but I don’t really see a major downside in using a software-defined zero instead. It would remove the need to “rewind” the motor just to reach hardware zero again. JCZ likely uses this for the XORG pin, which sets zero via hardware - but I imagine that pin could also be read and interpreted in software?
A consistent software-zero approach might actually be easier for you to maintain across different boards.
As for Z movement per pass… that would be fantastic. But please keep in mind that many users still buy EZCAD3-based boards only for Z-axis control. In almost every enclosed laser system, a motorized Z-axis is essential, because the manual focus crank is usually difficult to reach and in automated setups, it’s non-negotiable.
Here’s how I would prioritize Z-axis support features:
1. Input field for part height -> auto Z-focus
2. Zeroing via hardware pin (for homing)
3. Z-height per layer for engraving at different levels
4. Axis-to-motor mapping
5. Z-height per pass
Motor-to-axis mapping would open up a lot of powerful use cases: XY tables, switching between rotary and Z-axis when only one physical output is available, etc.
For the UI, a dedicated “Z” tab could make sense, or alternatively, Z-controls could appear under the Laser tab when enabled.
We almost exclusively sell enclosed systems - open systems are rarely feasible in Germany due to regulations. That’s why we’re still forced to offer EZCAD3 to customers… and honestly, I’m ashamed to even suggest it…
Please Oz free us from EZCAD3. 
If we can help let me know !
This will happen soon ™
Hi Colin,
now you’ve really put me in a tough spot 
and I’ll tell you why:
We actually want to sell only LightBurn to our customers, but the problem lies with the controller boards.
In our standard systems, we need at least one rotary axis and one Z-axis.
That’s why we’re currently using DLC2 boards with EZCAD3, or LMCV4 boards (but without LB).
The simpler JCZ boards (like FBLI) only support one axis, which is exactly why I brought up the idea of motor-to-axis mapping.
Having more axes (X, Y, Z, A) would be a big step forward. The EZCAD3 (DLC) board can technically handle it but we really want to avoid using EZCAD software.
That’s why I’m so hopeful LightBurn will support this in the future.
So… have you managed to “crack the encryption”? Will EZ3 boards be supported soon?
If yes, we’ll switch to using only DLC boards going forward.
Even better would be an GCODE controller like the one from HALaser but I know that’s probably asking too much at this point.
Something with at least two axes would be amazing.
Support for four axes would be a dream!
I’ll send you a DM
Not quite - The hardware has a limit to how far it can go, and it’s possible to hit that limit with repeat marking.
If you’re using repeat marking with a rotating plate with 6 items on it, and you run a full “circle” of them, when I’m done marking the 6th one I can either “rewind” the plate back to zero, or go forward 60 degrees, which is now an angle of 360. With JCZ cards I can just tell them “now this is zero again”. The moves are sent in absolute step location, so if you have a high number of steps per rotation, like 128,000, and you run parts all day, you could feasibly exceed the maximum number of steps I can tell the card to move.
12,800,000 would be 100 rotations, at 128,000 steps per rot.
I think the maximum I can send is 16,777,215 (24 bits)
If I try to send a move that exceeds that, it’ll wrap around, and go all the way back to zero, so the user would have to sit there and wait for the card to rewind all the way.
I could make the repeat-mark system know about this, and just rewind the BSL cards back to zero, but it’s annoying to have to do that. 
#3 has the same problem as #5 - It requires sending a Z move “mid stream” which doesn’t play nice with the way we generate jobs for the machine.
When we get to EzCad3 support it’ll be feature parity with current LightBurn, no 3D yet or dynamic focus, but over time…
Hello Oz,
okay, I understand the issue, but are you sure there’s no way to send a zero signal to the BSL board?
You’re of course much more familiar with the details than I am, but the BSL boards also have hardware pins for setting zero points.
So there must be some logic to handle that, at least that’s what I assume, based on the presence of those hardware pins.
The BSL card will zero using external limit switch pins, moving the card until it hits a stop, but according to their engineers I can’t just tell the card “where you are right now is zero”, which I can do with JCZ cards.
Hello Oz,
I get your point, they probably know better than I do.
I was just wondering because of those pins. I’d assume there’s some kind of command for it, since that’s what those pins are meant for… right?
Pin triggered = Set zero
But in China you never know 
That’s what I mean though - The pins are to zero the card, so I can send the command to trigger the zeroing function, but I can’t just tell the card it is currently at zero. It has to actually move and bump a limit switch.
Okay, thanks for the explanation.
If this really can only be done physically via the pin, and there’s no way to simulate it without actual movement, then unfortunately things aren’t looking too good for the BSL boards, unless you always move the motor back, as you mentioned.
In that case, absolute and relative step matching doesn’t make much sense either, since you’re constantly at risk of exceeding the max step range…
So… not that good 
Maybe you should consider developing your own hardware, that would be amazing!
I really hope things will become more flexible once G-code-based boards for galvo systems are supported.
It’s honestly quite difficult to find good, reliable hardware for Galvos …
They have enough work with software, and you want them to get into the hardware business? Really!!! 
When Hardware is limiting your software, why not. I think the building the software ist more difficult than hardware. We would buy it 
