[3.4.0b7+7] Heater overshoot if second K value in M307 is used

[OwenD]

As reported by several users there seems to be some issues with the heating algorithm if the heater is tuned as a tool and a second K value is used.
I have noticed an increase in initial heater overshoot as well compared with earlier firmware versions.

Duet 2 Wifi standalone.
Titan Aqua (water cooled) extruder
E3D V6 running 24v 40W cartridge (measured at 15ohms resistance)
Silicon sock fitted
Nominal voltage is 24.3

If you set up a print that has rapid (short period) fan speed changes, such as in bridging, t appears that there is a boost of power to the heater each time the fan comes on even if the current temp is well above the set value.
In some cases this has triggered a heater fault for me.

In this print (using TPE) I have a default fan speed of zero
External perimeters are set to 35% fan speed and bridging at 80%

Before running it, I did a fresh PID autotune using this command.

M303 T0 P1 S240 F1

and got a result of

M307 H1 R2.848 K0.325:0.197 D10.51 E1.35 S1.00 B0 V24.3

I didn't need to get to the bridging to demonstrate the issue.

Initial heatup seems to give an overshoot of around 10 degrees which is increased from earlier versions.

As soon as the print got to the second layer and began turning the fan on & off as it moved from leg to leg, then this graph resulted.

I then sent this command

M307 H1 R2.848 K0.325:0 D10.51 E1.35 S1.00 B0 V24.3

After which this graph resulted. Note temp has dropped back to target value whereas before it was oscillating about 10 degrees over

I had turned on logging at the start using

M929 P"0:/sys/heater-log.txt" S3

But all I got back when I stopped the print was in the attached file.
I had expected heater values?
heater-log.txt

[OwenD]

@owend
I ran the print again but started logging before I started instead of after all the start Gcode.
It doesn't offer any more info as it only seems to log temps if an adjustment is made to the active temp. (it did show I have a damaged bed causing heightmap issues )
It also doesn't log the M307 command
Let me know if there's something I can do to provide more required info.

Log file attached
heater-log(1).txt

[OwenD]

Just for giggles I turned off the second K value and then checked what the typical temp drop when turning the fan on at different values is.
In this graph the sequence was.

• Stabilise at 225
• Set fan at 33% - Drop was about 2.5 degrees
  *Stabilise at 225
  *Turn fan off - Temp rose about 2 degrees
• Repeat at 66% - temp drop about 3 degrees and increase about the same
• Repeat at 99% - temp drop about 4 degrees and rise about 3 degrees when turned off

So I probably need to work on my fan shroud as it affects the temp despite the silicon sock.
However the +/- 2-3 degrees I get is much better than the temp increase with the second K value active.
I can of course fine tune with lowering PWM values and tweaking K values to make them closer together, but just giving feedback on what the firmware spits out.

[dc42]

@owend what hot end are you using?

The E3D v6 hot end places the thermistor on the opposite side of the nozzle to the heater. This gives the most accurate reading, although it does increase the dead time a little. However, some other hot ends place the thermistor between the heater and the nozzle. This configuration will give a less accurate reading, because when the heater needs to produce more power, the thermistor will read higher then the nozzle temperature. For this type of hot end, the thermistor will show a temperature overshoot when the fan is turned on, even when the nozzle temperature actually drops when the fan is turned on.

[OwenD]

@dc42
It's a genuine E3D V6 hotend, so thermistor is separated from heater by the nozzle.
The initial overshoot is not such a problem (although it is increased since earlier firmware)
The problem is the large increase in temp when short bursts of fan speed changes occur.
This has on several occasions caused a heater fault as it's above the maximum excursion limit.

[OwenD]

This issues persists in V3.4.0RC1
Performed a fresh PID before testing.
If the default fan speed is zero (such as for ABS) and a part of the print gives multiple short bursts of fan for bridging etc, the heater will rise until the maximum excursion limit is reached and the heater goes into fault mode.
If I do the same print but ensure the fan speed never goes below 30%, then the spikes do not happen. (there are small temp changes)
Likewise if I set the second K value to zero it does not error.

[gloomyandy]

@owend Did you re-run the PID tuning with RC1? Not sure if anything has changed in that or not, but may be worth trying if you didn't?

[OwenD]

@gloomyandy
Yes I did a new PID for 3.4RC1 before testing.
There was nothing in the notes to say that anything had changed in heating apart from those directed at slow responding beds, but I thought it worth a shot.

[dc42]

@owend it may be that the position of the head relative to the bed or print affects the nozzle cooling a lot. How far above the bed was the nozzle when you tuned the hot end? I normally tune hot ends with the bed at operating temperature and the nozzle close to the bed.

You can reduce the second K value manually if you need to.

[OwenD]

@dc42
I normally do the PID tuning at about 5mm from the bed, but the bed was probably cold, so I'll run it again.
I can indeed "solve" the issue by manually adjusting the second K value and don't mind doing so, but this behaviour wasn't evident with earlier versions.
I can't roll back far without breaking a bunch of macros.

[Dogma2k]

I have the same problem since 3.4.0beta7+7 and 3.4.0RC1.
Whenever the fan speed changes, the algorithm doesn't seem to take it into account. I always print my bridges very slowly and therefore reduce my fan speed slightly during this time, the target temperature is always overridden by approx. 5 Kelvin to the target value, even if the change is very short (e.g. 3mm bridge).

[Dogma2k]

IMG_5123.mp4

[OwenD]

Initial testing suggests that 3.4RC2+2 fixes this issue.

https://forum.duet3d.com/post/274456

I'll mark this as solved.

[dc42]

@owend thanks for confirming.