Crash detect out of sync with menu if setting changed during re-homing (3.8.0-RC1)

[vintagepc]

Running a print on a MK3S/MMU2 with the 3.8.0 RC. Crash detection is disabled, normal (not stealth) mode.

Printer still detects crashes and rehomes/prompts to continue print if there are enough of them.

I have to change to stealth mode to stop crashes from being detected. (Reviewing the failure stats shows they appear to be X crashes)

[mkbel]

I can not reproduce this problem on actual MK3 branch + fix_power_panic_2. I tried both settings menu when not printing and tune menu during print and both reacted properly.

[mkbel]

I can not reproduce this problem on 3.8.0-RC1. I tried both settings menu when not printing and tune menu during print and both reacted properly.

[vintagepc]

weird. Is the crash detect change queued perhaps? I know for sure it was disabled in power mode and I was still getting crash detects; that's the only reason I can think of.

I'll run in power mode with detect off again in the next few days to see if I can reproduce it again.

[mkbel]

I analyzed the code. Crash detection enable / disable from menu is not queued. It directly sets three / resets four variables. tmc2130_sg_stop_on_crash, EEPROM_CRASH_DET, CrashDetectMenu, tmc2130_sg_crash.

We don't need to care about EEPROM variable, as it is read only after power up.

CrashDetectMenu variable shadows state of menu (and is good candidate for removal, as it could be efficiently read from EEPROM when needed, as it is not accessed from time critical ISR).

tmc2130_sg_stop_on_crash is the real variable controlling crash detection enable/disable.

When the crash is detected tmc2130_sg_stop_on_crash is temporarily disabled and "CRASH_RECOVER" gcode is queued. And here we are getting to point, where CrashDetectMenu and tmc2130_sg_stop_on_crash is intentionally out of sync. CrashDetectMenu is in this moment still enabled and tmc2130_sg_stop_on_crash is disabled as we don't want to detect crash during crash recovery (re-home). Normally printer is first re-homed, then "CRASH_RECOVER" command is executed, and this re-enables tmc2130_sg_stop_on_crash so both variables goes back to sync.

If you manage to disable crash detection from menu during re-homing after crash is detected and tmc2130_sg_stop_on_crash is temporarily disabled variables goes out of sync permanently. In such moment CrashDetectMenu is disabled. Menu item shows Crash detect[off], but once "CRASH_RECOVER" command is executed from queue tmc2130_sg_stop_on_crash variable is re-enabled leading to state where menu shows Crash detect[off], but crash detection is enabled in reality.

Easy fix would be to set tmc2130_sg_stop_on_crash to true in crashdet_recover() only if CrashDetectMenu == 1.

Even better would be to refactor first - remove redundant variable CrashDetectMenu, as it shadows EEPROM_CRASH_DET in EEPROM.

[vintagepc]

ahhhh. that is probably exactly what happened. The print was crashing, rehoming, going back to the print, doing one small perimeter, and crashing again. So It almost certainly got out of sync as you described, and why it went away on switching to stealth mode.

[mkbel]

Reproduced, so I can fix it.

[mkbel]

Fixed in #2123 Thank you for reporting.

[vintagepc]

Rock on - thank you for fixing!