New heater tuning algorithm

gloomyandy

No problem, sounds like it ran for a fair number of cycles!

Exerqtor

Don't quote me on it, but I THINK it was 11 for the bed. And 7 for the hotend (std Mosquito with a silicone sock, 40mm fan and 50w/12v heater).

dc42

@gloomyandy said in New heater tuning algorithm:

I originally posted by mistake in 3.2-beta3.2 thread, but I think it is better here...

I've been testing the new algorithm on my printer and have seen some strange results when tuning the bed heater. My bed is a 310x310x6mm aluminium plate with a magnetically attached steel sheet on top. The heater is a mains powered 250x250mm 500W Silicon pad (with the thermistor embedded in it). When tuning my target temperature is 60 degrees. Ambient temperature is around 21 degrees. This combination is probably not ideal as there is a lot of lag between the pad thermistor and the actual bed plate temperature.

If I run the tuning from cold then it always seems to run for the full 30 cycles. However if I run it when it has cooled (from 60) to say 30 degrees (using the A parameter to specify the ambient temperature) then it will complete after 5 cycles. To try and understand what is going on I have added some additional debug to the tuning process. Here is the output from the first case:
I suspect that the relatively large thermal mass means that as the full bed heats up it is impacting the heating/cooling times of the test cycle. But there also seems to be something a little odd going on with the "dLow" values as these are sometimes zero.
...
It may well be that I need to add an additional thermistor (perhaps embedded in the edge of the bed) to get more accurate readings of the actual bed temperature. However I don't think the setup I have is that unusual so I thought the data might be of interest to you.

I think I know what is going on. My theory is that systems such as yours behave somewhat like a FOPDT (first order process plus dead time) plus a thermal reservoir that is somewhat weakly coupled to it. When heating from cold, the temperature of the reservoir lags the temperature of the heating element and temperature sensor. It is only when it has heated up to their average temperatures that the behaviour during the tuning cycles becomes stable.

This phenomenon also occurs with hot ends to some extent, which is why the tuning algorithm does two heating/cooling cycles before is starts collecting data. It's clear that with bed heaters like yours, more of these dummy cycles are needed.

I too have a bed heater that behaves in this way, however in my case the thermistor readings have become noisy, so it is not surprising that it always goes the full 30 cycles.

Any solution must not only solve the problem you encountered but also handle noisy thermistors reasonably well, by continuing to average over a reasonably large number of cycles. One option would be to check the consistency after 5 cycles, and if it is poor then throw the data away and start again. So instead of doing 2 dummy cycles and up to 30 real cycles, it would do 7 dummy cycles and up to 25 real cycles. Do you think this would work for your heater?

gloomyandy

@dc42 said in New heater tuning algorithm:

Any solution must not only solve the problem you encountered but also handle noisy thermistors reasonably well, by continuing to average over a reasonably large number of cycles. One option would be to check the consistency after 5 cycles, and if it is poor then throw the data away and start again. So instead of doing 2 dummy cycles and up to 30 real cycles, it would do 7 dummy cycles and up to 25 real cycles. Do you think this would work for your heater?

On my test build I cleared the data every 5 cycles and continued on up to a max of 30 cycles in total. So basically I tuned in groups of 5 cycles. In my case this resulted in the tuning completing after 10 cycles total. So yes I'm pretty sure that your proposal would work in my case (though I'm not sure if it would in the case of even bigger/thicker beds as they might take even longer to heat up). I wonder if there is any way to differentiate between a noisy reading (which will benefit from more readings) and a lagging reading (which probably needs a restart)? But yes I'm pretty sure that being able to extend the dummy cycles would help.

dc42

Some other solutions come to mind:

We could store the last 5 readings instead of just the mean and standard deviation; then we could check whether the last 5 readings are good enough. I am reluctant to do this because of the additional RAM that would be needed. One of the goals of the new algorithm was to use minimal RAM so that it can be implemented on the Duet 3 tool board.
We could monitor the ratio of heating time to cycle time, and continue doing dummy cycles until this stabilises or has the appearance of being noise rather than a trend. For example, wait for the ratio of heating time to cycle time to be at least 95% of the value in the previous cycle.

Your thoughts?

gloomyandy

I agree that it would be a pity not to be able to use the same mechanism for the tool boards. On my system the way that the cooling time gets longer and heating time shorter is very noticeable so yes perhaps that could be used to indicate that things have not stabilised. I'm not show how much noise impacts those readings though?

Oh and I think there may be a bug in the code that determines the dLow time. In the data I posted above this is sometimes 0 which I don't think is correct. I added some extra code to my experimental version which I think fixes it. I'm not at home at the moment so will post more details later. But I think the problem was that sometimes we fail to detect a "low point" correctly after the heater has been turned on and it is using time values from the previous cycle.

