The above PR has been stale for about a year due to what I understand is Xorlev’s life commitments (real priorities). It seems to me that a large number of users (pretty much everyone using MAX31865) can benefit from this feature.
Would anyone be interested in resurrecting this PR so that it can be merged? I think the outstanding “cleanup” is rather minor in nature. I would make an attempt at it myself, but I can pretty much guarantee that I would turn it into dog’s breakfast. I know virtually nothing about Python, even though I understand what the proposed changes are doing at a high level.
---
### Author:  [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)
#### Post date: [June 23, 2022, 6:24am UTC](https://klipper.discourse.group/t/can-we-resurrect-max31865-fault-tolerance-pr-4164/3187/2 "2022-06-23T06:24:12Z")
Well, there does not seem to be much excitement about this, so here is my attempt at turning this into dog’s breakfast:
> **[GitHub - ReXT3D/klipper at Xorlev-max31865-fault-recovery](https://github.com/ReXT3D/klipper/tree/Xorlev-max31865-fault-recovery)**
>
> Xorlev-max31865-fault-recovery
I think I addressed all points that Kevin and Xorlev discussed, but once again - I know nothing about Python. Is anyone interested and able to conduct a sanity check & review? The modified code appears to work fine in my test setup.
As a separate note, I tested the above code by momentarily shorting the RTD input to induce faults. While doing this, I noticed a rather unexpected behaviour - at times Klipper would briefly register seemingly valid spikes in temperature. I therefore added experimental feature to handle excessive rate of change of temperature received from MAX31865. This should be capable of handling certain intermittent and/or in-range failures that the MAX31865 internal diagnostics may not catch, such as those associated with wiring issues or electromagnetic interference. The primary goal here is to prevent these from being fed into the PID cntroller. I have not pushed these changes into my repository yet, but would be happy to do so if there is interest…
---
### Author:  [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)
#### Post date: [June 24, 2022, 1:57am UTC](https://klipper.discourse.group/t/can-we-resurrect-max31865-fault-tolerance-pr-4164/3187/3 "2022-06-24T01:57:20Z")
If anyone is interested in reviewing and/or testing the excessive rate of change handling branch, it is located here:
> **[GitHub - ReXT3D/klipper at max31865-handle-excessive-temp-slope](https://github.com/ReXT3D/klipper/tree/max31865-handle-excessive-temp-slope)**
>
> max31865-handle-excessive-temp-slope
Note that it includes all of the other changes to Xorlev’s branch that I referenced before.
---
### Author:  [@ReXT3D](https://klipper.discourse.group/u/ReXT3D)
#### Post date: [July 5, 2022, 10:51pm UTC](https://klipper.discourse.group/t/can-we-resurrect-max31865-fault-tolerance-pr-4164/3187/4 "2022-07-05T22:51:11Z")
For the sake of completeness and traceability, I now created a PR:
>
>
> thermocouple: Reworked Xorlev's PR max31865: attempt to recover from faults
>
> T…his revises Xorlev's PR \[thermocouple: max31865: attempt to recover from faults\](https://github.com/Klipper3d/klipper/pull/4164) to address comments from @KevinOConnor.
>
> I made the following functional changes to Xorlev's code:
> 1. Replaced user configurable rtd\_consecutive\_fault\_limit with fixed CONSECUTIVE\_FAULT\_LIMIT = 3
> 2. MCU code changed to not transmit consecutive fault count to host
>
> Algorithm: The host transmits CONSECUTIVE\_FAULT\_LIMIT to the MCU. The MCU counts consecutive faults. Host code reinitializes MAX31865 on each fault indication from MCU. If the RTD fault condition persists exceeding CONSECUTIVE\_FAULT\_LIMIT, the MCU will shutdown.
>
> This modified code works fine in my setup during normal operation and when intentionally inducing intermittent RTD faults. Code review should emphasize Python and Klipper coding conventions as I have not written any useful code in 12+ years and my experience is primarily in C.
>
> Signed-off-by: Piotr Twarecki \