So what I wanted to do is Z offset into the wood 0.02 inches per pass.
I set Z steps per pass to 0.02 in the job (Z offset at 0.000 still) , nothing happened. Remembering Z axis settings over in device. I turned on “enable Z axis” and ran the job again. The Z moved away from work piece about a half inch immediately after starting the job. I added “relative Z only” after looking here, that didn’t change what happened.
Ideas?
What is your Material thickness set to on the main UI / cuts panel? If you’re using relative moves, set that to zero.
was set to 0.000 from the start so thats not it
Post the LightBurn project file here and I can have a look.
new users can’t upload restriction. Just started from a new file and it did it again. One thing I am noticing is after I home, I hit the 'GetPosition" and it’s all over the place . Z after homing is 4.xx and after I get it to work piece it’s -0.45. After I start the job “From current position” , Z is now 0.000 … so it moved back by the -0.45 (X and Y honored the ‘from current position’ / didn’t move at all).
Please try again now.
If you have “relative Z moves only” set it should be recording the Z starting position and using that. Having said that, LightBurn was written to work in mm, but you’re running in inch mode, and GRBL controllers can be set to respond in either inches or mm. Can you post the value of your $13 setting? (that’s “report status in inches”). I’m wondering if maybe I’m expecting inches and getting mm, or vice versa.
Definately the GRBL settings are in mm and yet run in inches from our tools, Vcarve,etc but that has a post processor that “handles” it.
Here’s the whole $$
$$
$0=10
$1=255
$2=0
$3=2
$4=0
$5=0
$6=0
$10=0
$11=0.020
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=3
$24=25.000
$25=750.000
$26=250
$27=1.000
$30=255
$31=0
$32=1
$100=26.669
$101=26.669
$102=100.118
$110=8000.000
$111=8000.000
$112=2000.000
$120=500.000
$121=500.000
$122=500.000
$130=790.000
$131=790.000
$132=155.000
some experimenting with $13=1
Effect:
‘Get Position’ button = X: -0.335 , Y:0.264: Z,: -0.028
Console: <Idle|WPos:-8.4997,6.7089,-0.7099|FS:0.0,0|Pn:P|WCO:-22.5635,-28.4629,-4.5653>
If I move the Z in positive direction 1 inch:
Console: <Idle|WPos:-8.4997,6.7089,0.2901|FS:0.0,0|Pn:P|Ov:100,100,100>
Get Pos: X: -0.335 , Y:0.264: Z,: 0.011
Now, I tried using this anyway, and it did jump back to Z=0.00 before doing anything, but because Z was only slightly in the negative (wrongly), it was much smaller.
Still left with the only clue is Z being negative causes a move to what it thinks is position 0.00 before anything else. going to look at gcode itself, try to issue 1 by 1
here’s some thing weird. I played back the Gcode by hand, no problems. So ran a different test to ‘Save GCode’ and then ‘Run Gcode’ from the very same project that just did the jump back to zero. The GCode file is fine, it doesn’t do anything weird… there must be something ‘extra’ you’re sending that the ‘Save GCode’ doesn’t capture / save GCode version works fine
I have the same problem with my Open Builds Acro, running GRBL.
Z Axis makes a jump at the start of a job, no matter how you have things set. I have not yet installed my Z axis because of this. It also will not return to start (home) at the end of a job.
setback on the clue from this morning… while I did generate correct GCode with the correct behavior… I can’t do it again, nor did i save the lightburn file I was playing with. So not sure what magic buttons I pushed or sequence to get it to spit out correct behavior Gcode but I can confirm the GCode has an explicit move to “correct” the amount my Z shows negative. I’m attaching both. The bad version is what I get from the previously attached lightburn file, as well as a freshly created file
Both are simple squares (unforunately for comparison purposes they are not the same squares but otherwise the same)
GCode with expected behavior, generated once (notes added)
; LightBurn 0.9.02
; GRBL device profile, current position
G00 G17 G40 G20 G54
G91
M4
; Cut @ 10 in/min, 100% power
M8
G0X0Y0
G1Y0.7279S255F10
G1X0.6706
G1Y-0.7279
G1X-0.6706
**G0Z-0.0201 - OK**
G1Y0.7279
G1X0.6706
G1Y-0.7279
G1X-0.6706
**G0Z-0.0197 OK**
G1Y0.7279
G1X0.6706
G1Y-0.7279
G1X-0.6706
**G0Z0.0398**
M9
G1S0
M5
; return to starting pos
G0 X0Y0
M2
GCode generated from a fresh lightburn file, same 0.02 offset per pass (notes added)
; LightBurn 0.9.02
; GRBL device profile, current position
G00 G17 G40 G20 G54
G91
M4
; Cut @ 10 in/min, 100% power
M8
G0X0Y0
**G0Z0.274 <-- Jump Back (Z pos was -0.274)**
**G0Z-0.0004 <-- ???**
G1Y0.4417S255F10
G1X0.3491
G1Y-0.4417
G1X-0.3491
**G0Z-0.0197 OK**
G1Y0.4417
G1X0.3491
G1Y-0.4417
G1X-0.3491
**G0Z-0.0201 OK**
G1Y0.4417
G1X0.3491
G1Y-0.4417
G1X-0.3491
**G0Z0.0402 OK**
M9
G1S0
M5
; return to starting pos
G0 X0Y0
M2
On the console, type $? and hit enter, and copy / paste what outputs here. I’m wondering if maybe you have a Z offset.
Did you mean $#? Below. Why would that cause lightburn to generate a Z move in the opposite direction but exact amount of current negative Z position while ‘relative move only’ is set? Got distracted last night so didn’t get back to troubleshooting. may be a few days before I can get back to trying to recreate the one time it didn’t generate a Z jump
$#
[G54:-573.113,-722.958,-115.960]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
I am also having this problem with my Eleks A3 with a Z axis added. I don’t understand why it is making the jump. There is a lot of instructions to handle the X & Y axis setup, but almost nothing about the setting up the Z axis. Should the zero be all the way up or down, I think maybe there should be a section in the common configurations.md file that goes into more detail of the Z setup and configuration like the Z & Y.
It would also be nice to be able to turn on a debug option to see the actual stream the is being sent so we could get an idea where things are failing.
the ‘Save Gcode’ button is exactly what it sends. i was confused with my earlier post where one time ever it generated correct gcode without the two z moves i noted above. i just dont recall what settings i had messed with. it isn’t the obvious ones like ‘z relative only’…
Try setting “Reverse Z” in the device settings. I’ll add some logging to the part of the code that sets up the Z moves for the next version, which should be coming relatively soon. Part of the problem is that I simply don’t have enough machines to try all the possible combinations of setups that my users have; not easily, at least.
Having looked at the code a bit, are you running in “Absolute Coords” mode, or using “User origin” or “Current position” as the starting point? If you’re using the latter, I think I might know what’s going on.
Yes I always use Start From “Current Position”
Confirm that if I use 'Abosolute" , looking at G-Code the Z jump is not there compared to ‘User Origin’ or ‘Current Position’ Modes both generate the Z jump back to position 0 (current position being in -Z territory). Still don’t know how i created an expected Gcode from ‘current position’ once…