Print recovery after out of filament, yet "continued to finish print".
Hi all, I'm not sure if this is the right place to post this. I ran into an issue last night with a 10+ hour print and would like some education and some assistance.
Setup:
i3 MK3S w/ MMU2S
Using OctoPi for the print.
MK3S Filament Sensor [ON]
Filament: PETG
Using 0.6 nozzle
Compiled with "0.35mm Speed" setting in Prusa Slicer 2.3.1
Printer set to 60% print speed using the dial.
I believe both my Mk3S and MMU2S firmware is up to date.
Situation:
Printed near the end of a spool expecting MMU to switch to filament #2 once it ran out.
Woke up to find the print 'was finished' but only about 3/4 of the project was physically printed.
Filament was pulled 1/2 way back up from the extruder toward the MMU2 with the MMU2 waiting on user intervention to clear error. I am assuming the error was b/c it couldn't grab the filament to retract upon completion since I had to tug back on the filament until it could catch as I continued pushing the rightmost button to retract more.
What appears to have happened was the end of the filament was bent into a hole in the spool keeping it secure. MMU2 managed to eventually pull the filament free from the spool, but the damage was done and the filament was ground down to the point of not being able to continue feeding. MMU2 sensed filament and MK3S continued printing. The extruder was not receiving any filament and was just printing hot air.
So my questions are:
1. Why did MK3 continue printing if the Extruder did not have filament? I double-checked and the Filament Sensor setting is ON. Is this an OctoPi related issue?
2. Is there a way to recover the print and continue printing? I started looking at some sources on how to edit the GCode, but I don't see layer labels in the GCode. (I haven't done any slicer/gcode customizations.) I counted the layers in a zoomed in photo and it appears to have 115-116 layers complete. How do I correlate this to the existing GCode position to be modified? What special items do I need in the modified GCode to make sure it doesn't recalibrate/crash into the model? Is there any recommended procedure to reheat or not heat the bed to ensure everything maintains attached to the bed?
I am completely new to editing GCode and can't seems to coherently piece together the nuggets of possibly applicable information from the various Internet sources. Most don't seem to be Prusa/Slicer oriented.
I do have access to the OctoPrint server and can use the terminal if needed.
The printer is still on and in its completed state. I haven't moved any axis and if needed might be able to manipulate it to locate the Z if needed.
I could just take the L and do-over the whole print, but figured I'd take this as an opportunity to learn recovery methods and maybe something else about how the systems function. Thanks if advance for any assistance the community can provide.
Recovery partial success, but still curious why it failed.
Thanks. That video was very helpful. I ended up having to do the last-resort no-homing method since my print was under the extruder cabling harness.
It seems to be a partial success. 1 item seem to be getting completing almost perfectly. The second item seems to have been a layer short and with that was eventually affected by temperature variation and popped upward on one end at the seam. The printer seems to be making due with that issue, so I guess I'll just fill the crevice with epoxy.
In summary, the recovery was not that bad, just daunting playing with G-Code the first time.
But, I still don't know why it didn't stop printing when the filament ran out. Hoping someone can chime in here on whether they really think it was the OctoPi or some other problem. If it is an OctoPi issue, I'll probably start sticking with SD card prints.
RE: You answered your own question
MMU2 managed to eventually pull the filament free from the spool, but the damage was done and the filament was ground down to the point of not being able to continue feeding. MMU2 sensed filament and MK3S continued printing. The extruder was not receiving any filament and was just printing hot air.
That’s what happens, in that situation the extruder gears can’t pull the filament due to the ground down filament and FINDA is triggered because there is still filament in the selector. During normal printing the MK3/MMU ignores the filament sensor on the extruder as long as FINDA is happy and continues printing or to be more exact - moving and extruding air…. Only when FINDA senses the end of the filament, the printer would push the filament back to the MMU with the extruder and the MMU would retract the filament from the extruder and ask the user to feed new filament or in case of spool joint switch to the next spool.
So, I believe not a OctoPrint issue but normal behaviour…
If at first you don't succeed, skydiving is not for you.
Find out why this is pinned in the general section!
Prusa knows it but does nothing
A know problem. But prusa does nothing about this!
difficult
A know problem. But prusa does nothing about this!
There is not much they could do. If you use the extruder sensor for filament runout detection it is to late, the extruder would not be able to push the filament back to the MMU to remove it because it's not enough filament left - that's why FINDA is used for this purpose and it works quite well, as long as the filament detaches from the spool without major kinks. The problem is the way the filament is fixed to the spools...
Additionally using the extruder sensor for filament runout detection would cause a lot of malfunctions with flex filament...
If at first you don't succeed, skydiving is not for you.
Find out why this is pinned in the general section!
firmware update
firmware update!!
RE: Print recovery after out of filament, yet "continued to finish print".
What's needed is a guillotine that chops off the end cleanly when the filament with kink leaves the spool.
Surely someone has made such a thing?