Under certain critical circumstances like thermal runaway protection, Marlin entered a killed state. You typically need to hard-reset the mainboard after entering that state. However, in environments where physical access to the machine, hard-resetting Marlin is not possible, so you might need to implement.
Note that diagnosing & fixing the underlying issue that caused the reset is extremely important and ignoring it might lead to further issues, up to a fire hazard or the destruction of the printer. So be sure to know what you are doing before just.
The following guide was tested with Marlin 2.0.9.1. It should work with most Marlin 2.x versions with minor adjustments.
First, note that as an alternative to hard-resetting the mainboard there is the SOFT_RESET_ON_KILL option which allows you to trigger a soft reset out of kill mode using a button connected to a pin. We won’t delve into more detail on this, since it doesn’t really change the requirement for physical access to the printer.
Open Marlin/src/MarlinCore.cpp and find the minkill(bool) function.
At the end, this function contains a preprocessor-controlled branch of the following structure:
#if EITHER(HAS_KILL, SOFT_RESET_ON_KILL) // Branch 1 ... #else // Branch 2 ... #endif
We will replace this entire branch by these lines:
// Wait for 5 seconds for controller to catch up
for (int i = 5000; i--;) { DELAY_US(1000); watchdog_refresh(); } // 5000*1ms = 3s
// Auto-reset after kill
HAL_reboot();I prefer to insert the 5-second delay into the reboot logic so no superordinate controller (like a Raspberry Pi running OctoPrint) can miss that the Marlin board has been killed. Although most controllers should be able to detect the killed state from the G-Code, this 5-second delay will simulate the default behaviour of not resetting at all after the killed state has been reached. However note that in case you absolutely need to reset ASAP after the kill state has been reached, it’s typically safe to omit the wait loop.