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_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
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