Temperatures totally wrong 3.4 RC

[droftarts]

@jensus11 Thanks for this info, I've highlighted it for @dc42 's attention. It shows that the PID values are computed pretty much the same in both cases. Just to be clear, did you have heater temperature fluctuations in 3.4-b5?

Ian

[jensus11]

I don't think that was the case in 3.4-b5. It is not possible for me to print a Temptower. The temperature is just fluctuating. With other parts I noticed that the temperature increases in the first layer of the top layer after the infill part.
If I reduced the Bridges fan speed, it's better. I think when the part fan changes fast and slow the fluctuating start. If the partfan is constant, the temperature is also constant.

Tell me what to do to help.

100% Bridges fan speed in my test print

50% Bridges fan speed in my test print

should i upload the gcodes?

[jensus11]

It really must be the transition from infill to top layer. If I only print the botton and then the top layer, it's ok. Exactly the same if I only print perimeter.

[dc42]

@jensus11 please try with the second K parameter in the M307 command missing or set to zero, as @droftarts suggested. This will help me to pin down the problem.

[dc42]

I am running tests on one of my machines with a new hot end installed, and although the behaviour I am seeing is nothing like as bad as reported in this thread, it is evident to me that the heater feedforward when fan PWM is changed is not working correctly even though the M307 parameters appear to be correct. I will continue investigating tomorrow.

[dc42]

I just found the bug that is causing this. I will provide updated RRF builds tomorrow or Wednesday. Meanwhile you can set the second M307 K value to zero to disable feedforward.

[jensus11]

@dc42
I tested it without the second K value. It's better but not good yet. With K0 it looks very good.

[dc42]

@jensus11 @Hernicz @resam @TheDragonLord I've put 3.4.0rc2+2 binaries at https://www.dropbox.com/sh/amtiizdcylnuaye/AAA4hzXFvU0RMOSDtdT37HFua?dl=0 for testing. These should fix this issue. Although the changes are minor, please test them with care.

[A Former User]

@dc42 said in Temperatures totally wrong 3.4 RC:

@jensus11 @Hernicz @resam @TheDragonLord I've put 3.4.0rc2+2 binaries at https://www.dropbox.com/sh/amtiizdcylnuaye/AAA4hzXFvU0RMOSDtdT37HFua?dl=0 for testing. These should fix this issue. Although the changes are minor, please test them with care.

@dc42 said in Temperatures totally wrong 3.4 RC:

@jensus11 @Hernicz @resam @TheDragonLord I've put 3.4.0rc2+2 binaries at https://www.dropbox.com/sh/amtiizdcylnuaye/AAA4hzXFvU0RMOSDtdT37HFua?dl=0 for testing. These should fix this issue. Although the changes are minor, please test them with care.

ok, thanks

[bberger]

Thank you guys for this thread. Up until a few moments ago I was sure it was in my head and been like this forever and expected.

It wasn't as bad as some state here, but at certain temperatures RRF tried to keep the "wrong temperature". It's within a few degrees up until 215C. At 215C and above it tries to hold ~230C - and that quite for quite some time - before going down to 220C. It seems like it tried to over-compensate at that temperature.

For reference here are my tuning params (Rapido hotend, HF configuration, Gdstime 5015 fan - 12V running @24V @100%):
; Heater model parameters
M307 H0 R0.234 K0.184:0.000 D0.80 E1.00 S1.00 B0
M307 H1 R4.502 K0.516:0.459 D5.09 E1.35 S1.00 B0 V23.9

I'll report back it it looks better on the 3.4 RC2+2, but I highly suspect it might.

[jensus11]

@dc42 Unfortunately I can't test it. I have to wait until gloomyandy releases a new FW.

[ÖrjanE]

@dc42 I just tested 3.4rc2+2 and can confirm that, at least for me, it behaves much better controlling the hotend temperature.

I have a regular E3Dv6 hotend and a Maestro card. With 3.4rc2 it did overcompensate substantially for the fan and did not return to the target temperature after a fan burst. It often remained over 4 degrees above target.

With 3.4rc2+2 it seems to compensate perfectly for varying fan speeds. I had a slight overshoot (ca 1.5 degrees) at initial heatup, and a slight undershoot (ca 1.5 degrees) when the fan first started. For the rest of the print, it stayed within +-0.2 degrees of target. I have not yet done a new PID tuning with the new firmware,

/Ö

[OwenD]

I have just run some tests with 3.4RC2+2
After doing a fresh PID tune I can confirm that the initial overshoot I got with the later beta versions was greatly reduced and the over compensation and over heating when intermittent fan speed changes occurred was likewise not evident.
I got an initial drop in temperature when the fan activated, but over all it is more like what I would expect for my setup.
I was able to provoke a heater excursion fault be using slicer settings that moved fan speeds from 0 - 50% every few seconds, but in fairness I can't think of a real situation where such settings would be used.

[dc42]

@owend thanks for confirming this.

Whether you see an initial temperature rise or drop when the fan turns on depends on the hot end. With a Revo hot end I see a rise initially. I think this is because the thermistor is between the heater and the fan, so it's reading a value somewhere between the heater temperature and the nozzle temperature. With a Hemera hot end the thermistor is the opposite side of the nozzle to the heater, so it follows te nozzle temperature more accurately, and I see a temperature drop.

I'll mark this as solved.

[A Former User]

@dc42 said in Temperatures totally wrong 3.4 RC:

@jensus11 @Hernicz @resam @TheDragonLord I've put 3.4.0rc2+2 binaries at https://www.dropbox.com/sh/amtiizdcylnuaye/AAA4hzXFvU0RMOSDtdT37HFua?dl=0 for testing. These should fix this issue. Although the changes are minor, please test them with care.

it works, thanks!

[jensus11]

Thanks @dc42, the version works as it should. The temperature fluctuations are history.

[bberger]

I agree too. RC2+2 also for me has way more stable temperatures.