Z-axis programmed control in Lightburn

While troubleshooting weak burns, I modified the Gcode for steps in the process. Unfortunately, the first Z move (-24.000) drives Z up to the limit switch, no matter what polarity I use. I have toggled nearly every Z-related switch, and cannot get past this error.

Is there some way I can program to do this in Lightburn?

The attached .NC file is a snippet of the full program. The Lightburn file is the file I am trying to run. It is a manually created focus test where I burn a circle, step over and drop Z 1mm, and burn the next. With my eyes, those lines in the LB focus test were just not helpful.

Citcles Burn Test 1 - Zmove - Partial.nc.txt (4.0 KB)

Citcles Burn Test 1 - Zmove.lbrn2 (40.8 KB)

This is the alarm reported. The Z commanded move is well within the Xmax=294 Ymax=305 Zmax=37 cube.

I thought I had a solution when I read about the Run Gcode button in another thread. The alarm message attached is frim that test.

Circles Burn Alarm.txt (572 Bytes)

Always start from scratch …

  • Does it home correctly? I assume that means the Z axis goes upward, away from the platform, to the top of travel, and does the correct bump-backoff-bump sequence before stopping.

  • After that, do X and Y home properly?

  • What are the XYZ coordinates of the home position and where is the laser head with respect to the platform after homing?

  • Does the Z jog button move the head in the proper direction?

For simplicity, edit the file and discard everything below the first ; Layer Cut line.

In this command:


You depend on the interpreter to switch from absolute to relative motion in the middle of a command. This is semantically correct according to the LinuxCNC doc, but may run afoul of what actually happens in GRBL.

Per the LinuxCNC Best Practices suggestions:

Don’t put too many things on one line
Ignore everything in Section Order of Execution, and instead write no line of code that is the slightest bit ambiguous.

Move the G91 to a line by itself so it’s obvious to everybody, including GRBL, what you intend to have happen:


However, because the machine is homed and you (should) know the coordinate of the Z axis home position, there is no reason to use G91 relative coordinates.


  • What happens when you use absolute Z coordinates?

I know you have to ask, but we are way past motion issues. The machine behaves fine if I leave out Z commands.

When I left everything in Absolute coords, but with Z commands, it totaly ignored Z and ran thru the program, too high to burn. That is why I tried incremental.

GRBL 1.1f is very capable and the code arrangement is not an issue like it was on the o.9 release.

Having just learned about the Run Gcode button, I will go back to absolute and try that.
Thanks for pitching in!

If there’s one thing I’ve learned from a year of puzzle solving around here, it’s that everybody starts by being absolutely certain they know what can’t possibly be the problem.

So, when you say having the thing move incorrectly isn’t a motion issue, there’s really nothing more I can contribute.

1 Like

I understand completely!

In the meantime, I have been putzing around with and discovered an interesting result. It appears LB Run Gcode mode is not strictly pass-thru. The attached text file shows what I mean. Maybe @JohnJohn can investigate this for me.

Gcode Processing Issue.txt (2.5 KB)

I’m going to ask a couple of clarification type questions then take it to the Devs & CNC enthusiasts.

I’ve seen some home or set origin with a bed level probe so I feel that i’ve seen home-down more often than home-up.

Polarity is an alien term for stepper motors. When they’re 2 windings and (A, B, !A, !B) where A is the first powered winding and B is the Second powered winding and !A is the first winding with reverse polarity and !B is the second winding with reverse polarity… Reversing the ‘Polarity’ yields (!A, !B, A, B) which, is identical when repeated. To reverse direction on a stepper, you reverse one pair only. By reversing B we get (A, !B, !A, B) which, when repeated reverses the first pattern. :slight_smile:

It’s one of my favorite things about stepper motors.

To reverse the Z-Axis, there’s a switch in the Device Settings window, but that would change the perspective from the software not the ‘machine’. It would be like changing S-value max but not changing $30.

To invert the Z-Axis in the engraver you flip the boolean bit in $3=n by adding or subtracting 4. It’s similar to the homing direction mask $23=n which may also need to be reversed.

Here’s more about that, and the code is heavily commented and quite readable. grbl/doc/markdown/settings.md at master · gnea/grbl · GitHub

That’s my best scientific hunch. :wink:

I’ll ask the team for a sanity check.

My reference was to Gcode, not axis direction. Motion control is just fine, and does not need fixing. What I said was Z goes plus no natter what the sign of the Z command. No matter…

