TMC2240: Allow control and use of temperature report

[nefelim4ag]

My personal goal:
I like to control all fans, the printer is at home and I try to minimize noise if possible.

There are 3 patches:

1. Duct tape fix for race conditions with temperature combined sensor and other sensors during klippy initialization, where sensors can return 0. This may be by design, but it currently limits the minimum possible deviation between sensors. Like there, it is adc + i2c:

2. Temperature combined allows us to set "any" object in the sensor list, but with tmc2240, there is a corner case, it has method get_status() and temperature field, but it has no value. So, it will crush Klippy cause max/min can't handle None.

3. Proposal to allow monitoring of TMC2240 continuously, which in the end allows the use of it as combined sensor to control fans.

I can split PR if needed.

---

Should close: #6675

[KevinOConnor]

Thanks. In general the first two patches look fine. The new comments seem a little odd though - I'm not aware of any sensor that will return 0 - we should definitely fix any sensor doing that.

I'm not sure about the third patch. Why would one use temperture_combined on a tmc2240 temperature? What would they combine it with? If the goal is to use a tmc2240 temperature sensor as a regular sensor, maybe we should consider adding an internal mechanism to indicate to the tmc2240 that it always needs to provide temperature (that is, have the temperature code signal the tmc2240 instead of a user config option signalling tmc2240).

-Kevin

[nefelim4ag]

I'm not aware of any sensor that will return 0 - we should definitely fix any sensor doing that.

I think that about the first patch and the delay in initialization.
It will be nice, but all temperature sensors do that, the only exception is ADC ones.
They all initialized with the default value equal to .0:
https://github.com/Klipper3d/klipper/blob/master/klippy/extras/ds18b20.py#L20
(same for BME, HTU, SHT, LM75).

So, get_status which always just returns the last value of self.temp, can be called and will return .0
Of course, after the first query cycle, they will return the actual value or crash the system.

Maybe there is a more clever solution, like ... do pause() in get_status() to wait for initialization in every sensor?
I'm not so familiar with the whole call chain here, to suggest something sane here.
Looks like ADC is always making calls to MCU instead of providing cached property.

---

I'm not sure about the third patch. Why would one use temperture_combined on a tmc2240 temperature? What would they combine it with?

Maybe I misunderstood the goal of temperature combined and misused it, but I have only 2 use cases, like:

• use avg/max over drivers' temperatures to control temperature FAN (I use only one pin to control fan output to cool drivers)
• Duplicate sensor, because heater object can't have humidity or gas, and I use bme680 as the control for chamber temperature, and ADC + temperature fan to control PTC heater.

I do not see a reason to use any individual data from the drivers to control anything, AFAIK there is no external TMC2240 like TMC5160, which can be cooled individually.

If the goal is to use a tmc2240 temperature sensor as a regular sensor, maybe we should consider adding an internal mechanism to indicate to the tmc2240 that it always needs to provide temperature (that is, have the temperature code signal the tmc2240 instead of a user config option signalling tmc2240).

If there is a way to avoid adding strange config options and do some magic behind the scenes - I agree it is a better solution (like query always if there are consumers of data - it will be a better solution).
But I can't imagine how to do that without modifying every possible temperature consumer to add some callback for that. I even had thought about allowing to define something like temperature_sensor where type is tmc2240 stepper_* which will do something like that - change internal behavior/reload as a sensor. But it also feels weird a little.

My original intention here is to just allow us to use it somehow at least because right now it is only for graphs.
Graphs btw look strange to anyone who doesn't know why there is no data from the driver - if I can easily query it from the console.