Apologies up front if I'm not including the necessary information. I'm brand new to 3D printing using my Prusa MK3S-MMU2S system, and newer still to running OctoPi on an RPi 3 B+.
I'm printing medallions for tap handles for our brewery. They're 54mm in diameter and 6mm thick. After I finish the layer at 3.6mm height, I have added statements in my g-code to move the extruder out of the way so I can insert 12 magnets in each of the 12 medallions. Then I resume the print to complete the run. Here is the code I insert:
;;Pause and insert magnet(s)
G1 X10.000 Y200.000 E0; parking position
G1 Z40.000 F10800.000
M1; user stop
M105; return to current temp & resume print
I ran a couple of sheets of 12 medallions before using Octoprint, with no issues after inserting the magnets.
A couple of days ago I ran my first sheet of 12 using OctoPi (the latest version - I don't have the rev # with me), and there was about a 1mm layer shift on the Y-axis that I believe occurred exactly at the layer where I'd paused. I thought maybe I knocked the carriage or something and dismissed it. Then I ran another sheet of 12 and I got the 1mm Y-axis layer shift again, but this time in the opposite direction.
I ran another sheet of 12 last night from the SD card, and they ran perfectly just as before.
Any suggestions on what to look at to try and address this? I suspect it's related somehow to OctoPi use, since the runs never have an issue from the SD card. But I certainly don't have the knowledge to state that as a fact.
First things first, whenever I attempt pause/resume work like the kind you're doing, I always slice using Cura's relative extrusion option set. It helps make the extrusion audit happier.
You didn't mention what movement mode you have for your axes. We could assume that it's set to absolute mode. In theory, there might be a G90 command somewhere at the top of all this. If it's set to relative mode instead via G91 then expect unexpected/bad things to happen when you insert your own G0/G1 code into the middle of something.
Classically when I perform pause/resume scripts for the purpose of inserting things in objects, it goes something like this:
M117 Pausing to insert part # Might display a popup notification
G0 Z20 F1800 # I'm moving the hotend up first
G0 X0 Y0 F1800 # Then moving to home
M0 # Stop, awaiting resume from OctoPrint
# We continue from here after OctoPrint's resume button is pressed
G0 X64.488 Y40.267 F1800 # Move back to the place we were before
G0 Z3.0 F1800 # And bring the hotend back down
This depends upon the last X/Y/Z values right before this inserted code which we assume to be X64.488, Y40.267, Z3.0 from the looks of things.
You should really move the hotend up and then over to home, bring it back "on high" and then down before resuming. Otherwise, you'll eventually have a bigger part and notice that your hotend takes the shortest path to get back and crashes into your part, causing mayhem.
So I created a test print using 12 hollow cylinders with a 54mm OD and 6mm height. This is the same overall size of the medallions I print where I pause to insert magnets. I added g-code to pause after 2.0mm height complete and 4.0mm height complete, like this:
My code begins with the line ";" right after ";4.2", and ends after the M0 command.
When the print paused after 2.0mm height complete, I waiting a minute or so and then sent a resume through Octoprint. I did the same after 4.0mm height complete.
On completion of the print job I once again have a y-axis layer shift, but only at the first pause after 2.0mm height. The print stayed concentric from then on, meaning there was not another shift after completing 4.0mm height.
The only other thing I can think to try would be to move my pause code after the G1 command that positions the print head for starting the next layer, and then add another G1 command to return to that same location. So for example:
Otherwise I'm out of ideas, and it would seem that there may be a bug of some sort in Octoprint.
Just to recap, this never happens when I print from the SD card and don't use Octoprint. So that said I guess the other thing I can try is to use Octoprint to print from the SD card???
You could just remove any X/Y movement and bring the hotend to the ceiling to get it out of the way. Then it comes back down and there should be no y-shift, in theory.
Or... move the Z high, send the hotend to X0, Y0 then run a G92 for X/Y to reset the motor audit for those two.
By the way, you can test this with just a single cylinder to save filament.
Also, if you think OctoPrint is to blame then try this in Safe Mode to disable all third-part plugins.
I forgot to mention that I did test this with a single cylinder like the ones above, and in that case I didn't get a y-axis shift. Sorry about that. That's why I went back to a sheet of 12.
I will try what you just suggested, z up to perhaps 200mm so I have room to get in and insert magnets, and then z back down. No x/y changes.
If that corrects the "issue" I will try running in Safe Mode as well.
That's rather significant, don't you think? As in "this works great with one part, no problems, no y-shift; it's when I add more parts that I get the problem..."
Definitely try the first suggestion where you don't move the X/Y to get the hotend out of the way.
One of the aspects here (with 12 parts) is that travel to/from the home position could be further than with a single part. Your own code introduces a speed-of-movement in that F1800 command. Maybe that's too fast to accurately position your motor(s). It's entirely possible that the belt for the Y is too loose. You could try this with F300 instead.
All that OctoPrint does here is pump gcode to the printer, be it from your printed file or whatever you have defined in your scripts.
It doesn't rewrite coordinates on the fly nor does it control the stepper motors directly. It can't cause an axis shift unless your code contains a coordinate reset or some weird rounding issue in the pause resume script.
What I'm completely unclear on is how you are pausing, what you have configured in OctoPrint with regards to scripts and how your files look precisely. To figure this out we'd really need a full serial.log here and a demo file with which you are seeing this behaviour.
Also, considering that you are using a printer here who's firmware should support M600 for swapping filament, it might be worth considering testing with that (use the swap pause for insertion of your magnets and simply don't actually swap) because it handles pause, moving out of the way and resume in firmware, which given the protocol situation is usually preferable.
