Here's an example.
A 5x5x5mm cube sliced with CuraLE 3.2.19 and lets assume that the filament jams in the middle of the print and the top half of the cube is printed with air. We don't want to waste all of those hours of printing time 
so we decide to try and recover.
After measuring the part on the bed, we determine that layer 10 was in process at the time of the failure and we are going to attempt recovery starting at layer 11.
In the .zip file, Test_Cube.gcode is the complete file, Test_Cube_Before.gcode is the beginning and layers 1-10, Test_Cube_After.gcode is the layers 11-end. Test_Cube_AfterFixed.gcode is what needs to be sent to the printer to finish the print.
Before we can finish the print, we need to solve the filament issue. Lets say that the filament on the spool got wedged so we need to remove the filament from the extruder, cut off that nice semi-circle ground into the side of the filament by the hob bolt, clean the hob bolt, and reinsert the filament (adjust temperature as needed) and prime a few mm just to make sure everything is ready.
Now lets discuss what was added to Test_Cube_AfterFixed.gcode (reproduced here)
G90 ; absolute mode
M82 ; absolute extruder
M109 R195 ; hot end temperature
M106 S255 ; cooling fan speed
G92 E10.25736 ; last filament position
We need to reestablish the conditions that were present when layer 10 ended. The first 4 commands should be obvious. The last command is what we are having trouble understanding. If you look at the Test_Cube_Before.gcode, you will see the last command that extruded filament did so by moving the E value to 10.25736. Since the failure was not detected immediately by the firmware, all the "air filament" was extruded and who knows what the E value is now (not to mention any LCD filament movements we needed to restore the filament). Maybe M114 will show us, but we don't care. We will just tell the firmware that the current E value is 10.25736 and the first G1 in Test_Cube_AfterFixed.gcode will move the E value to 10.32594 extruding .6858mm of filament.
Hopefully, this will settle the confusion. If not, I'm sure you will let me know 
1 Like
Beautiful (and thanks for all the prep there). You didn't have to factor in any of your prep-work to re-prime; you're just basically jumping into a time machine and rewinding the extruder audit to the time of death, so-to-speak.
That should be enough to go on. I'm sure I'll end up making something useful out of this. I intend to upgrade GetToDahChoppa to be compatible with the latest version of Cura, to eventually create a means of restarting a print after a power outage and maybe something else yet unimagined.
After a power outage is going to be a challenge. The printer firmware "has lost its mind". You might be able to get "G28 XY" to work but "G28 Z" runs the risk of crashing into whatever is on the bed.
I wonder if "G92 Zn" works instead of "G28 Z"?
Not to mention that G29 (or equivalent) auto-level generates information that probably isn't saved across a power outage either. I think the Prusa MK3 may have special firmware to handle this case.
Ah, yes. I'm aware of the autolevel-challenge, hence the OctoPrint-plugin-toggle-autolevel which can programmatically ignore G29 when seen. Beyond the bed-leveling info (not) stored, it also results in problems when the IR sensor sees plastic below and wildly setting up for a bad virtual plane as well as the fondness of crashing through your parts like a bull in a china shop.
I'll play with the possibilities. My take on this was to run a plugin which monitors/saves what's being sent to the RAMPS board, what the last G29 produced in a virtual plane, what the last layer was and the adjusted last line from the file which was sent (accounting for removed comments), the last extrusion offset and the movement mode.
As foosel said, that would be me. But I kinda lost the thread - do you need anything?
@mikhael47, the OP, suggests that he's using 0.15.0 of OctoPi but it's losing its serial connection and he's having difficulty connecting to it over the network as well. Most of the information is in the initial post.
1 Like
Yes, I am actually holding serial connection, octopi is just locking up solid though. I have bypassed it for now to get some important prints done from SD, but once I have a chance I can do some troubleshooting if required.
The var/log/messages file does not show anything, octoprint.log just stops and my serial.log file just stops. I am inclined to believe it may be hardware related. I do not have another Pi to test with ... yet.
Mike