New heater tuning algorithm

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

jbarros

Just to add some data into this, I just performed pid tuning on a new printer I'm finishing, new heater model so I don't have a baseline for it.

Heater: Keenovo 240V 750W 300x300mm
Bed: 310x310x4mm

RepRapFirmware for Duet 3 MB6HC version 3.2-beta4 running on Duet 3 MB6HC v1.01 or later (standalone mode)

M308 S0 P"temp0" Y"thermistor" T100000 B3950       ; configure sensor 0 as thermistor on pin temp0 - 100k beta 3950 1% thermistor (Used in Keenovo AC silicone mats)

28/11/2020, 22:47:58 M307 H0
Heater 0 model: heating rate 0.911, cooling time constant 393.9, dead time 1.81, max PWM 1.00, calibration voltage 24.1, mode PIDComputed PID parameters: setpoint change: P108.5, I4.069, D137.1, load change: P108.5, I13.719, D137.1
28/11/2020, 22:47:53 M303
Heater 0 tuning succeeded, use M307 H0 to see result
28/11/2020, 22:44:05 Warning: heater behaviour was not consistent during tuningAuto tuning heater 0 completed after 30 cycles in 1711 seconds. This heater needs the following M307 command: M307 H0 R0.911 C393.9 D1.81 S1.00 V24.1
Edit the M307 H0 command in config.g to match this.
28/11/2020, 22:42:06 M303
Heater 0 is being tuned, phase 4 of 4
28/11/2020, 22:18:24 Auto tune starting phase 3, fan off
28/11/2020, 22:17:03 Auto tune starting phase 2, heater settling
28/11/2020, 22:16:29 M303
Heater 0 is being tuned, phase 2 of 4
28/11/2020, 22:15:39 Auto tune starting phase 1, heater on
28/11/2020, 22:15:33 M303 H0 S80
Auto tuning heater 0 using target temperature 80.0°C and PWM 1.00 - do not leave printer unattended

hmortensen

Hi

I've tried tuning my hotend heater after updating to 3.2b4, but this step "Auto tune starting phase 3, fan on" ran for 45 min without finishing, and then I turned it off.

Is something wrong, or should it take this long?

Attached snip of temp chart and console log.

Screenshot 2020-11-29 200054.png

11/29/2020, 7:47:45 PM	M303
Heater 1 is being tuned, phase 5 of 5
11/29/2020, 7:37:59 PM	M303
Heater 1 is being tuned, phase 5 of 5
11/29/2020, 7:11:50 PM	M303
Heater 1 is being tuned, phase 5 of 5
11/29/2020, 7:07:56 PM	M303
Heater 1 is being tuned, phase 5 of 5
11/29/2020, 7:05:29 PM	Auto tune starting phase 3, fan on
11/29/2020, 7:04:57 PM	M303
Heater 1 is being tuned, phase 4 of 5
11/29/2020, 7:02:30 PM	M303
Auto tune starting phase 3, fan off
Heater 1 is being tuned, phase 4 of 5
11/29/2020, 7:01:05 PM	Auto tune starting phase 2, heater settling
11/29/2020, 7:01:03 PM	M303
Heater 1 is being tuned, phase 2 of 5
11/29/2020, 6:58:30 PM	M303
Heater 1 is being tuned, phase 2 of 5
11/29/2020, 6:58:05 PM	Auto tune starting phase 1, heater on
11/29/2020, 6:58:00 PM	M303 T0 S250
Auto tuning heater 1 using target temperature 250.0°C and PWM 1.00 - do not leave printer unattended
11/29/2020, 6:57:47 PM	Connection established
11/29/2020, 6:57:46 PM	Connection interrupted, attempting to reconnect...
HTTP request timed out
11/29/2020, 6:57:36 PM	Upload of config.g successful after 0s
11/29/2020, 6:56:36 PM	M303 T0 S250
Error: M303: heater 1 target temperature must be below the temperature limit for this heater (250.0C)
11/29/2020, 6:44:03 PM	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta4 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7JTDJ-3SS6J-KWVNH
Used output buffers: 3 of 24 (15 max)
=== RTOS ===
Static ram: 24108
Dynamic ram: 104312 of which 40 recycled
Never used RAM 1588, free system stack 188 words
Tasks: NETWORK(ready,148) HEAT(blocked,294) MAIN(running,459) IDLE(ready,20)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:46:27 ago, cause: software
Last software reset details not available
Error status: 0x00
MCU temperature: min 28.1, current 28.9, max 29.4
Supply voltage: min 23.9, current 24.0, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 0, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 0, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-11-29 18:43:55
Cache data hit count 4294967295
Slowest loop: 259.02ms; fastest: 0.19ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.6ms, write time 39.8ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1754.37ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.24
WiFi MAC address 60:01:94:2e:a5:fa
WiFi Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 23840
WiFi IP address 192.168.1.7
WiFi signal strength -64dBm, mode none, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
11/29/2020, 6:43:25 PM	M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.2-beta4 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2020-11-26
11/29/2020, 6:41:14 PM	Connected to 192.168.1.7

