Slic3r always inserts a G90 command after the start G-code to ensure absolute coordinates. However, I recently started to use relative extruder (E) coordinates, and therefore I added an M83 in my start G-code. The typical output from Slic3r now looks like this:
;- - - Start G-code begins - - -
…
M83; use relative E coordinates
…
M73 P1 ;@body (notify GPX body has started)
;- - - Start G-code ends - - -
; The actual print starts here
G21 ; set units to millimeters
G90 ; use absolute coordinates
M73 P0
G1 Z0.250 F8400.000
…
Obviously, the G90 does not cancel out the M83, or my prints would fail horribly, which they don't. However, gCodeViewer does assume that a G90 command will also reset the E coordinates to absolute. This causes the display to be messed up for these new G-code files, almost all moves look like retracts and the estimates are bogus. As a workaround, I now insert an extra M83 after the G90 that was inserted by Slic3r, but I shouldn't need to do this.
Here are examples of a file without and with the workaround: GCodeFiles.zip
My printer runs on Sailfish. I'm not sure whether this behaviour is the same across all printers/firmwares. If there are some that do switch back to absolute E when encountering a G90 command, there would need to be a way to discern between them.
Slic3r always inserts a G90 command after the start G-code to ensure absolute coordinates. However, I recently started to use relative extruder (E) coordinates, and therefore I added an M83 in my start G-code. The typical output from Slic3r now looks like this:
Obviously, the G90 does not cancel out the M83, or my prints would fail horribly, which they don't. However, gCodeViewer does assume that a G90 command will also reset the E coordinates to absolute. This causes the display to be messed up for these new G-code files, almost all moves look like retracts and the estimates are bogus. As a workaround, I now insert an extra M83 after the G90 that was inserted by Slic3r, but I shouldn't need to do this.
Here are examples of a file without and with the workaround: GCodeFiles.zip
My printer runs on Sailfish. I'm not sure whether this behaviour is the same across all printers/firmwares. If there are some that do switch back to absolute E when encountering a G90 command, there would need to be a way to discern between them.