I also have this problem. After resuming, the extruder motor does not seem to do the thing. It will manually extrude when I tell it to via the octopi control, but once I restart the print, the extruder motor doesn't see to extrude.
I may start another thread if I find no other info.
I went though this today because I wanted to change color at a certain layer, M600 was not recognized and I didn't want to update the firmware since everything else had been running great, I was on Marlin 1.0.1 on a 4.2.2 board. So I tried using the PAUSE and RESUME feature in OctoPi (Version 0.17.0, running on Raspberry Pi 3 Model B Plus Rev 1.3) and upon resume the extruder motor seemed to actually run opposite what I should be. I thought this might be a firmware issue so I updated to Marlin 2.0.7.2. Same results, so I edited the firmware build to enable the change filament codes. Works fine from Prusa Slicer now. I don't think it is a big deal since there is a right way to do it in the gcode now but I am sure there is a bug when the RESUME function is used in OctoPi.
Unlikely to be a bug - without knowing the contents of the scripts, I can't say for sure, but it's unlikely.
The problem you probably faced is relative vs. absolute commands, if the gcode is using absolute and then the script is using the other but you don't include the right commands to switch modes, this can happen.
The slicer was Prusa, no added script. The gcode file was not modified, the commands were sent via the PAUSE and RESUME buttons in OctoPi. The process was handled strictly in the user interface of OctoPi as follows.
Paused the print, retracted, lift on Z and homed on XY, then Extract for some mm until the filament was changed color then, RESUME and the extractor then ran in reverse.
Just the slicer name isn't enough to confirm or deny @Charlie_Powell's premise. Slice a small object (1x1x1mm cube) and post the gcode output here and we probably can give you a better answer.
Last night I was trying a two color print for the first time and came across this same issue. With some test prints and watching the terminal output I was able to figure out that it is a relative vs. absolute command issue like @Charlie_Powell suggested. As it turns out PrusaSlicer (2.3.1) outputs the extruder commands as relative, but the XYZ commands are absolute. From what I found OctoPrint does not track the current command state of the motors and just assumes all command states should be absolute for printing. In my testing I found if you just pause a print and restart without any motor movement there is no issue and the print resumes as normal, but if you move any motor the movement command is wrapped by commands to set the command mode to relative, do the move, then set the command mode to absolute for all motors. This method causes the extruder to be running in the incorrect command state for the remainder of the print.
FIX / WORKAROUND:
In the OctoPrint Settings -> GCODE Scripts -> Before print job is resumed
make sure the end of the resume script ends with
; relative extruder
M83
This will set the extruder back to relative and your print should resume as expected.
WARNING: If you happen to use multiple different slicer softwares and the other software uses absolute command mode for the extruder this could break prints sliced in that other software if there are pauses in the print.
Thanks for your post. I actually tried your recommendation and it seems like it works however, I have another problem for some reason after the print head extrudes out the new filament and returns back to print, nothing comes out from the print head on the print. It extrudes out the new color just fine.
I agree with @Ewald_Ikemann that seeing the serial log will help to diagnose this further. It would also be good to include your entire pause and resume scripts.
Here's my serial log using the Prusa Slicer pause. It pauses just fine and purges filament prior to resuming the print. Unfortunately, after it resumes nothing comes out of the hotend.
I was experiencing the same issues and, after a long research time, I found applicable fixes for me.
I know this topic is old now and maybe it was resolved in other topics but if I can help someone else
My printer : Sidewinder X2
My slicer : Superslicer_2.4
I'm using Octoprint togheter with M600 Rewriter plug-in to interpreet the M600 command because the X2 does not supports it natively.
First problem : the fact that the extruder seems to go in a "reversed" way ( moving up the filament instead of moving down for extrusion )
Resolution : I first apply the solution to just add the M83 into octoprint's "Before print job is resumed
" g-codes but the problem was still there. So I decided to put the full "package" of information so I did put :
{% if pause_position.x is not none %}
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 X{{ pause_position.x }} Y{{ pause_position.y }} Z{{ pause_position.z }} F4500
{% if pause_position.f is not none %}G1 F{{ pause_position.f }}{% endif %}
{% endif %}
And it worked.
Second problem : the fact that the printhead was printing "in the air" for some seconds before suddenly going back to the correct layer.
Resolution : I found out, in the log, the G1 Z=XX code was going from Z=81.6 to Z=1.7 ( the famous 8 cm that need to be removed ) so that was the reason of the fact that suddenly the printhead was going to the correct layer. I checked a bit deeper the log and I found out that superslicer ( and I presume Pusaslicer too as it is the same base ) puts the M600 command in the middle of a layer change.So I moved the M600 command just before the layer change code and it worked also . The printhead was going back directly to the correct position after filament change as a correct Z position
I'm still trying to figure out how to fix this thing, within superslicer, without modifying my gcode everytime so if someone find a fix, I would be happy to have it