Bounding box or first move wrong when using "User origin" (LB 1.7.04, Snapmaker 2.0)

HaukeDE · December 21, 2024, 9:07pm

I just had a nasty surprise with Lightburn in conjunction with my Snapmaker 2.0. 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 you need to correct the bounding box, or the first move.

MikeyH · December 21, 2024, 10:10pm

Are you thinking this means current position in Lightburn? In Absolute Coords or User Origin, Lightburn creates the code from a known location. with Current Position, neither Lightburn nor anyone else except the laser knows where the laser head is located. Lightburn issues no motion commands prior to starting the burn. So being connected means nothing because you told it to start burning no matter where it is located.

Not exactly, you told it by using those little round buttons under the Start From selection. Those positions refer to the bounding box of the selection.

I have added the links below to help you understand how the various coordinate system work (very well in my experience).

Here is an excellent video by @thelmuth worth watching about 5 times…

HaukeDE · December 22, 2024, 4:48pm

Thanks for pointing me to the explanations, and I’m the first to admit that part of my problem is my ignorance
Still, in one point I’d insist on my point: The bounding box in the GCode header should match what’s actually happening in the GCode - so IMHO it is a bug that the bounding box comment is not where the laser operation actually takes place.
This may be a pure Snapmaker issue - I’ve honestly no idea if the bounding box comment lines are in any way universal and other machines evaluate them, or if only Snapmaker uses them.

MikeyH · December 22, 2024, 5:23pm

Some controllers do not use the Lightburn FRAME command because Frame is built into the controller. I do not know if this is true for a Marlin controller. However, the bounding comment should match what Lightburn uses when it does a Frame. I would be very surprised if any controller uses a free text comment line for an operation. There is no standard for comments except they start with a semicolon and have limited length.

Frame is just a short Lightburn program sent to the controller, like a macro. Assuming you are not messing with the coordinate systems, Frame should go where the screen says it will go. Have you played with the Circular Frame button?

HaukeDE · December 22, 2024, 8:33pm

So - be surprised Snapmaker did this… They seem to rely on these GCode comments (which I guess is definitely not one of their clever ideas):

;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

And the FRAME command I think is unknown to Marlin (I may be wrong here…)

No, never came across this… And did not mess with coordinate systems.

As I said: I’m reasonably sure that there is the bug - and if you look at the Gcode I posted in my starting post (which is the complete first lines except for the base64 encoded thumbnail which I cut out), you can see the wrong lines - on the one hand the mentioned header lines, but also the comment line ; Bounds: X58.11 Y49.57 to X149.84 Y207.15 has the same wrong values.

MikeyH · December 23, 2024, 2:21am

You have me at a disadvantage, I do not have access to a Marlin controller. So forgive me if I ask the wrong questions.

I looked at that GCode output again and have some questions:

That listing looks strange, especially with the color in the formatting . Is that an output from Lightburn or is it retrieved from the Marlin controller?
Your Lightburn has a Save GCode button near the Start button. Can you save the GCode using the program from above to a .NC file and upload it here?
I would expect both sets of comment lines (both listings) to contain the same bounds info.

Not to be rude, but I think you are still struggling with the coordinate systems. It is often recommended that (1) Home switches are used, and (2) Absolute Coordinates are used except when using a rotary… I once worked with an engineer that broke a 2" boring bar on a $280K machine because he wanted to use incremental positioning.

When I get a chance, I will print out the entire thread and study it closely There are a lot of Marlin users out there. If this is a bug, I am pretty sure it would have appeared in text by now I searched for anything Marlin, quit after about 100 postings).

HaukeDE · December 23, 2024, 9:30am

Color fomatting is done here by the discourse forum syntax highlighting - the file is plain text GCode. What you see is straight outta LightBurn “Save GCode” button. I do not have my machine connected directly to Lightburn - I always save the GCode, transfer it to the machine and let it run self-contained with its own controller.

So, for playin’ around yourself, here’s:

The project file: ErrorDemo.lbrn2 (16,4 KB)
The Absolute Coords output: ErrorDemoAbsoluteCoords.nc (197,8 KB)
The User origin output: ErrorDemoUserOrigin.nc (176,3 KB)

I used this online GCode viewer to simulate the outcome.

Absolute Coords:

User origin:

So you can see that the User Origin file does not have the long move that offsets the starting point from the origin. Which is fine - no probs with that. But I guess it is obvious that the bounding box is a different one between the jobs. However, the GCode contains the same bounding box.

Oh, and this is definitely not a Marlin thing - this is all Lightburn.

MikeyH · December 23, 2024, 3:43pm

Thanks for the files. I will review to see if I get the same results. Maybe someone with a Marlin can also jump in.

MikeyH · December 26, 2024, 8:49pm

No, the bounding box will be the same because you have the same 2 elements selected. If you select only the “L” or the “4”, the bounding box will change.

If you select Absolute Coords, The starting point is at 0,0 (if you Homed the machine there) because you told it to do that. It found the “L” first and did that one first (this is not always the case). If you select Current Position and select the upper-right Job Origin button, it will start at the upper-right corner of the “4”, as is expected.

I fail to see anything wrong with Lightburn. If you disagree, please provide more detail on what you are observing.

HaukeDE · December 26, 2024, 9:01pm

With Absolute Coords and with Current Position boundig boxes are correct, with User Origin the bounding box is wrong.

MikeyH · December 26, 2024, 9:42pm

I cannot test this because my machines are 1000 miles away. Maybe someone can jump in and test this claim?

system · January 25, 2025, 9:42pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.