Absolute vs incremental mode, and transfer method

Just wondering if the choice to use absolute or incremental Gcode is user settable. I couldn’t find it if it does exist. (I’m using a Cohesion3D LaserBaord with Smoothieware.) I know from looking at the Gcode the particular job I’m doing, (a power scale test with a grid of filled boxes), does a G90 absolute mode move to the start position and then switches to G91 incremental to scan the lines. A reasonable choice but the problem I have is that very occasionally some kind of communication issue causes a single line to be lost. This will throw the rest of the job out by the length of that particular line, (if using the recommended buffer transfer mode). If this was running in absolute mode entirely then the missed line would cause an imperfection, but would likely be unnoticeable.

I’ve read a good explanation of LightBurn buffered vs synchronized transfer modes, and the Smoothieware and GRBL sites, but then the choice becomes speed vs reliability. I haven’t yet found an answer to what happens if LightBurn sends a line in synchronized mode but never receives an acknowledgement. In buffered mode it just runs to the end of the program and then remains Busy as it’s still waiting for the one missed acknowledgement. Switching to synchronized isn’t going to ensure that lines don’t drop but will handle them differently and it would be nice to know how.

EDIT: So it looks like G90/G91 moving to start is dependent on Start From being Absolute Coords or Current Position. I always use the latter. And the scanning is done using G91 regardless.

Relative positioning is used during scans because it generally makes the GCode more compact, reducing bandwidth.

LightBurn assumes that the transfer is perfect, which might be slightly naïve, but not many of these boards provide a retry mechanism, and if the returned OK response was what failed, instead of sending the command itself, a resent command would cause similar issues to the dropped one, so maybe that wouldn’t matter. USB protocol includes error correction and retries, so as long as the micro on the other end doesn’t miss data, it should actually be robust.

LightBurn also does not send one line at a time - it sends batches, and if a character or two drops, it would scramble the whole command and cause GCode interpreter errors, possibly locking the board, so it’s not unreasonable to assume that it has to be perfect or you should simply abort.

I’ve considered making fills or image engraving in absolute mode send a single G90 / absolute move at the start of each line, then flip to relative for the remainder of the line, as that would have the benefit of making the GCode more easily editable and partial code could still be run. The reason it’s done the way it is with ‘Current Position’ mode being entirely relative is that stored / saved GCode can be run from a different spot easily if you were to choose to - move the laser head and re-run the same file and it lands in a different place. That said, I doubt many people use it that way, but that was the intent.

Thanks Oz. An excellent answer as always. Pretty much confirms what I thought was going on. I think I’ve gone about as far as I can getting perfect USB transfer so I’m going to draw a line through this to-do item and move on the next. It’s not a regular occurrence so I’ll learn to live with it if it happens again.

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