I'm running OctoPrint from a Raspberry Pi 3B+ to control a FlashForge Creator Pro. Nothing special - I've tried to keep it as basic as possible, with GPX and Print History as the only plugins. Not even using the webcam module.
Twice in the last few weeks, I've discovered my printer frozen mid-print. The extruder and bed are still at temp, and the nozzle is touching the print.
The last time, I rebooted before pulling any diagnostic info from OctoPrint (I was printing some parts for a project on a tight deadline). When I went back to check, the log file didn't even have any record of the failed print.
This time, I pulled some console output from OctoPrint that includes the moment of the incident. I was able to reconnect OctoPrint to the printer just by selecting Reconnect, and that's apparent from the console as well. I don't know if this any more informative than a generic checksum error, but I'm hoping somebody has some idea of a diagnosis.
Send: N278030 G1 X44.221 Y17.745 E0.0157*110
Send: N278031 G1 X45.145 Y17.249 E0.0157*102
Send: N278032 G1 X46.153 Y16.944 E0.0158*105
Send: N278033 G1 X47.199 Y16.842 E0.0157*103
Send: N278034 G1 X48.244 Y16.944 E0.0157*107
Send: N278035 G1 X49.132 Y17.214 E0.0139*110
Unexpected error while writing to serial port: IOError: 'Generic Packet error' @ comm.py:_do_send_without_checksum:3005
Changing monitoring state from "Printing" to "Offline (Error: IOError: 'Generic Packet error' @ comm.py:_do_send_without_checksum:3005)"
Connection closed, closing down monitor
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: <GPX.gpxprinter.GpxPrinter instance at 0x714618c8>, starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Recv: startRecv: Sailfish v7.7
Recv: echo: gcode to x3g translation by GPX
Recv: SD card ok