New heater tuning algorithm

[oliof]

@dc42 said in New heater tuning algorithm:

Subject to the feedback I receive from beta testers, I hope to include it in tool and expansion board firmware too in the RRF 3.2 final release.

My body printer is ready for testing.

[jbarros]

I'm available for testing too when the firmware for the Toolboards is available

[Veti]

@jbarros said in New heater tuning algorithm:

I'm available for testing too when the firmware for the Toolboards is available

see
https://forum.duet3d.com/topic/19763/reprapfirmware-3-2beta3-2-released

[jbarros]

@Veti my understanding of dc42's post is that the new heater tuning algorithm is going to be tested on the 6HC and if all goes well Toolboard and Expansions will be supported on the final release.
I was hoping to test it before the final release so it gets more exposure but alas not my decision.

Nonetheless I tried running the auto tune just to check if you might be right but not yet:

M303 T0
Error: M303: remote heater auto tune not implemented

[Veti]

have you updated the toolboard as per the changelog?

[Duet 3 + expansion/tool boards] You must also update expansion and tool board firmwares to 3.2beta3.2, otherwise heaters on expansion/tool boards will not work properly

[dc42]

I am waiting for feedback from users of all Duet Wifi/Ethernet, Maestro and Duet 3 main boards on this new algorithm in RRF3.2beta3.2. If and when I have enough feedback to confirm that the new algorithm is working well, I will implement it on tool and expansion boards.

[jay_s_uk]

@dc42 is it typical now that the tuning now Carey's put the cycle 5 times?
I also wasn't clear whether I should be starting the tune with the fan on? Also, what difference does it make using the T value? Is the preferred method to use the tool number?
Will this affect tuning of beds much or is it mainly aimed at hotends?

[gloomyandy]

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

[oliof]

When doing this with the bed heater, phase 3 also says "fan off". This is likely just a cosmetic issue, as the part cooling fan wasn't on during the first couple cycles.

[deckingman]

@oliof said in New heater tuning algorithm:

When doing this with the bed heater, phase 3 also says "fan off". This is likely just a cosmetic issue, as the part cooling fan wasn't on during the first couple cycles.

Are you saying that the bed heater tuning also runs multiple cycles? If so, is that the number of cycles changeable by the user ? If not, that would be huge problem with a big, thick, insulated build plate such as I have because it takes maybe 50 minutes to cool. So one heater tuning cycle using the current algorithm takes about an hour or more and I most certainly wouldn't want to have to repeat that multiple times.

[jay_s_uk]

@deckingman said in New heater tuning algorithm:

Are you saying that the bed heater tuning also runs multiple cycles? If so, is that the number of cycles changeable by the user ? If not, that would be huge problem with a big, thick, insulated build plate such as I have because it takes maybe 50 minutes to cool. So one heater tuning cycle using the current algorithm takes about an hour or more and I most certainly wouldn't want to have to repeat that multiple times.

It doesn't cycle fully, just by 5 degrees

[oliof]

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. So you will likely save some time compared to previously if you need PID tuning for different target temps, because you could go and run it for 60, then 80, then 100C, and would not need to wait until the bed cools down to 30 inbetween. So depending on the way you do manage your PIDs, the process is only marginally longer, or may even be shorter with a larger bed.

[A Former User]

@deckingman said in New heater tuning algorithm:

@oliof said in New heater tuning algorithm:

When doing this with the bed heater, phase 3 also says "fan off". This is likely just a cosmetic issue, as the part cooling fan wasn't on during the first couple cycles.

Are you saying that the bed heater tuning also runs multiple cycles? If so, is that the number of cycles changeable by the user ? If not, that would be huge problem with a big, thick, insulated build plate such as I have because it takes maybe 50 minutes to cool. So one heater tuning cycle using the current algorithm takes about an hour or more and I most certainly wouldn't want to have to repeat that multiple times.

@dc42

Since I also have build as a job a printer with a huge aluminum-plate (I think it was 750x750x8 or 10mm or so) I would also support that multiple cycles can be "optional" limited (which is the same as disabled if you put the limit to 1 cycle), because each cycle just takes too long... If the optional variable is not put, the system would do by default the amount of cycles it needs (the new approach)...
By this those kind of printers with huge thermal-mass-print-plates could benefit by the multiple-cycle approach for the extruder but could avoid its side-effects regarding the heat-plate ? Because of the huge thermal mass of those print-plates if the corridor of the PID algorithm for the temp-sensor-limits are narrow enough and resolution of the temp-sensor is high and it is a fast-reacting sensor, maybe 1 cycle could be enough for the plate? It would be also a fall-back solution for those having trouble with the new approach for whatever reason... This implicates that "the first cycle" (and ONLY this one) would behave like as we are used to it (old style)?

[dc42]

@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 pre-filter 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 pre-filter) 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.

[dc42]

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

[dc42]

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

[oliof]

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

[A Former User]

@dc42

Thanks as usual! Just a bit worried.
At the moment can only test with the smaller "renewed" (via the duet-board) 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 duet-boards supporting RRF3.x have enough storage-space another option would be to make it optional via M307 the B-parameter there, 0 for PID, 1 for bang-bang, 2 for the "new iterating PID" or similar...? Just thinking out loud)

[deckingman]

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

[fractalengineer]

Very nice to see betaflight features implemented here