Wrong project boundaries if relative coordinates are used

First day testing Snapmaker and I had already run into a conundrum. Everything seemed to be correct, but the machine was sometimes reporting completely wrong project sizes. It took me some time to figure out what the problem is, and I think I managed to nail it down to incorrect boundary calculations during import where the gcode includes relative coordinates.

Project: 40x10mm square, positioned at [0,0], with 0.5mm fill interval. The generated gcode uses G91 (relative movements) with X-40/X40 and Y0.5.

Import: when the file is loaded, the machine reports a size of “80.0 x 0.5 mm”. That is, it seems to only look at the numbers in the file, ignoring the fact that it is relative coordinates. So, the minimum coordinate detected is X-40, maximum X40 (making a diff of exactly 80.0), and Y only has 0.5.

Run: Boundary check goes indeed to negative X-40, but once it starts, the laser seems to positions itself correctly and move correctly during the run.

Is this just a bug in the FW (1.10.1) or is there something I am missing?

File:

; LightBurn 0.9.18
; SnapMaker device profile, absolute coords
; Bounds: X0 Y0.25 to X40 Y9.75
G21
G90
; Scan @ 100 mm/sec, 20% power
M106 P0 S255
M05
G0 X0 Y0.25 F0
; Layer C01
G91
M03 P20 S51
G1 X40 F6000
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X40
M03 P0 S0
G1 Y0.5
M03 P20 S51
G1 X-40
G90
M107
M05
G90
; return to user-defined finish pos
G0 X0 Y0 F0
M2

Import into Luban? If so, no one who’s been here long will be surprised to know of another defect in Luban.

1 Like

Lightburn uses relative moves in some modes, and I’ve never been able to run boundary in the touchscreen either. Not a huge loss since I can move the origin and just measure carefully,.

Apropos origin - when I open a file from USB, the origin is always reset to somewhere in the middle - is there any way to make it remember for the next time? I plan on making a contraption to make sure I always know where it is when I place materials, because I’m mostly going to be printing on pre-cut stuff and precision is of utmost importance. Any other suggestions to achieve the latter are welcome.

You could embed the necessary gcode in the file. Start with a g92 and set your own offset.

Lightburn allows generating gcode that starts at the current location, wherever that is. Could make use of that after issuing a g0 move to known coordinates in native space

The touchscreen will reset the work origin each time though. Letting it go to center is fine if the file moves the origin shortly after

1 Like

Do you print directly from LIghtBurn via USB? And it then moves exactly where it should on the canvas when you start the job? I guess that makes things easier with regards to exact placement.

No, you actually can’t do that either. Light burn is written for standard Marlin, which can accept a 254 character serial buffer. But that’s not what happens with this STM32 clone chip. It only supports four lines in the buffer. So what will happen is when the planner queue fills up and then no more commands get processed and then the serial queue fills up, The main controller will stop accepting new commands but light burn will continue sending them anyways because it’s expecting 254 characters.

Long story short it will break and probably in the form of motion will stop with the laser on in a single spot.

I suspect it would be easy to raise the serial queue length to fix that issue since this chip is not being taxed. But that’s just one of the things I haven’t been able to try yet.

Oh… even if you choose Snapmaker as the device?

Correct, if you’re interested in reading more on it, here’s the main Lightburn developer discussing: https://forum.lightburnsoftware.com/t/jobs-stop-after-a-short-time-20sec-1-min/630/4

I misremembered the length, it’s 127, but close enough.

I haven’t tried it with the absolutely latest release, there have been some snapmaker specific changes related to M9 with the generated gcode. I’m not aware of a change relating to the serial buffer for sending it, but it’s possible.

1 Like

So, I finally got to try this option, and it was much better. Imported into Luban, it was placed on the exact spot where it should have been and Luban calculated correctly the boundaries and everything (except for the preview). Even the fill was printed correctly.

One thing I noticed though is that the speed when executing a drawing from Lightburn is much higher than the when creating it within Luban. Are their scales different? Couldn’t find any discussion about that. Even when I put the speed to 10% in Lightburn, it seem to go much faster for instance around a circle (although, the latter might be due to different sampling rate of the arc).