New heater tuning algorithm

@gloomyandy said in New heater tuning algorithm:
Hi David,
a quick bit of feedback on the new heater tuning mechanism when it is used with the LPC port.On the LPC the ADC is quite noisy to the extent that we have a prefilter on the readings (that uses a median filter). On my test machine I tested with just that filter and with the standard RRF temperature filter disabled. In this configuration I occasionally (about 50% of the time) had a result in which the tuning was not consistent and so ran for the max 30 cycles (with the fan not being used) and produced a warning message.
If I enable the RRF filter (in addition to the prefilter) then the same printer completes the test in from 5 to 7 cycles (again with the "fan on" test not run). This same hardware ran the old algorithm fine with the RRF filter disabled. I suspect that this may mean that the new algorithm may be slightly more sensitive to noise than the older one. I'm not sure if this is an issue (especially with Duet hardware), but I thought it might be of interest.
The old algorithm calculated the heating rate using the entire time to heat up. from room temperature to target temperature. Likewise it calculated the cooling time by monitoring a long cooldown time at the end. The new algorithm cycles between the target temperature and 5C below it. It measures the heating and cooling rates on the last 3C each cycle, and accumulates the mean and standard deviation. If there is a lot of noise in the ADC readings then that noise will be a greater proportion of that 3C, so the data quality (as shown by the standard deviation) will be less good and it will do more cycles.
You could try increasing that 5C value to reduce the effect of noise, although it will lengthen the tuning process. It's TuningHysteresis in LocalHeater.h.

@LB, I suggest you try the new algorithm on your bed heater. The new algorithm doesn't need the long cooldown period at the end, so it won't necessarily take longer.

@oliof said in New heater tuning algorithm:
What Jay said, and then: If you do need to do multiple runs for different target temperatures, the new "A" parameter for ambient temperature allows you to start a new cycle before the bed cooled down.
That's true; but it should not normally be necessary to tune at more than one temperature. An exception might be if you use a heated chamber and the chamber temperature varies a lot depending on the material.
BTW in you use a heated chamber then the tuning for the hot end heaters should be done with the chamber up to temperature, and "ambient temperature" will be the chamber temperature.

Another use may be multizone heaters like Keenoovo offers for larger beds I guess.

Thanks as usual! Just a bit worried.
At the moment can only test with the smaller "renewed" (via the duetboard) anycubic here. With this little 220x220mm plate, I guess it will be fine.
The other printer with the big plate is a few hundred km away...(If all duetboards supporting RRF3.x have enough storagespace another option would be to make it optional via M307 the Bparameter there, 0 for PID, 1 for bangbang, 2 for the "new iterating PID" or similar...? Just thinking out loud)

@dc42 said in New heater tuning algorithm:
@LB, I suggest you try the new algorithm on your bed heater. The new algorithm doesn't need the long cooldown period at the end, so it won't necessarily take longer.
But does it still need to "cycle" the temperature by 5 deg C or so? That in itself is likely to be problematic with a large (and insulated) thermal mass.

Very nice to see betaflight features implemented here

@deckingman said in New heater tuning algorithm:
@dc42 said in New heater tuning algorithm:
@LB, I suggest you try the new algorithm on your bed heater. The new algorithm doesn't need the long cooldown period at the end, so it won't necessarily take longer.
But does it still need to "cycle" the temperature by 5 deg C or so? That in itself is likely to be problematic with a large (and insulated) thermal mass.
If the overshoot and undershoot is small and the temperature sensors are not noisy, then it would be possible to use a smaller temperature range.

