<p>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 <a href="https://www.youtube.com/watch?v=KDJq0WplXb0&amp;feature=youtu.be&amp;t=145" rel="nofollow noreferrer">this video from Jozef Prusa</a> 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. </p>

<p>Please do read <a href="https://shop.prusa3d.com/forum/others-archive--f66/octoprint-with-mk3-crash-detection-missed-lines-of-t15123.html" rel="nofollow noreferrer">this interesting post</a>; 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.</p>

<p>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 <code>ok</code> to OctoPrint for receiving new commands) from the crash and re-homed and got the temperatures back to normal levels.</p>

<p>An existing plugin for OctoPrint may help you in this case. The <a href="https://plugins.octoprint.org/plugins/actiontrigger/" rel="nofollow noreferrer">Action Trigger Plugin</a> is able to detect events, but have to be implemented in your firmware. E.g. the action for filament <a href="https://plugins.octoprint.org/plugins/actiontrigger/" rel="nofollow noreferrer">describes</a>:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>Maybe it can be configured to pick up the existing event and issue a pause. It could be worth looking into this.</p>

<hr>

<p><strong>EDIT</strong><br>
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...</p>

CC BY-SA 4.0
2018-09-11T07:46:05.903Z
2018-09-11T18:18:54.267Z
2018-09-11T18:18:54.267Z
0scar
<p>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.</p>

<p>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.</p>

<p>My questions:</p>

<ul>
<li>Is it expected that printing stops when a head crash is detected?</li>
<li>If so, does Octoprint recognize this condition and stop printing?</li>
</ul>

<prusa-i3><octoprint>
Does Octoprint stop printing on Crash Detection?
Mark Harrison
# Does Octoprint stop printing on Crash Detection?

(Asked by: username_0 on 2018-09-11)

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:

* Is it expected that printing stops when a head crash is detected?
* If so, does Octoprint recognize this condition and stop printing?

**Tags:** prusa-i3, octoprint

---

## 1 answers

### Answer by username_1 on 2018-09-11. Score: 5 | Accepted answer

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](https://www.youtube.com/watch?v=KDJq0WplXb0&feature=youtu.be&t=145) 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](https://shop.prusa3d.com/forum/others-archive--f66/octoprint-with-mk3-crash-detection-missed-lines-of-t15123.html); 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](https://plugins.octoprint.org/plugins/actiontrigger/) is able to detect events, but have to be implemented in your firmware. E.g. the action for filament [describes](https://plugins.octoprint.org/plugins/actiontrigger/):

> 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...


---