dc42

@gloomyandy said in New heater tuning algorithm:

I agree that it would be a pity not to be able to use the same mechanism for the tool boards. On my system the way that the cooling time gets longer and heating time shorter is very noticeable so yes perhaps that could be used to indicate that things have not stabilised. I'm not show how much noise impacts those readings though?

If the temperature readings are noisy then sooner or later the heating time will be at least 95% of the heating time in the last cycle, which would trigger the start of data collection for tuning. So the effect of noise may be to suggest that stabilisation has occurred sooner than it actually has. I am not concerned by this, because we can't expect good results from noisy temperature readings anyway.

Oh and I think there may be a bug in the code that determines the dLow time. In the data I posted above this is sometimes 0 which I don't think is correct. I added some extra code to my experimental version which I think fixes it. I'm not at home at the moment so will post more details later. But I think the problem was that sometimes we fail to detect a "low point" correctly after the heater has been turned on and it is using time values from the previous cycle.

Thanks, I'll wait for the detail from you.

gloomyandy

Hi @dc42 , sorry that took a little longer then I expected!

So the problem I was seeing was that when the bed was hot, occasionally when the tuning code switched from heater off to heater on the temperature would not drop below the temperature recorded in peakTemp, or rather it had already heated to be above that temperature by the next time that the tuning code runs. This resulted in new values for peakTemp, afterPeakTemp, peakTime and afterPeakTime not being captured which in turn resulted in the later if statement:

		else if (afterPeakTime == peakTime && temperature - tuningTargetTemp >= TuningPeakTempDrop - TuningHysteresis)
		{
			afterPeakTime = now;
			afterPeakTemp = temperature;
		}

never being executed. This then gives an odd value for heatingRate as the calculation used the times and values from the previous cooling cycle for afterPeakTime and afterPeakTemp.

I've made some changes to my test branch which seem to help with this (but this may not be the best fix). You can see the changes here:
https://github.com/gloomyandy/RepRapFirmware/commit/1726cdf3647ecf812400cded0b04d295a30420fc

Let me know if any of that makes sense!

Oh and one final thought. With a hot bed we can end up with some very short times in dLow (I've seen values as low as 250mS or 500ms and occasionally 0). With the sample time being 250mS any "jitter" from say 1000 to 750 or 1250 can result in a pretty big impact on the standard deviation and so on the stability test.

0

gloomyandy committed to gloomyandy/RepRapFirmware

Experimental fix for when temperature drop is not detected with heaters
on

dc42

Thanks Andy, I agree with your fix and I have committed it.

We may need to reduce the heat sample time to handle heaters with very short dead times. It's on my work list to make it variable again.

jay_s_uk

@chrishamm
The new heater tuning output doesn't get saved using M500 when a duet is connected to an SBC.
They save fine when in standalone mode

chrishamm

@jay_s_uk This is known and it will be addressed in 3.2-b4. DSF 3.2-b3 doesn't have the new object model properties either, so it cannot save them yet.

jay_s_uk

@chrishamm good. Just wanted to make sure it was known

jay_s_uk

@dc42

Here is a snapshot of the bed tuning being carried out on a my duet 3 in standalone mode.
As you can see, the cool down period takes longer and longer as the bed heats up.
I have a 500x500x10 aluminium bed with a 2kW 240v silicone heater with a thermocouple embedded in it.
These were my results.

Warning: heater behaviour was not consistent during tuning
Auto tuning heater 0 completed after 30 cycles in 1047 seconds. This heater needs the following M307 command:
 M307 H0 R1.489 C145.3 D2.44 S1.00 V27.0
Send M500 to save this command in config-override.g

gloomyandy

@dc42 Hi David,
I've been taking another look at this and have implemented your suggestion:
"One option would be to check the consistency after 5 cycles, and if it is poor then throw the data away and start again. So instead of doing 2 dummy cycles and up to 30 real cycles, it would do 7 dummy cycles and up to 25 real cycles."

Though in my case it will actually still run up to 30 real cycles after the 7 dummy ones. I basically added a new phase to insert the extra dummy cycles. I've been testing it and it works fine for me and the results it produces are pretty consistent. You can see the changes I made here: https://github.com/gloomyandy/RepRapFirmware/commit/868993b6e534e985bf5fe689a76ed33ce4ddb9a1

I've also been running a number of tests using the results from the new tuning code on both my bed and hot end heaters and so far it looks pretty good. I see very stable temperatures both with and without the cooling fan. The initial overshoot is pretty low (approx 2 degrees on the hotend and less than 1 degree on the bed).

0

gloomyandy committed to gloomyandy/RepRapFirmware

Run extra 5 tuning cycles if readings are not stable

pixelpieper

Hi, @dc42 - I think I found a bug when using multiple thermistors together with M143 monitors. I use a duet Maestro with an AC powered silicone mat heater. I have the heater configured such that a) we regulate for a thermistor placed on the edge of the aluminum bed (Bedplate) but I want the thermistor integrated inside the silicone mat (Bedmat) not to reach temperatures higher than 130°C - hence I have configured two monitors with M143, disabling the heater temporarily once the mat reaches 130°C:

