M190 / M109 optionally wait for stable power after stable temperature to sense equilibrium?

Features
1

Many heated beds have the temperature sensor on the bottom of the bed and no direct sensing of the surface temperature.

As a result, there is often a suggestion to pre-heat the bed and wait for some fixed amount of time for it to heat up so that the surface reaches approximately the target temperature. But, of course, the time it takes to heat up depends on the starting temperature and the environmental temperature. A G4 can of course be used to insert a fixed delay that is considered good enough, but that wastes preheating, and to be reliable has to be quite conservative.

I use fluidd, in which I can watch the pwm duty cycle (reported as % power) after the bed reaches target temperature. As long as the pwm duty cycle is reducing, the colder top surface is still heating up. When the pwm duty cycle quits changing much, then the system is at equilibrium, and the surface temperature has stopped changing, which is the key characteristic for safely printing without chance of adhesion failure.

I could imagine heater configuration called stable_pwm_range and stable_pwm_time such that, after _wait_for_temperature is done, a new _wait_for_power function waits for the pwm duty cycle to stay within a range of values limited by stable_pwm_range for an entire stable_pwm_time window before the associated M190 or M109 command completes.

So if I note that my bed power fluctuates only 4% (e.g., between 47% and 51% in some given environmental conditions) once it has reached equilibrium, and that it tends to change at least 1% every 5 seconds before reaching equilibrium, then I might want to wait a bit longer than 4% times 5 seconds to be sure, I might want it to wait to print until the power used to maintain temperature has stayed within 4% for at least 22 seconds. Then I would have have the following configuration:

[heater_bed]
heater_pin: ...
sensor_pin: ...
...
stable_pwm_range: 4
stable_pwm_time: 22
...

After reaching the target temperature, it would start to keep a sliding window over stable_pwm_time seconds at any convenient rate, and return when that sliding window has filled with entries and all the entries differ by no more than stable_pwm_range percent.

If this config is not set, there would be no change to operation; it should be backward compatible.

There could be an additional stable_pwm_max_wait configuration that would avoid infinite wait if environmental conditions create ongoing power drift beyond what has been demonstrated in testing (say, an oscillating fan in room with un-enclosed printer). I could see this defaulting to, say, five or ten minutes, overridden for any printers with special operating conditions.

This would, of course, work only with PWM (currently, this would be only ControlPID) and not with ControlBangBang.

2

This approach will not work. The PWM value and the heater power and the temperature are direct proportional. So stable PWM == stable temperature == stable heater power.

For a discussion on the temperature difference between the bed’s underside and the printing surface see Dual Loop PID, a accurate bed surface temperature

3

If the power sample window, only if defined, was always collected between a new power setting and finishing my proposed _wait_for_power, that would be better, because it would not introduce an at least winow-length wait for stabilization with small changes. That would be better and I think still not an invasive change.

You appear to be ignoring the ID of PID. Either that, or missing that this isn’t an instantaneous power, but a measure of change of power over time.

The power reported in fluidd stays at 100% until the sensor is around the target temperature, then the reported power slowly ramps down (in my case over several minutes) until it stabilizes, at which point the bed temperature is within an acceptable and essentially constant delta relative to the sensor temperature.

The power used would have to sensed (and therefore be an input to a control system) if it weren’t for the fact that we’re using close enough to ideal components such that duty cycle is very close to power.

Starting from a cold bed, when the sensor reaches a stable temperature, the surface has not yet reached that stable temperature. The instantaneous rate at which heat is conducted from the heater to the surface of the bed depends on the thickness of the bed, the head conductivity of the bed material, and the current temperature delta. But you can think of this either as heat from the heater reaching the surface, or as cold from the surface reaching the heater. The second might be more intuitive here.

When you are heating the bed, as the temperature delta between the surface and the sensor decreases, the power required to maintain temperature at the sensor decreases. You can think of my proposal as a secondary control system; consider the power rate as “sensed” by the PWM rate currently being commanded by the ID part of the PID algorithm. If you try to use a PID algorithm against the output of of a PID algorithm, of course it would misbehave. But a simple window would suffice.

I’m aware that there is a substantial body of research into extensions to the basic PID algorithm, but not of the details of the extensions. It might be that an alternative controller class could be implemented that could help here. But I’m not aware of any that could intrinsically solve this problem.

My general idea could also be implemented, in theory, as maximum power slope over some particular time, but that’s probably harder to explain how to configure, and would need to be hysteresis-tuned in an individual system, which a simple window would not be. I could easily write easy-to-follow documentation for how to tune my proposed stable duty cycle window configuration; I think this would be hard to explain if it were explicitly slope-based in a way that would lead to stable configuration.

That’s very interesting but irrelevant to my situation, as it assumes a second sensor to directly measure bed surface temperature. I’m fully aware of that and read at least the top post aroud when it was posted. My point is unrelated: that it’s possible to use duty cycle as a sufficient proxy for temperature delta between heater-attached temperature sensor and bed surface, reducing the value of a second sensor and making it practically unnecessary at the cost of a short wait, which the user controls.

4

On reflection, I’ve realized that this should not apply to TEMPERATURE_WAIT because that’s explicitly about sensors and has no knowledge of heaters. Therefore I have changed the title to reflect that this would apply to M190 and M109 but not TEMPERATURE_WAIT

5

OK, now I’ve found PID_SETTLE_DELTA and PID_SETTLE_SLOPE

While you said that the approach won’t work, perhaps you actually meant that it generally does work and is already implemented?

:smiling_face:

Maybe it’s just a question of being able to configure the slope to something other than the default 0.1 on a per-heater basis?

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.