the offending toolhead has PT100 attached to MAX31865
Describe your issue:
So I have been noticing occasional temperture sensor spikes to crazy values on klipper restart. In the order of trillions.
They normalize immediately and there seems to be no bad side effects, except the temp graph scale going crazy.
The spike is always on extruder0 temp, which is reported by one of the ebb36 boards.
The Klippy.log does not show any retransmits or errors from the board.
I keep wondering how to best debug this. This appears like one every 10+ restarts, so not exactly easy to catch.
Mu klippy.log is 100+ megs right now, so not really eager to attach that here.
Indeed, there are a few reports here mentioning the same phenomenon,
No idea though, why and where to start looking. Generally I’d doubt that the klippy.log is of much use here except that it confirms that the sensor send some wired values.
I’m not aware of reports that Klipper itself is producing erratic temperatures, and it’s not clear to me what in the Klipper code could cause them. As a total guess, it’s possible that the GUI code (eg, mainsail, moonraker, fluidd) is getting confused by a restart and performing some invalid calculation. I suspect taking careful logs and tracing those logs would be needed to track something like this down.
I’m using a lot of temp sensors at work. Sometimes really expensive sensors.
My testing environment can be compared with a 3D printer. Lots of noise and spikes in the air.
In my working logs also I find some temp readings, which make no sense. When analyzing the logs I just delete those values, since I know they are wrong.
I don’t know, if it is possible to run macros on your EBB36 MCUs to filter those wrong values out before data is transmitted to your printer board using CAN.
I don’t think so. In my eyes just a wrong reading (due to electrical distortions from the environment) from the sensor or AD conversion error. Just throw that reading away, since you know it must be wrong.
Hmm, digging deeper, the sensor code passes max value to the spi driver, but that would still provide the raw 32 bit value before detecting that it exceeds max and resetting on fault.
Maybe there is something to it, will analyze some more tomorrow.