I just had a nasty surprise with Lightburn. I created a job that deliberately had nothing at the work origin, but the first object to be lasered was offset. This was to align the job with the corner of the workpiece. I created the GCode as usual, loaded it into my Snapmaker 2.0, started the setup (focus, work origin), and after that did a “run boundary”. This traced the target area on the workpiece nice and correctly. Confident, I started the actual laser process, and was unhappily surprised by the first lines being lasered at the wrong place! So here’s a bit of post-mortem:
The job setup in Lightburn (ignore the white box - text is “confidential” 
):
From the laser job that messed up things here are the relevant GCode parts:
;Header Start
;header_type: laser
;file_total_lines:16875
;max_x(mm): 149.84
;max_y(mm): 207.15
;max_z(mm): 0
;min_x(mm): 58.11
;min_y(mm): 49.57
;min_z(mm): 0
;thumbnail:
[...]
;Header End
; LightBurn 1.7.04
; SnapMaker device profile, user origin
; Bounds: X58.11 Y49.57 to X149.84 Y207.15
G21
G90
G0 X0 Y0 F0
G91
; Offset @ 1000 mm/min, 100% power
M107
M05
G0 X6.793 Y1.462 F0
; Layer C00
G1 X0.068 Y0.185F1000 I S255
[...]
Noteworthy: Correct bounding box in header; G91 → relative positioning; First move to X6,793 Y1.462 → Close to the starting point and wrong!
Reason: Selected “User Orign” as “Start From:” value. I think this is the default setting, but I may be wrong here.
Problem is: Lightburn decides that the “User Origin” is the corner of the lowest and leftmost object:
So, I changed to “Absolute Coords”:
Resulting GCode:
;Header Start
;header_type: laser
;file_total_lines:16869
;max_x(mm): 149.84
;max_y(mm): 207.15
;max_z(mm): 0
;min_x(mm): 58.11
;min_y(mm): 49.57
;min_z(mm): 0
;thumbnail:
[...]
;Header End
; LightBurn 1.7.04
; SnapMaker device profile, absolute coords
; Bounds: X58.11 Y49.57 to X149.84 Y207.15
G21
G90
; Offset @ 1000 mm/min, 100% power
M107
M05
G0 X64.906 Y51.036 F0
G0 Z0
; Layer C00
G1 X64.974 Y51.22F1000 I S255
[...]
Noteworthy: Same bounding box in header; G90 → Absolute positioning; First move to X64.906 Y51.036 → This is correct!
So, just out of curiosity I tried the third option, “Current Position” (which does not make sense in my case as I do not control the Snapmaker directly via Lightburn, i.e. it is not connected to Lightburn in any way) - and also for current position it seems that the lowest leftmost object defines “Current position” - GCode:
;Header Start
;header_type: laser
;file_total_lines:16874
;max_x(mm): 91.73
;max_y(mm): 157.58
;max_z(mm): 0
;min_x(mm): 0
;min_y(mm): 0
;min_z(mm): 0
;thumbnail:
[...]
;Header End
; LightBurn 1.7.04
; SnapMaker device profile, current position
; Bounds: X0 Y0 to X91.73 Y157.58
G21
G91
; Offset @ 1000 mm/min, 100% power
M107
M05
G0 X6.793 Y1.462 F0
; Layer C00
G1 X0.068 Y0.185F1000 I S255
[...]
Noteworthy: Different bounding box (The reduced one - this would have warned me when doing “run boundary” as the area would have been wrong); G91 → Relative positioning; First move to X6.793 Y1.462 - which is correct in the sense of the file, but wrong for my aim.
So long story short: The “User origin” output of Lightburn is buggy - either they need to correct the bounding box, or the first move.
Another learning: I’ll use “Absolute coords” also for another reason in the future: When you pause a laser job that uses relative positioning, after hitting “Resume” the job is no longer working, as the Snapmaker switched to absolute positioning while running the pause sequence and did not switch back (at least this was the case a year or so ago). This results in funny starlike patterns around the work origin. So using the absolute coords should be safe from this problem - nice insight!
Of course in the end I am to blame: Had I looked a bit closer on the GCode preview in Luban (or perhaps understood what the green dot in Lightburn means), I could have spotted the problem - the preview shows exactly what happened. Which makes me once again think: Snapmaker introducing this stupid bounding box header was a mistake. Analysing the GCode and getting the real results from that (as it was before the header was introduced) would be the slower, but safer way. And the more compatible: “Run boundary” would work for any GCode, not only from programs that support the header.