Problems with Example scripts from docs.octoprint.org

Get Help
1

Hi experts!
I'm using Octoprint since I've got my new Ender 3 printer. Before that I was working with Repetier Server so I'm quite new to Octoprint.

What is the problem?

I've found the example scripts on docs.octoprint.org. I copied the scripts of Listing 6 (afterPrintPaused) and Listing 7 (beforePrintResumed) to my octoprint.
Listing 6 seems to work fine:

{% if pause_position.x is not none %}
; relative XYZE
G91
M83

; retract filament, move Z slightly upwards
G1 Z+5 E-5 F4500

; absolute XYZE
M82
G90

; move to a safe rest position, adjust as necessary
G1 X0 Y0
{% endif %}

but with Listing 7 I have a problem:

; relative extruder
M83

; prime nozzle
G1 E-5 F4500
G1 E5 F4500
G1 E5 F4500

; absolute E
M82

; absolute XYZ
G90

; reset E
G92 E{{ pause_position.e }}

; move back to pause position XYZ
G1 X{{ pause_position.x }} Y{{ pause_position.y }} Z{{ pause_position.z }} F4500

; reset to feed rate before pause if available
{% if pause_position.f is not none %}G1 F{{ pause_position.f }}{% endif %}
{% endif %}

Normally I use this pause to change the filament. When I do this I use the extrude and recect function of octoprint to get the old filemanent out and the new in. E.g. I retract the filament for 400 to 500 mm, until I can get it easily out of the extruder, then I extrude the new filament it maybe for 550 or 600 mm, until all the rest of the old filament is out of the nozzle.
The problem is that the printer remembers all extruder movements. When I'm ready with changing the filament and click on "Continue", the extruder compensates for all these different paths again, so that the filament is pushed back much too far when it starts printing again.

What did you already try to solve it?

I deactivated the line ;reset E

;G92 E{{ pause_position.e }}

But this has no effect...The filament movement after the restart is still executed.

Additional information about your setup

OctoPrint version 1.4.2; Octopi Version 0.17.0; Ender 3; different browsers

2

You might consider adding a G91 line in to switch the positioning back to relative motion at the beginning. That appears to be the difference between the two.

3

The problem with these examples is that they assume (or ignore) the absolute/relative status of the X, Y, Z axis and the extruder (E). Unfortunately, Marlin doesn't provide any commands to determine the current absolute/relative state and it can vary depending on the slicer used (or the slicer settings).

I'd like to see the examples have some comments added which state the assumed states or better yet, optional code for each state.

For the issue at hand, the gcode produced by the unknown slicer needs to be examined to determine the states used. My guess is that the mainline gcode is using relative E so when listing 7 blindly sets absolute E (M82), chaos ensues immediately upon resuming the mainline gcode.