Print stopped short of completion

I woke up early, went to check on my print, and the printer was not moving. Still up to temp, fans on, etc.

tried to log on to octoprint server to see what was going on. I got the page saying the server was not running, and it gave a few suggestions on what to try. I could connect to the Pi with putty, and restarted octoprint. Checked the logs, but found that for some reason the serial logging was disabled.

I'm running a Pi3 model B, OctoPi 0.15.1, OctoPrint 1.3.9, a Prusa I3 MK2S

last few lines of the terminal:
Send: M105
Recv: ok T:148.2 /0.0 B:51.4 /0.0 T0:148.2 /0.0 @:0 B@:0
Send: M105
Recv: ok T:143.9 /0.0 B:51.1 /0.0 T0:143.9 /0.0 @:0 B@:0
Send: M105
Recv: ok T:139.3 /0.0 B:50.8 /0.0 T0:139.3 /0.0 @:0 B@:0
Send: M105
Recv: ok T:135.5 /0.0 B:50.4 /0.0 T0:135.5 /0.0 @:0 B@:0
Connection closed, closing down monitor
Changing monitoring state from "Operational" to "Offline"

Octoprint log:

octoprint.log (123.6 KB)

I'm not really sure what's going on in the octoprint log, I was hoping someone would see a reason for the server shutting down. For now I have switched back to printing from the SD card until I can figure this out. Thanks for any help in this matter.

If you're using the GPX plugin then it sounds a lot like this issue. The underlying problem appears to be C language code in this plugin which—upon seeing a CRC sort of memory access error—dies badly, taking out Python. The suggested fixes included replacing the microSD card and/or the Raspberry Pi itself.

Also, this issue looks like the same. In this case, OctoPrint Anywhere as a plugin was removed for the fix.


To troubleshoot, disable any plugins you've added except GPX and give that a try.

It's disabled by default because it creates a lot of sd card data to be written which can very quickly fill up your sd card and should only ever be enabled for troubleshooting. I suggest you enable the serial logging and do another test print, you can turn off any heating and extrude moves so you don't waste filament, and run through a long print with serial logging on, also try it in safemode to see if the error still occurs.