This is just a proposal.
Problem:
PID can oscillate too much for some users. While printing because of large hot end flow changes or powerful fan, hotend can temporarily lose temperature.
There are several attempts to change something in PID or propose different solutions to that problem (MPC, velocity PID, other calibration methods).
I personally think there is a minority of users with such problems, and I feel like my solution is mostly “duct tape”.
There are 3 patches:
-
Allow configure/decrease pwm delay.
-
Allow configure/decrease adc interval.
They both improve response time a little, and a decrease in PWM delay can possibly decrease system stability. ADC interval, I think has no side effects (a little more MCU load).
They are both mostly for “Bamboo” cases, overpowered hotend with low thermal mass.
Remove the 300ms heater control delay? - #11 by koconnor -
Allow compensation of thermal losses depending on “fan” power.
I do not think PWM should be changed, but we can peek some ideas from Marlin MPC.
PWM is mostly self-regulated and can account for system balance changes.
Our thermal balance is more or less linear system:
- Thermal loss to melt filament.
- Thermal loss to the environment.
- Thermal loss to the cooling fan.
We can of course do some equations, but I think there is a simple way.
We have temperature/PWM graphs for estimation.
Example estimation to prove the point:
There are filament extrusion, 0-> 24 mm^3/s.
min 218.5, max 221.2
I have CHC Pro heater, according to “the datasheet” with temperatures 200-250 there is 50W of power on 23.8V. The actual voltage on the connector is 24.5v.
50 / 23.8 = 2.1А
23.8 / 2.1 = 11.3Om
24.5 / 11.3 = 2.16A
24.5 * 2.16 = 52.9W
There is around 30% PWM in idle ~ 15.87W.
With 24mm^3/s there are 50% peak ~ 26.45W.
My eSUN PLA+ has density: 1.23 g/cm3
Heat capacity is unknown, I use data from seas3d PLA 1,800 J/kg·K,
Heat capacity: PLA 1.8 J/g-°C
The environmental temperature is 23 °C.
To heat up filament with the flow 24 mm^3/s from 23C to 220C:
1000 mm^3/s == 1 cm^3
1.23 / 1000 * 24 = 0.0295 g/s
To heat up by 1 degree:
1.8 * 0.0295 = 0.0531 J/°C
I want to heatup it by 220 - 23 = 197C
0.0531 * 197 = 10.46J
J/s is Watt. 10,5W is enough.
Let’s check our simple model:
According to above PWM %, I used 26.45 - 15.87 = 10.58W
According to my calculation, I need 10.48W
Error is around 0.1W.
I personally expected a slightly larger error, maybe I’m just lucky here.
Anyone who is interested can do the same, with different heater, plastic, temperature & etc.
I think those can be extrapolated to a cooling fan and thermal losses.
*I use decreased smooth time, like 0.2s.
Below are some data for the above patches:
Current master
min: 217.77, max: 221.63
[extruder]
sensor_interval: 0.1
smooth_time: 0.2
pwm_delay: 0.05
min: 217.95, max: 221.55
According to PWM values, my FAN removes around 15% of the heater power.
Fan compensation, default PWM/Sensor interval:
[extruder]
fan: fan
fan_power_loss: 0.15
min: 219.6, max: 220.5
So, it is pretty stable here.
My thoughts, they can be wrong:
A better solution than mine to improve system control is to use something like continuous ADC sampling on STM32, then we can feed that values to klippy. Then we can query it as often and as many as we want, and push that values to klippy. Like in sensors bulk.
I don’t know if there is a case where we actually ‘schedule’ heater PWM. It looks reactive. So, to remove strict timer requirements we can instead send it like:
queue_pwm_out oid=%c count=%u on_ticks=%u
Where the ‘count’ is, on each duty cycle it is decreased
I’m not sure if queue_digital_out can be reused there, it is used not only in heater logic.
I think this is more or less, proper solution
About PID/PWM and FAN/Filament flow.
It should work with this simple solution, I think.
But the actual implementation in code is dirty, it feels wrong to my eye to put everything in the heater class and use lookup_objects to side load data.
Maybe we can reload it to ExtruderHeaterPid and later modify it in PrinterExtruder? Who knows.
I hope it helps someone, with the above changes anyone interested can play around and do personal tests.
Thanks.
There are old topic where are current constants explained