I originally posted by mistake in 3.2beta3.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:
Auto tune starting phase 1, heater on Auto tune starting phase 2, heater settling Sample 1 dLow 1250.000000 tOn 11250.000000 heatingRate 0.585193 Sample 1 dHigh 1750.000000 tOff 22750.000000 coolingRate 0.268330 tOn 11250±0, tOff 22750±0, dHigh 1750±0, dLow 1250±0, R 0.585±0.000, C 0.268±0.000, V 0.0±0.0, cycles 1 Sample 2 dLow 1250.000000 tOn 11500.000000 heatingRate 0.581589 Sample 2 dHigh 2500.000000 tOff 25750.000000 coolingRate 0.234478 tOn 11375±125, tOff 24250±1500, dHigh 2125±375, dLow 1250±0, R 0.583±0.002, C 0.251±0.017, V 0.0±0.0, cycles 2 Auto tune starting phase 3, fan off Sample 1 dLow 1000.000000 tOn 10750.000000 heatingRate 0.608868 Sample 1 dHigh 2500.000000 tOff 28250.000000 coolingRate 0.222683 tOn 10750±0, tOff 28250±5, dHigh 2500±0, dLow 1000±0, R 0.609±0.000, C 0.223±0.000, V 0.0±0.0, cycles 1 Sample 2 dLow 1250.000000 tOn 10250.000000 heatingRate 0.629652 Sample 2 dHigh 2750.000000 tOff 30750.000000 coolingRate 0.197948 tOn 10500±250, tOff 29500±1250, dHigh 2625±125, dLow 1125±125, R 0.619±0.010, C 0.210±0.012, V 0.0±0.0, cycles 2 Sample 3 dLow 1000.000000 tOn 9750.000000 heatingRate 0.676344 Sample 3 dHigh 2250.000000 tOff 34000.000000 coolingRate 0.179575 tOn 10250±408, tOff 31000±2354, dHigh 2500±204, dLow 1083±118, R 0.638±0.028, C 0.200±0.018, V 0.0±0.0, cycles 3 Sample 4 dLow 1250.000000 tOn 9750.000000 heatingRate 0.678182 Sample 4 dHigh 2250.000000 tOff 37500.000000 coolingRate 0.164589 tOn 10125±415, tOff 32625±3475, dHigh 2438±207, dLow 1125±125, R 0.648±0.030, C 0.191±0.022, V 0.0±0.0, cycles 4 Sample 5 dLow 750.000000 tOn 9250.000000 heatingRate 0.724365 Sample 5 dHigh 2500.000000 tOff 40000.000000 coolingRate 0.153312 tOn 9950±510, tOff 34100±4285, dHigh 2450±187, dLow 1050±187, R 0.663±0.041, C 0.184±0.025, V 0.0±0.0, cycles 5 Sample 6 dLow 1000.000000 tOn 9250.000000 heatingRate 0.710471 Sample 6 dHigh 3000.000000 tOff 43500.000000 coolingRate 0.142683 tOn 9833±534, tOff 35667±5251, dHigh 2542±267, dLow 1042±172, R 0.671±0.041, C 0.177±0.027, V 0.0±0.0, cycles 6 Sample 7 dLow 1000.000000 tOn 9000.000000 heatingRate 0.728104 Sample 7 dHigh 3000.000000 tOff 46500.000000 coolingRate 0.134402 tOn 9714±574, tOff 37214±6165, dHigh 2607±295, dLow 1036±160, R 0.679±0.043, C 0.171±0.029, V 0.0±0.0, cycles 7 Sample 8 dLow 750.000000 tOn 8750.000000 heatingRate 0.762012 Sample 8 dHigh 2500.000000 tOff 49500.000000 coolingRate 0.128104 tOn 9594±624, tOff 38750±7054, dHigh 2594±278, dLow 1000±177, R 0.690±0.048, C 0.165±0.031, V 0.0±0.0, cycles 8 Sample 9 dLow 1000.000000 tOn 9000.000000 heatingRate 0.740379 Sample 9 dHigh 3000.000000 tOff 52250.000000 coolingRate 0.125191 tOn 9528±617, tOff 40250±7889, dHigh 2639±291, dLow 1000±167, R 0.695±0.048, C 0.161±0.032, V 0.0±0.0, cycles 9 Sample 10 dLow 1000.000000 tOn 9000.000000 heatingRate 0.765968 Sample 10 dHigh 3500.000000 tOff 57000.000000 coolingRate 0.110748 tOn 9475±607, tOff 41925±9015, dHigh 2725±378, dLow 1000±158, R 0.702±0.051, C 0.156±0.034, V 0.0±0.0, cycles 10 Sample 11 dLow 750.000000 tOn 9000.000000 heatingRate 0.739456 Sample 11 dHigh 2500.000000 tOff 58000.000000 coolingRate 0.106328 tOn 9432±594, tOff 43386±9759, dHigh 2705±366, dLow 977±167, R 0.706±0.049, C 0.151±0.035, V 0.0±0.0, cycles 11 Sample 12 dLow 500.000000 tOn 8750.000000 heatingRate 0.766151 Sample 12 dHigh 3000.000000 tOff 60750.000000 coolingRate 0.104071 tOn 9375±599, tOff 44833±10504, dHigh 2729±360, dLow 938±207, R 0.711±0.050, C 0.147±0.036, V 0.0±0.0, cycles 12 Sample 13 dLow 750.000000 tOn 8750.000000 heatingRate 0.743942 Sample 13 dHigh 3250.000000 tOff 61500.000000 coolingRate 0.103689 tOn 9327±600, tOff 46115±11026, dHigh 2769±373, dLow 923±205, R 0.713±0.049, C 0.144±0.037, V 0.0±0.0, cycles 13 Sample 14 dLow 750.000000 tOn 8750.000000 heatingRate 0.793538 Sample 14 dHigh 3500.000000 tOff 62500.000000 coolingRate 0.101916 tOn 9286±597, tOff 47286±11432, dHigh 2821±406, dLow 911±203, R 0.719±0.051, C 0.141±0.037, V 0.0±0.0, cycles 14 Sample 15 dLow 0.000000 tOn 8750.000000 heatingRate 0.053600 Sample 15 dHigh 3500.000000 tOff 63250.000000 coolingRate 0.098418 tOn 9250±592, tOff 48350±11740, dHigh 2867±427, dLow 850±300, R 0.675±0.173, C 0.138±0.037, V 0.0±0.0, cycles 15 Sample 16 dLow 500.000000 tOn 8500.000000 heatingRate 0.790129 Sample 16 dHigh 3250.000000 tOff 64000.000000 coolingRate 0.097789 tOn 9203±601, tOff 49328±11982, dHigh 2891±424, dLow 828±303, R 0.682±0.170, C 0.136±0.037, V 0.0±0.0, cycles 16 Sample 17 dLow 0.000000 tOn 8750.000000 heatingRate 0.056186 Sample 17 dHigh 3250.000000 tOff 64250.000000 coolingRate 0.100125 tOn 9176±593, tOff 50206±12143, dHigh 2912±420, dLow 779±352, R 0.645±0.221, C 0.134±0.037, V 0.0±0.0, cycles 17 Sample 18 dLow 750.000000 tOn 8250.000000 heatingRate 0.805200 Sample 18 dHigh 3000.000000 tOff 64250.000000 coolingRate 0.096790 tOn 9125±614, tOff 50986±12231, dHigh 2917±408, dLow 778±342, R 0.654±0.218, C 0.132±0.037, V 0.0±0.0, cycles 18 Sample 19 dLow 750.000000 tOn 8500.000000 heatingRate 0.771688 Sample 19 dHigh 3000.000000 tOff 66000.000000 coolingRate 0.094537 tOn 9092±614, tOff 51776±12368, dHigh 2921±398, dLow 776±333, R 0.660±0.214, C 0.130±0.037, V 0.0±0.0, cycles 19 Sample 20 dLow 750.000000 tOn 8500.000000 heatingRate 0.797152 Sample 20 dHigh 3750.000000 tOff 65500.000000 coolingRate 0.094485 tOn 9062±612, tOff 52462±12421, dHigh 2962±428, dLow 775±325, R 0.667±0.211, C 0.128±0.037, V 0.0±0.0, cycles 20 Sample 21 dLow 1000.000000 tOn 8500.000000 heatingRate 0.781730 Sample 21 dHigh 3000.000000 tOff 66250.000000 coolingRate 0.097950 tOn 9036±609, tOff 53119±12472, dHigh 2964±418, dLow 786±321, R 0.673±0.207, C 0.126±0.037, V 0.0±0.0, cycles 21 Sample 22 dLow 0.000000 tOn 8500.000000 heatingRate 0.056254 Sample 22 dHigh 3500.000000 tOff 67500.000000 coolingRate 0.093961 tOn 9011±605, tOff 53773±12548, dHigh 2989±423, dLow 750±354, R 0.645±0.239, C 0.125±0.036, V 0.0±0.0, cycles 22 Sample 23 dLow 750.000000 tOn 8500.000000 heatingRate 0.789738 Sample 23 dHigh 3250.000000 tOff 66500.000000 coolingRate 0.094778 tOn 8989±601, tOff 54326±12544, dHigh 3000±417, dLow 750±346, R 0.651±0.236, C 0.124±0.036, V 0.0±0.0, cycles 23 Sample 24 dLow 750.000000 tOn 8500.000000 heatingRate 0.794132 Sample 24 dHigh 3750.000000 tOff 66250.000000 coolingRate 0.097583 tOn 8969±596, tOff 54823±12508, dHigh 3031±435, dLow 750±339, R 0.657±0.233, C 0.123±0.036, V 0.0±0.0, cycles 24 Sample 25 dLow 0.000000 tOn 8500.000000 heatingRate 0.055224 Sample 25 dHigh 3500.000000 tOff 66750.000000 coolingRate 0.095105 tOn 8950±592, tOff 55300±12477, dHigh 3050±436, dLow 720±363, R 0.633±0.257, C 0.121±0.035, V 0.0±0.0, cycles 25 Sample 26 dLow 1000.000000 tOn 8500.000000 heatingRate 0.797152 Sample 26 dHigh 3000.000000 tOff 66500.000000 coolingRate 0.095806 tOn 8933±587, tOff 55731±12422, dHigh 3048±428, dLow 731±360, R 0.639±0.254, C 0.120±0.035, V 0.0±0.0, cycles 26 Sample 27 dLow 1250.000000 tOn 8500.000000 heatingRate 0.793937 Sample 27 dHigh 3750.000000 tOff 66500.000000 coolingRate 0.093961 tOn 8917±581, tOff 56130±12359, dHigh 3074±440, dLow 750±366, R 0.645±0.251, C 0.120±0.035, V 0.0±0.0, cycles 27 Sample 28 dLow 1000.000000 tOn 8250.000000 heatingRate 0.805200 Sample 28 dHigh 3000.000000 tOff 65750.000000 coolingRate 0.093893 tOn 8893±584, tOff 56473±12267, dHigh 3071±432, dLow 759±363, R 0.651±0.248, C 0.119±0.034, V 0.0±0.0, cycles 28 Sample 29 dLow 750.000000 tOn 8500.000000 heatingRate 0.783488 Sample 29 dHigh 2750.000000 tOff 67000.000000 coolingRate 0.095667 tOn 8879±578, tOff 56836±12205, dHigh 3060±429, dLow 759±356, R 0.655±0.245, C 0.118±0.034, V 0.0±0.0, cycles 29 Sample 30 dLow 1000.000000 tOn 8500.000000 heatingRate 0.808610 Sample 30 dHigh 2750.000000 tOff 66750.000000 coolingRate 0.092288 tOn 8867±573, tOff 57167±12131, dHigh 3050±425, dLow 767±353, R 0.660±0.242, C 0.117±0.034, V 0.0±0.0, cycles 30 Warning: heater behaviour was not consistent during tuning tOn 8867±573, tOff 57167±12131, dHigh 3050±425, dLow 767±353, R 0.660±0.242, C 0.117±0.034, V 0.0±0.0, cycles 30 Auto tuning heater 0 completed after 30 cycles in 2137 seconds. This heater needs the following M307 command: M307 H0 R0.788 C289.8 D2.74 S1.00 V0.0 Edit the M307 H0 command in config.g to match this. Heater 0 switched off
and this is the output from the "preheated" case:
Auto tuning heater 0 using target temperature 60.0°C and PWM 1.00  do not leave printer unattended ok Auto tune starting phase 2, heater settling Sample 1 dLow 750.000000 tOn 9250.000000 heatingRate 0.753922 Sample 1 dHigh 2250.000000 tOff 36000.000000 coolingRate 0.165439 tOn 9250±0, tOff 36000±0, dHigh 2250±0, dLow 750±0, R 0.754±0.000, C 0.165±0.000, V 0.0±0.0, cycles 1 Sample 2 dLow 1000.000000 tOn 9250.000000 heatingRate 0.727826 Sample 2 dHigh 2250.000000 tOff 40250.000000 coolingRate 0.155488 tOn 9250±0, tOff 38125±2125, dHigh 2250±0, dLow 875±125, R 0.741±0.013, C 0.160±0.005, V 0.0±0.0, cycles 2 Auto tune starting phase 3, fan off Sample 1 dLow 1000.000000 tOn 9500.000000 heatingRate 0.699097 Sample 1 dHigh 2500.000000 tOff 43500.000000 coolingRate 0.141769 tOn 9500±0, tOff 43500±0, dHigh 2500±0, dLow 1000±0, R 0.699±0.000, C 0.142±0.000, V 0.0±0.0, cycles 1 Sample 2 dLow 1250.000000 tOn 8750.000000 heatingRate 0.769238 Sample 2 dHigh 2500.000000 tOff 46250.000000 coolingRate 0.132351 tOn 9125±375, tOff 44875±1375, dHigh 2500±0, dLow 1125±125, R 0.734±0.035, C 0.137±0.005, V 0.0±0.0, cycles 2 Sample 3 dLow 750.000000 tOn 8750.000000 heatingRate 0.763718 Sample 3 dHigh 2750.000000 tOff 50750.000000 coolingRate 0.126651 tOn 9000±354, tOff 46833±2988, dHigh 2583±118, dLow 1000±204, R 0.744±0.032, C 0.134±0.006, V 0.0±0.0, cycles 3 Sample 4 dLow 1250.000000 tOn 8500.000000 heatingRate 0.800977 Sample 4 dHigh 3500.000000 tOff 53500.000000 coolingRate 0.115505 tOn 8875±375, tOff 48500±3877, dHigh 2812±410, dLow 1062±207, R 0.758±0.037, C 0.129±0.010, V 0.0±0.0, cycles 4 Sample 5 dLow 1250.000000 tOn 8500.000000 heatingRate 0.761442 Sample 5 dHigh 3500.000000 tOff 56250.000000 coolingRate 0.110297 tOn 8800±367, tOff 50050±4651, dHigh 2950±458, dLow 1100±200, R 0.759±0.033, C 0.125±0.011, V 0.0±0.0, cycles 5 tOn 8800±367, tOff 50050±4651, dHigh 2950±458, dLow 1100±200, R 0.759±0.033, C 0.125±0.011, V 0.0±0.0, cycles 5 Auto tuning heater 0 completed after 5 cycles in 460 seconds. This heater needs the following M307 command: M307 H0 R0.895 C267.3 D2.67 S1.00 V0.0 Edit the M307 H0 command in config.g to match this. Heater 0 switched off
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.

The new autotune is working well for me on Duet 2 board. Thanks for your work on this

Working great here to! Took good over an hour to tune a 330x330x4mm 24v alu heated bed with a 4mm glass surface and cork insulation underneith for 60C tho

@Exerqtor How many cycles did it take to tune your 330x300x4mm bed?

My 300x300x4mm bed took seven or eight cycles. 220V AC bed to 80C

@gloomyandy said in New heater tuning algorithm:
@Exerqtor How many cycles did it take to tune your 330x300x4mm bed?
I didn't look at it tbh! After 45minutes i went downstairs and watched a movie lmao. Just sent a M500 before i went to bed when i saw it was done, then turned off the printer without thinking more about it i just saw it said 4700 something seconds.

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

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).

@gloomyandy said in New heater tuning algorithm:
I originally posted by mistake in 3.2beta3.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?

@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.

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?


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.

@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.

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/1726cdf3647ecf812400cded0b04d295a30420fcLet 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.

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.

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