A corner of my model curled up, causing the head to crash into it. The Prusa MK3 detected the error, printed a message to that effect, and moved the print head to the home position.
I was surprised when printing immediately resumed, and of course immediately went awry as it pulled the model off the print bed and dragged it around.
My questions:
You are describing precisely how the crash detection should work on the Prusa Mk3, so it is doing exactly what it should do. If you look into this video from Jozef Prusa you will see him explaining that in case a crash is detected (steps missed are registered because the Mk3 uses trinamic stepper drivers), the print head is homed and will immediately restart printing.
Please do read this interesting post; it describes your similar problems: after detection it resumes. He noteworthy mentions that even a few lines of G-code went missing, this is probably caused by the fact that OctoPrint buffers a few commands or something that get lost because the Pruse Mk3 crash fail safe kicks in.
In effect, OctoPrint is just a simple supplier of G-code commands and does not recognize the problem to act on it and will therefore continue sending new commands after the Prusa Mk3 crash has recovered (sending ok to OctoPrint for receiving new commands) from the crash and re-homed and got the temperatures back to normal levels.
An existing plugin for OctoPrint may help you in this case. The Action Trigger Plugin is able to detect events, but have to be implemented in your firmware. E.g. the action for filament describes:
This trigger will pause the print and home the X and Y axis, giving the user the opportunity to change out the filament. The print needs to be resumed manually through the UI.
Maybe it can be configured to pick up the existing event and issue a pause. It could be worth looking into this.
EDIT
Looking closer to the ActionTrigger plugin I noticed that you cannot configure it and the "manual" is very terse. I guess this might involve some serious hacking...
