You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: