RFC: Heaters/temperature_* refactoring

Developers
1

It looks to me that over the years, many different types of sensors have been used, and composite objects have accumulated in the code.

Sometimes, it requires weird duct tape to define them in the config.
For example, I have an extruder object.
It is: stepper + heater + temperature sensor, and for some reason, a separate fan object.

Where the definition of MAX31865, and the sensor pin, actually, is a CS:

sensor_type:MAX31865
sensor_pin: ebb42:PA4
spi_bus: spi1_PA6_PA7_PA5
rtd_nominal_r: 1000
rtd_reference_r: 4300
rtd_num_of_wires: 2
min_temp: 10
max_temp: 330
smooth_time: 0.3

The same would happen with heaters, temperature fans, temperature probes & etc.

It seems to me that the DAG approach to this complexity can simplify all objects and their definitions.

So, basically, one can do:

# or just sensor
[tempature_sensor _extruder]
sensor_type:MAX31865
sensor_pin: ebb42:PA4
spi_bus: spi1_PA6_PA7_PA5
rtd_nominal_r: 1000
rtd_reference_r: 4300
rtd_num_of_wires: 2
min_temp: 10
max_temp: 330

[extruder]
# or just sensor
temperature_sensor: _extruder
smooth_time: 0.3

That is it.
All the sensor-specific fields within the compound objects will be deprecated (now we can deprecate config sections).
The above example should be compatible with all the previous API and UIs.
Basically, one can do the same now with temperature_combined.

Later, it seems to me that it would be possible to fix specific objects like MAX31865, to get rid of the non-existent sensor_pin.
And to rework the temperature_combined, so it will use “true” callbacks, to work over the temperature sensors.

I understand it is a bit of work, and basically, it is refactoring to simplify the existing config and remove any possible ambiguity.

If I try to imagine the complete refactoring of this, it would be the “sensor” object, which loads the appropriate module, which can be a temperature sensor.
So, it would fit the not temperature sensors, for example: Support for SGP40 Sensors

So basically, the separation of the source of data from the consumers of data, to always define a DAG:

  • SGT40 → sensor_combined
  • SHT36 → sensor_combined
  • sensor_combined → chamber_heater

or:

  • heater_block → extruder

Thanks,
-Timofey

Separately, I guess, this can somewhat help with a possible toolchanger setup, where nowadays, the thing that we are changing is shifting between the whole toolhead and the pure nozzle.
But this is my speculation.

Ah, and it fixes the setups where several objects can be controlled from the 1 source, for example, 2 fans to cool down the drivers. Where people often use multi_pin to accomplish that.
Or 2 extruders for one hotend.

1 Like
RFC: Fan* refactoring
2

I agree that the extruder object is a little weird because while physically the extruder is the motor and gears, the config object combines

  1. stepper
  2. heater
  3. temperature_sensor

I like the idea of breaking out the temperature sensor especially if that makes it easier to maintain the individual sensors. Perhaps it’s worth considering dismantling the extruder object entirely and creating a toolhead object that then combines the stepper, heater, temperature_sensor and fan. This would probably go a long way to making multiple toolheads simpler because selecting a different tool would automatically select the heater, part fan etc without needing so much gcode macro glue.

FWIW, I don’t like sensor_pin having overloaded definitions, namely adc_pin and cs_pin. I would prefer for the mcu internal ADC to retain sensor_pin and external sensor device like the MAX31865 and others to use their connecting bus nomenclature.

1 Like