;; thermal -------------------------------------------------
; Sensors --------------------------------------------------
M308 S0 P"bedtemp" Y"thermistor" T100000 B3950 A"Bedmat"; configure sensor 0 as thermistor on pin temp0
M308 S1 P"e0temp" Y"pt1000" A"Hotend"  ; configure sensor 1 as thermistor
M308 S2 P"ctemp" Y"thermistor" T100000 B3950 A"Chamber"	;Chamber fan
M308 S3 Y"mcu-temp" A"Board"
M308 S4 P"e1temp" Y"thermistor" T100000 B3950 A"Bedplate"
 
; Heaters --------------------------------------------------
;Bed
M950 H0 C"bedheat" T4                           ; create bed heater output on out0 and map it to sensor 4
M950 H1 C"e0heat" T1                           ; create nozzle heater output on e0heat and map it to sensor 1
M140 H0   

;PID Settings
M307 H0 A301.0 C845.3 D1.4 S1.00 V23.6 B0	
M307 H1 A482.6 C291.7 D5.5 S1.00 V23.6 B0 ;V6

; Monitors & Limits
M143 H0 P1 T0 A2 S130 C0                     ; Regulate (A2) bed heater (H0) to have pad sensor (T0) below 130°C. Use Heater monitor 1 for it
M143 H0 P2 T0 A0 S135 C0                     ; Fault (A0) bed heater (H0) if pad sensor (T0) exceeds 135°C. Use Heater monitor 2 for it
M143 H0 P0 S120                            ; Set bed heater max temperature to 120°C, use implict monitor 0 which is implicitly configured for heater fault
M143 H1 S400                                  ; set temperature limit for heater 1 to 275C

I would have assumed these monitors would be also considered when tuning, but that does not seem to be the case, I peak 40°C over my limit of 130°C:

After tuning M143 works again as expected:

dc42

@gloomyandy said in New heater tuning algorithm:

I've been taking another look at this and have implemented your suggestion:
"One option would be to check the consistency after 5 cycles, and if it is poor then throw the data away and start again. So instead of doing 2 dummy cycles and up to 30 real cycles, it would do 7 dummy cycles and up to 25 real cycles."

Thanks; but I'd rather try my other suggestion, i.e. do idle cycles until the on-time settles (or a limit is reached). That way it should usually do less than 7 idle cycles.

dc42

@pixelpieper said in New heater tuning algorithm:

Hi, @dc42 - I think I found a bug when using multiple thermistors together with M143 monitors. I use a duet Maestro with an AC powered silicone mat heater. I have the heater configured such that a) we regulate for a thermistor placed on the edge of the aluminum bed (Bedplate) but I want the thermistor integrated inside the silicone mat (Bedmat) not to reach temperatures higher than 130°C - hence I have configured two monitors with M143, disabling the heater temporarily once the mat reaches 130°C:

As with the old heater tuning algorithm, the new one will always overshoot the target temperature. You need to be aware of this when choosing the target temperature. The heater itself is switched off when the target temperature is reached, so the overshoot is purely due to excess thermal mass in the heater and poor coupling to the thermistor.

gloomyandy

@dc42 said in New heater tuning algorithm:

Thanks; but I'd rather try my other suggestion, i.e. do idle cycles until the on-time settles (or a limit is reached). That way it should usually do less than 7 idle cycles.

Hi I'll be interested to see how well that works. I did play around with something along those lines but could not find a good stability test that only needed a small number of cycles. I should also have said that in the my test version if the overall results are stable after 5 cycles then it will use those results (as it does now), the extra cycles are only used if things are not stable.

Let me know if you want me to give anything a try.

jaymcd0626

Tried this and the cycle never seems to stop.

https://forum.duet3d.com/topic/20046/attempting-to-pid-tune-my-heat-bed?_=1606325917554

jay_s_uk

@jaymcd0626 it'll get to 30 cycles and then fail but will give you an output. This can be used for the time being.
Dc42 is going to be tweaking the heater algorithm