Troubleshooting Pause and Resume scripts


#1

Today I tested the pause and resume scripts available on the OctoPrint site here: http://docs.octoprint.org/en/master/features/gcode_scripts.html

I'm testing with a Prusa MK3 running firmware 3.4.0. OctoPrint is 1.3.10rc2.

The X, Y, and Z movements for both pause and resume seem to work fine. Unfortunately, on my tests, the extrusion did not seem to resume and I was air printing.

What is the best way to try to troubleshoot? Turn on serial log and see what actual commands were sent, and if there were errors?

Thanks for any guidance.

John


#2

See, this is why I left absolute extrusion at least six months ago. I love the relative extrusion option in the stand-alone version of Cura. It means that each and every extrusion is all about "extrude this amount of filament" and it has nothing to do with keeping track of an extrusion audit.

Absolute Extrusion

Imagine that you're some code in the firmware and that you're at the "3026.45 mm" point in some audit variable. And then you—the user—arbitrarily decide to interrupt all that with a pause/resume event. Maybe you're changing filament. So of course, you retract by 130mm to purge the hotend. You jam some different color of filament in there and extrude until you see the new color. But did you extrude exactly 130mm? No, you did not. Let's say that you extruded 150mm.

3026.45 - 130.0 + 150.0 = 3046.45

But you're supposed to be sitting at 3026.45 right now (according to the print job). So you're going to air-print for 20mm worth of filament until you get back to the zero point.


I could talk about successfully switching back and forth between modes and zeroing the extruder audit but just make your life simpler by slicing with relative extrusion.

More


#3

Thanks for your reply. I do use relative extrusion in all my print jobs.

I do see the OctoPrint pause and resume scripts reference both M82 and M83, but on quick glance, that seems to have more to do with effectively storing current position and later restoring that current position.

Do you know if turning on serial logging would capture the communication so I could see of some of the variables are being set incorrectly? (I guess I will just try it).

Thanks,

John


#4

Check out my initial set of scripts in that More link above. They're very simple and they work perfectly with respect to extrusion.

If you imagine a very long (unattended) pause, you might need to tweak things. A long pause would probably result in drooling hot-enough filament slowly onto the part. In that case, you'd likely want to retract 5mm before and extrude 5mm at the moment of truth when resuming. Another safety mechanism would be to move the assembly over toward the home position in some way and then back.

Following that thread, you can see that others want to cool things down and then bring them up to heat on the resume.


In my own case when I was first printing, I noticed that ALL print jobs started off with a deficit of available filament. The initial line never laid down, only getting started perhaps 10mm into it. Looking back on those days, the initial gcode prefix provided by my printer manufacturer was to blame since they didn't understand that audit I described before.

M82 sets the extruder to absolute mode and G90 sets the other motors likewise to absolute mode.
M83 sets the extruder to relative mode and G91 sets the other motors likewise to relative mode.

Most pause/resume script examples assume that your motors and extruder are both in absolute mode so be careful what you snag from the Internet. Relative extrusion is something new so not all of the tutorials and exampls have caught up yet.

In fact, new work is being done in Marlin at this time to include some logistics to make all of this easier. One of the authors is now working on that. A new Mnnn command of some kind will return the current state of the motors, making it easier to create a bullet-proof pair of pause/resume scripts.


#5

Excellent, info! Thanks.