I noticed that for some reason, after pausing my print using Octoprint, my prints have a layer shift of about 1.5mm in the x-axis (and maybe a very slight one in the y-axis as well).
What did you already try to solve it?
I changed the default "After print job is paused" Gcode to set the pause position of the nozzle to X10 Y10 instead of X0 Y0. This didn't result in a layer shift, so it seems to have something to do with the home position.
Have you tried running in safe mode?
Yes.
Did running in safe mode solve the problem?
No, safe mode gave the same result: a layer shift when using X0, and no layer shift when using X10 Y10.
The pause/resume scripts are the default OctoPrint ones, I have not changed them (besides the check for X0 and Y0):
Pause:
{% 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 %}
Resume
{% if pause_position.x is not none %}
; 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 %}
These scripts make an assumption about the relative / absolute state of the gcode file being printed. If the assumption is incorrect, then they won't work as intended.
If you don't know what state your slicer is using, slice a small object like a 5x5x5mm cube and post the gcode file here so we can help you figure it out.
Yes, the gcode file uses absolute coordinates and absolute extruder.
I think the next step would be to enable serial logging in OctoPrint and print that 5mm cube with a pause so we can capture the layer shift. You can upload the serial.log or create a bundle and upload that.
I printed the small cube, and it turned out fine. I only paused the print for about a minute or so, while I noticed that my shifted prints had been paused quite a bit longer. I'll see if I can create a log of the layer shift of a bigger print that has the issue.
Well, the small cube didn't have the layer shift, so that is not really useful. And I presume the only part of the log that is useful are the lines regarding the pausing and resuming, right? I can find those easily enough.
The pausing of the small cube is around line 2300, the pausing of the larger print is around line 32260.
As far as I can see, the saved coordinates are the ones that the print returns to after resuming,.
The pause is me simply hitting the Pause button in Octoprint, or did you mean something else? And indeed, the larger print had the layer shift.
I don't have any plugins related to the pausing, and the shift happens even in safe mode. It is almost like Octoprint uses the wrong coördinates, like all x-values should be ~1.5 lower, but it also doesn't look like the offset happens gradually over time, because I can trigger the layer shift at layer 10 and at layer 100, and both seem to be 1.5mm.
I also checked and re-tensioned my belts, but those were pretty well tensioned to begin with. I also checked if the x-stop has any give or shifts, but that is pretty solid as well.
I mean, I could easily fix the problem by just changing the pausing position to X10, but I'm kind of worried that an issue regarding the home position is indicative of another issue..
I re-read your initial post and if I understand correctly, there is a layer shift when the pause point is 0,0 but there is not layer shift when the pause point is 10,10. Is this correct?
You haven't given us any details about the printer. Model? Firmware?
Is it possible that moving to 0,0 triggers endstops? On my LulzBot TAZ 6, if I ask it to move past the endstop, triggering the endstop stops the move and the printer loses track of the position.
Since the comments in the pause script say adjust as necessary, you did that and the problem went away. Why isn't that the solution?
I'm using an Ender 3 v1 with an SKR Mini e3 v1.3 board running Marlin 2.0.1.
I'm asking this because this is a relative new problem, I've paused many prints in the past and didn't have this issue. Recently, I noticed it happening once and figured I must have bumped into the printer, but since it happened again this week, I started looking for a cause.
And indeed, editing the script is a viable solution, but I'm wondering why this is suddenly necessary, since I've been running Octoprint for many years with an unedited script and it worked fine.
I did update to the most recent version of Octoprint a few months ago after a few years on an old version (can't remember which one).
The thing that I think is curious is that this only happens when I pause for an extended period of time (first noticed it when I paused a print overnight). If I quickly pause and resume a print (even the bigger one from the log), there is no issue. But somewhere between pausing for ~3 seconds and pausing for ~20 minutes, the layer shift occurs. So this really seems like there is a real issue.
I'll try filming my printer when paused to see if I see any movement during the pause.
This honestly sounds like your printer is cancelling stepper hold somewhere in between, most likely due to stepper inactivity timeout, which means the position can no longer be guaranteed after re-engaging the steppers. That would be a firmware thing, not an OctoPrint thing.
That might actually be the cause indeed. I filmed the paused print, and noticed that at exactly 2 minutes after hitting the x endstop, the printhead moves ever so slightly. I have no idea what the setting is in the firmware, but I might look into it. That would explain why it also only happens on X0, since the endstop pushes slightly against the carriage, which doesnt happen at X10.
I believe adding M18 S0 to the pause script would resolve this, I'll run another test to check.