I looked at this second log file. Unfortunately, it does not show the event - it appears to be a log after the event. I did not see anything in the provided log that indicates the software is not functioning as intended.
Note that the log does indicate the software was modified (eg, errf and led effects). If you’re looking for help diagnosing an issue it really needs to be with the pristine Klipper code, as it is not practical for us to diagnose or predict the operation of modified code.
If there is a concern with the operation of the mcu shutdown code, I’d recommend testing it. Set a temperature, wait a few seconds for the temperature to start rising, issue an M112 command, and verify that the temperatures starts dropping within a few seconds. If temperatures do not drop then remove power from the printer. I’d also recommend running the diagnostic steps at Configuration checks - Klipper documentation - this document was written so that users can exercise the fail-safe code in a controlled environment to ensure its functionality.
Separately, I’d recommend not running this printer hardware (other than for diagnostic purposes) until the root cause can be diagnosed and fixed. The fact that this hardware continues to fail is, to me, highly indicative that the hardware has a serious defect.
For what it is worth, there are a number of issues besides a blown mosfet that could cause a hardware issue. In particular, most boards (including the sb2040) always wire the heater to 24V and switch the ground wire on/off to control power. Should something ground that heater it will be enabled outside of the control of software (eg, malfunctioning ground plane, wire short to ground, wire short to frame which is partially grounded). To be clear, I do not know the root cause of the issue (and have no ability to know the root cause), but I would caution against ruling out hardware problems.
-Kevin