I discovered the Run Gcode is not a true pass-thru mode. LB parses the file and changes the output, which can be captured in the Console Window. It also ignores Z commands it did not put there. I put in a Feature Request for this. With the number of 3-axis machines out there, it might get some attention. Add a true Gcode pass-thru option · LightBurn

In the meantime, I guess I will have to use LaserGRBL for this particular applocation. Then I am back to Lightburn!

Did you attempt the change to $3?

No, the machine runs fine without messing with the parameter masks. When I run something that has multiple passes and steps, it will move, run the path, step down Z increment, run path, retract to Z start, move over and repeat. Imagine small circles across the X axis. Based on this proper procedure, I should not mess with the parameters.

I haven’t seen this behavior. Can you upload a sample gcode file where this happens? I’d like to reproduce the issue.

I haven’t been following this Topic very closely but I’ll review it more carefully in a bit. What stood out to me is the comment that sign makes no impact on z travel. That’s confusing to me and makes me think there’s something else going on. That should be handled entirely in the controller so should not behave differently between applications.

1 Like

I will get together the files that demonstrate the suspect activity and upload them in the morning. I ran a bunch of different tests and will have to pick the right ones. Thanks for asking!

When you get a chance, can you run these commands in Console and return results? I’d like to understand current state of offsets and position after homing:


Once homed, can you jog the Z axis midway between home and the bed. Then can you run these commands in Console? What happens for each?

  1. G91 G0 Z5
  2. G91 G0 Z-5

I will include the $ commands. I can tell you what G will happen, it will do as you expect, but I will do and document like you ask. I would be asking the same questions to understand the scope of the issue.

Feel free to ask for more detail. :grin:

You guys are going to hate me for this. I took the LB file and did a Save Gcode.
Circle Test.lbrn2 (120.8 KB)
Then I ran the .NC file to make sure it ran the same. I then edited the .NC file, adding the Z moves and comments.
Circle Test.nc - Z-move ABS.txt (5.1 KB)
I then ran it, fully expecting it to fail. You probably already guessed what. I ran exactly as it should have.

So I spent two days wasting my and your time on this. My only answer is that a recently deceased family member was having fun at my expense. Believe it or not, this is not the first time.

Thank you for all your attention and I apologize for the disturbance. Now I am back to what started all of this in the first place, low laser power output. Taking bets on this working now?


Glad you’re sorted.

I’m looking at the gcode and curious what you’re trying to achieve with this. Are you trying to use this to focus on materials of varying focus? If so, are you aware that LightBurn can do this for you? If you disable Relative Z Moves Only and set the material depth for each material LightBurn will adjust for the depth.

Alternatively, you can use Z-offset in the cut settings to adjust depth for a given layer. This can be done with or without Relative Z Moves Only.

I did the LB Focus Test, but got lines of almost equal density. My circled test is easier to view with my eyes. It is 15 circles, each from a different height. I keep increasing speed until one circle is complete and the others look poor. If I get two good ones at the end, then I go to 0.25mm steps and continue increasing speed. Obviously, if I hit the speed limit, I start reducing power.

I still have to determine if I have a power loss, bad TiO2 procedure, or strange 6" tiles. Oh joy! Glad this is not a production machine! :hugs:


UPDATE: A grey painted tile I had properly fused lines onto the surface did not fuse with my latest test. Looks like I need to drag out the test equipment and start taking measurements. More oh joy!

I need help from a 5.5w diode laser owner. It the laser power pins I am getting 2.95vdc to the laser at zero power after hitting the test button. It gradually discharges down to less than a volt… At 20% power, it goes to 3.02v. When I press the test button on the control module, or command a feed at S1000 power, it goes to 4.93v max. Input to the controller module is a steady 12.36 volts.

I thought these were 12 volt laser modules. If so, I am only getting 50% power from the controller module at Smax. I have an identical laser, with a bad dot pattern, that I ran at 10v, 2a for several seconds.

Anybody know if these values are correct?

The laser power line will be 12V to ground.

However, the intensity of the laser is controlled through PWM on the signal/pwm pin. This is typically based on 5V TTL or 3.3V depending on the driving circuitry. Arduinos use 5V logic and most 32-bit MCUs will use 3.3V logic.

PWM is based on duty cycle. So the logic voltage is 5V or 3V but they duty cycle determines power level. So 100% duty cycle on 5V TTL will result in a measurement of 5V on a typical meter. If you were to look at this through a scope you would actually see a 5V signal at 100% duty cycle. Similarly, 0% duty cycle should read as 0V on the meter. 50% should read 2.5V.

This indicates a potential issue with power scaling.

What are your $30, $31, $32 values? And did you measure these voltages with the laser in motion or still?