dc42

@gloomyandy said in New heater tuning algorithm:

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

I've implemented that algorithm, and it works well on my bed heater that previously needed all 30 cycles. Now it needs 7 idle and 5 tuning cycles. The temperature graph clearly shows that the cooling time increases steadily through the idle cycles.

dc42

@hmortensen said in New heater tuning algorithm:

Hi

I've tried tuning my hotend heater after updating to 3.2b4, but this step "Auto tune starting phase 3, fan on" ran for 45 min without finishing, and then I turned it off.

Is something wrong, or should it take this long?

The tuning algorithm does two idle cycles and up to 30 tining cycles until the data becomes stable. Yout heater struggles to reach 250C, so each cycle is taking 2 minutes. Therefore it could take a little over an hour. You could try using a lower target temperature.

The next update uses a modified algorithm that often reduces the number of cycles needed in cases like yours.

hmortensen

@dc42 said in New heater tuning algorithm:

@hmortensen said in New heater tuning algorithm:

Hi

I've tried tuning my hotend heater after updating to 3.2b4, but this step "Auto tune starting phase 3, fan on" ran for 45 min without finishing, and then I turned it off.

Is something wrong, or should it take this long?

The tuning algorithm does two idle cycles and up to 30 tining cycles until the data becomes stable. Yout heater struggles to reach 250C, so each cycle is taking 2 minutes. Therefore it could take a little over an hour. You could try using a lower target temperature.

The next update uses a modified algorithm that often reduces the number of cycles needed in cases like yours.

Is it possible to control the fan when tuning? I rarely use it at 100% when printing, but the tuning turns it fully on.
Can I see how many cycles it has run so far?
Would the result be usefull at all, if I let it finish, or should I just wait for the next algorithm update?

dc42

@hmortensen said in New heater tuning algorithm:

Is it possible to control the fan when tuning?

No.

I rarely use it at 100% when printing, but the tuning turns it fully on.

When printing, the heating algorithm takes account of using the fan at reduced PWM.

Can I see how many cycles it has run so far?

Only by counting the cycles on the temperature graph.

Would the result be usefull at all, if I let it finish, or should I just wait for the next algorithm update?

Yes it would be useful; however the next version is likely to be available 1 to 2 days from now, so you may prefer to wait.

hmortensen

@dc42 said in New heater tuning algorithm:

@hmortensen said in New heater tuning algorithm:

Is it possible to control the fan when tuning?

No.

I rarely use it at 100% when printing, but the tuning turns it fully on.

When printing, the heating algorithm takes account of using the fan at reduced PWM.

Can I see how many cycles it has run so far?

Only by counting the cycles on the temperature graph.

Would the result be usefull at all, if I let it finish, or should I just wait for the next algorithm update?

Yes it would be useful; however the next version is likely to be available 1 to 2 days from now, so you may prefer to wait.

Redid the tuning after updating to beta 4.1. This time it did finish after 45 min but with a warning.
Then I tried with S230 instead, and that took around 11 min and no warning.
Any guidelines to which temperature to tune at?

After saving with M500, it also rewrote the M307 for bed heater. I didn't retune bed heater yet. Is that normal?

Exerqtor

Just did a new tuning run on my hotend after finally recieving the magnum heatbreak for my mosquito, and well it for sure took a while.

It also ended with a warning:

5.12.2020, 00:43:25	M500
5.12.2020, 00:41:51	Warning: heater behaviour was not consistent during tuning
Auto tuning heater 1 completed after 3 idle and 30 tuning cycles in 3905 seconds. This heater needs the following M307 command:
 M307 H1 R1.216 C265.2:232.2 D8.18 S1.00 V12.5
Send M500 to save this command in config-override.g
4.12.2020, 23:50:07	Auto tune starting phase 3, fan on
4.12.2020, 23:46:14	Auto tune starting phase 3, fan off
4.12.2020, 23:43:18	Auto tune starting phase 2, heater settling
4.12.2020, 23:36:50	Auto tune starting phase 1, heater on
4.12.2020, 23:36:45	M303 T0 S280
Auto tuning heater 1 using target temperature 280.0°C and PWM 1.00 - do not leave printer unattended
4.12.2020, 23:35:48	Connection established

The setup is a Mosquito Magnum with a 12v / 50w heater, silicone sock, 40mm fan for hotend cooling and a "fang-style" part cooler powered by a 12v 5015.

sozkan

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

Hi,
In my case, it took more than 2 and a half hours as seen I have to give up and postpone for later.

How many times it cycles I don`t know.
IT might be from our bed size;

However, the previous PID was very short. The reason I am doing it again because it fail to start heating after the firmware upgrade.

By the way on PID, Dyze dual heater and dual sensor kind of struggling me.
https://docs.dyzedesign.com/typhoon.html#liquid-cooling
It keeps failed. All was working on Duet2and3Firmware-3.1.1

Kind Regards