RFC: Cooperative Heaters predictive control

[nefelim4ag]

Some time ago I dug heaters a little on the Discourse

I don't think PID is bad or needs to be replaced.
I tried to do some fun stuff, like train DNN or write my own algo to control the power.
In the end, everything looks the same.

There are historically various topics, that try to replace it or tune it differently.
I think the only practical reason is to handle something important for that human being.

So, there is an ultimate solution, I think.
Pid is still under the control of a heater and is able to drive it.
The end-user has the ability to adjust it freely, like in my doc example - drive PWM in a feedforward way if the fan is suddenly enabled, like for bridges.

If it is needed, it is definitely possible to get the current chamber temperature, adjust to the fan curve, try to parse the extruder moving queue (IDK) and drive PWM higher before the temperature falls and PID will reactively compensate for that.
I hope that will add enough flexibility to stop rituals like "how to do PID autotune properly".

Another example, for some reason people do not insulate the heating beds, adding thermistors inside a thick aluminum plate and then want sort of PID control by two thermistors, and feel that combined sensor is not good enough.

Well, now it is possible to literally query the sensors and decide what to do, like return the -N value and decrease bed heater power on demand.

I hope it is made in a way to is safe and acceptable, leaves all existing safety measures in place, and mostly does not touch safety-critical code.

Thanks.

---

Btw, I will try to add templates to temperature FANs in a similar way, to fit most of the wishes, like curves, formulas & etc.

[Sineos]

Nice!
It seems to follow the same logic as display templates. Maybe stick to the general wording and naming from there?

[nefelim4ag]

Maybe stick to the general wording and naming from there?

I imported some changes from there, and I hope, now it is a little better.

[Sineos]

From the eyes emoticon, I gather you found my comment confusing. What I tried to say:

The display template functions in Klipper for LEDs and fans (example) seem to be using the same overarching logic, albeit with a bit of different nomenclature.
Maybe I'm misunderstanding something?

[nefelim4ag]

The display template functions in Klipper for LEDs and fans (example) seem to be using the same overarching logic, albeit with a bit of different nomenclature.

I got the idea of what you meant after your comment in the temperature_fan PR.
I'm looking for what can be done to make it similar to current integration with `[display_templates]'.
The current integration feels a little unintuitive from my perspective, but it is better to reuse it, of course.

Thanks for checking. I was totally unaware of that functionality, now I will try to wrap my head around it.

[nefelim4ag]

I don't know how I feel about adding a G-code command to reload the template or directly alter the PWM output.
I also think it is wrong to add custom value get/set/log functions to all templates by incorporating them in display_template.
So, I dropped them for now.

So, for now, I only leave here a bare config binding between template and heater.
If it is needed, technically, temperature and read time can be propagated in the template context.
But I think they are mostly useless without state management inside macro.

Thanks.