Marlin: [2.0.X-bugfix] Printing at wrong height after [Pausing] -> [G28] -> [Resuming] a print

[AcHub]

Description

I was pausing a print in Octoprint after a few layers and then re-homed XY with G28 X0 Y0. This makes the printhead to raise about 2mm and then home as expected. But when I resume the print, the printhead continues to print at the elevated height, instead of lowering back down to the level where it printed before, making the print useless.

Steps to Reproduce

1. Start a print with Octoprint
2. Pause the print with Octoprint
3. Home XY with the Command-Tools in Octoprint / Send G28 X0 Y0. The printhead will raise ~2mm and then home.
4. Resume Print. The Printhead resumes printing without lowering ~2mm.
5. Fail to resume at correct height

Expected behavior:
When resuming the print, the printhead should be moving to the correct XY position for continuing the print and then be lowered back to the correct height before continuing the print.

Actual behavior:
Resuming the Print does not lower back to the print-level.

Additional Information

Printer is running on 498a328 (May 26).

config 27.5.18.zip

Terminal log from Octoprint:

Send: N2425 G1 X89.256 Y85.100 E0.0094\*98
Recv: ok
Send: N2426 G1 X103.925 Y99.768 E0.7176\*82
Changing monitoring state from "Printing" to "Pausing"
Recv: ok
Send: N2427 M400\*20
Recv: ok
Send: N2428 M114\*27
Recv: X:103.93 Y:99.77 Z:0.20 E:41.67 Count X:8318 Y:7985 Z:77
Recv: ok
Changing monitoring state from "Pausing" to "Paused"
Send: G91
Recv: ok
Send: G28 X0 Y0
Recv: echo:busy: processing
Recv: X:0.00 Y:0.00 Z:2.00 E:41.67 Count X:0 Y:-394 Z:801
Recv: ok
Send: G90
Recv: ok
Changing monitoring state from "Paused" to "Printing"
Send: N2429 G1 X104.241 Y99.518 E0.0139\*90
Recv: ok
Send: N2430 G1 X89.508 Y84.785 E0.7207\*111
Recv: ok

[cdedwards]

I can verify this occured to me as well. I did this twice on the same print. The first time, everything worked as expected.. The second time, printing resumed at MAX delta height, causing some issues with my mechanical endstops.

[thinkyhead]

Marlin doesn't know that a print is being paused and resumed; it's simply interpreting the commands being given by the host. Since typical G-code doesn't contain the Z coordinate in every G1 there's no way the firmware knows that it should move back to some previous Z. There are a few possible solutions:

• Don't home with G28 but simply use G1 X0 Y0 F6000. If a Z raise is desired, it should be done in relative mode with G91;G1 Z2;G90 and before resuming the print, a relative Z lower should be done with G91;G1 Z-2;G90.

• Home with G28 X Y R0 which will not raise the nozzle

• Home with G28 X Y R2 so the raise is predictable. Then do G91;G1 Z-2;G90 to lower the nozzle before resuming.

• Enable PARK_HEAD_ON_PAUSE and use the M125 command to pause from the host. Make sure EMERGENCY_PARSER is enabled so you can resume with M108, otherwise you must resume with the LCD controller.

[thinkyhead]

@MarlinFirmware/host-software-team — Just a note that since G28 X Y might do a raise depending on its configured behavior, and some may want to use this command as part of pausing a print, the host should remember the current (last sent) Z position on Pause and return to that Z position as part of Resume.

Also, as noted in my reply above, M125 is available if the firmware has PARK_HEAD_ON_PAUSE turned on, and can resume with M108 when EMERGENCY_PARSER is turned on. When both of these options are enabled, we could expose a capability so hosts could use these commands for pause and resume, along with the print job timer stop/start commands.

[foosel]

For the record, OctoPrint already records the position of the print head before executing the pause script. If OP had reset X/Y/Z positions in their resume script using that information as documented there probably wouldn't have been an issue - the above log doesn't look like this was the case though, explaining the observed behaviour.

[cdedwards]

I was printing from SD card and therefore used the LCD pause/resume function. my USB serial function is too flaky with the rearm board to print from a host.

[AcHub]

For the record, OctoPrint already records the position of the print head before executing the pause script.

Am I getting you right @foosel, Octoprint will resume at the correct position by default? Because I didn't change any settings regarding the pause/resume behaviour of Octoprint. And pausing -> G28 -> resuming within Octoprint did work as expected before (before means like months ago with some older version of a 1.x Marlin firmware)

[foosel]

@AcHub No, not by default (the reason for that is that is explained in the docs I linked), but it can be configured to do so.

Just pausing/resuming without any kind of position recording and such will work in most cases, but in case of e.g. a G28 that modifies the Z value, it won't (since as already mentioned your GCODE file doesn't contain Z coordinates on every line).

E.g. consider the following pseudo GCODE:

G0 X1 Y2 Z1
G0 X2 Y2 
G0 X2 Y1

Let's see what happens if you pause without a pause/resume script:

• G0 X1 Y2 Z1
• You pause
• You do whatever you need to do, leading to your print head now being somewhere else in X, Y, Z
• You resume
• G0 X2 Y2 <- this moves from wherever your print head was before you resumed to X2, Y2. Z is not changed

• G0 X2 Y1 <- this actually continues the print

  You've effectively skipped a line in the printed model and also the Z coordinate is now completely out of whack.

Configure a pause/resume script, that's the only proper way to pause/resume. Because that will boil down to this sequence of event instead:

• G0 X1 Y2 Z1
• You pause
• OctoPrint records the pause position and makes it available to your pause GCODE script
• Your pause script gets sent to the printer (e.g. retract, move to X0 Y0)
• You do whatever you need to do
• You resume
• Your resume script gets sent to the printer (e.g. prime, move to X, Y, Z from pause position, restore T, F and E)
• G0 X2 Y2
• G0 X2 Y1

Now the second line actually gets processed with the origin point from which it should be processed, and on top of things your Z is the correct one as well.

[thinkyhead]

In the case of SD Card pause / resume, when the PARK_HEAD_ON_PAUSE feature is enabled, pausing from LCD or with M25 invokes M125 to move the carriage to the configured park position. Resuming from the LCD or with M24 will move the carriage back to where it was when resuming, and it should not be bothered by any movement in Z during the pause.

[cdedwards]

speaking of which.

define NOZZLE_PARK_POINT { (X_MIN_POS + 10), (Y_MAX_POS - 10), 20 }

this is not a good place to park a delta while printing. I know kossel XL at least has this for a parking position.

[thinkyhead]

this is not a good place to park a delta while printing

Now patched to park on the left side.

[cdedwards]

I was thinking more the height. 20mm above the bed no matter where it is on the bed is a lousy place to park. If it’s relative it might be ok but could cause issues near max height

[thinkyhead]

The Z value is relative, and constrained to avoid going past the top.

[boelle]

@AcHub is this still an issue?

[boelle]

@thinkyhead think we can close this one

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.