Temp Tuning Madness

  • I'm about to pull my hair out. Love the new Duet WIFI's hardware and web interface, but the temp setup is KILLING me.

    Background: Converting from Smoothieware on SBase ( though also ran true-blue smoothieboard for a while). Switching exactly the same hardware to my Duet WIFI. Everything went fairly smoothly - motion is working, endatops working, probe is working.

    I did read the "avoiding spurious thermal faults" thread and wiki post.

    I've got a B3 Pico hot end, with a 40 watt heater and a completely pedestrian NTK100 thermistor. I've got a standard issue 50mmx15mm blower for part cooling, and a silicon insulating sleeve on my heat block.

    If I run:

    M303 H1 P0.5 S240

    It faults by exceeding. I can raise it to S275 and it will complete successfully. I check the M307 values with M307 H1 and insert them into the config. I reset the system, set temp to e.g. 200C. It climbs, overshoots by a few degrees and drops back. I then kick the fan on 50%, and the temp drops like a stone and faults at 10C below. So I tried the same tuning command (M303 H1 P0.5 S275) with the fan on 100%. It completed with a max temp of ~210. I used those values in config.g, reset, and set the temp to 200C. It overshoots dramatically, just short of 10C, drops back. I kick on the fan at 75%, temp drops like a stone and faults.

    So do I need to go above P0.5? I'm afraid the temp will be ridiculously high if I do that. Or perhaps P0.6 with fans full on?

    I tried transcribing my PID settings from Smoothie (where this hardware worked fine; the PWM was at ~250 when fan was running full tilt boogie, but it didn't drop more than 1C before recovering) - but fault immediately on the "failed to increase the 1.7C/sec predicted". M307 was commented out and replaced with M301 containing the smoothie values for P I and D.

    Open to any suggestions, thanks.

  • administrators

    If the nozzle temperature drops more than 10C when you turn the fan on, you can reduce the sensitivity of the temperature fault detection. See http://reprap.org/wiki/G-code#M570:_Configure_heater_fault_detection. In your case, something like M570 H1 P5 T20 should do, provided the temperature doesn't drop as much as 20C when the fan comes on.

    However, the advice I always give on these occasions is that if the temperature drops by more than 10C when the fan comes on then you are likely to have extrusion problems, and you should fix your print head design so that the print cooling fan cools the print but not the heater block or heat break. If you have an E3D hot end then adding the silicone sock may help - but the sock affects the heater gain, so you will need to run M307 again.

    In a future version of RRF I intent to implement feed-forward control so that the firmware can predict the effect of the fan and increase power in advance.

    You can use your own PID parameters if you wish, but you should still use a M307 command to configure the heater model, so that the heating fault detection knows what is normal. Just put your M301 command after the M307 command so that it overrides the PID parameters computed from M307. Are you really saying that with your own PID parameters, the temperature only drops 1C when you tuirn the fan on? if so, I would be interested to know how your own PID parameters compare with the two sets computed from M307.

    HTH David

  • Thanks, David -

    The important thing here is that the same exact hardware does not have this problem using other firmware. No 10C sag, with Repetier on RAMPS 1.4 (long ago) or with Smoothie on SBase (day before yesterday). I could run at 255C printing PETG with fan at 100%, with no temp drop. I literally just moved the wires over. That's what has me confused and believing there is something about the configuration system here that I don't get.

    EDIT: Sorry, forgot to answer this:

    Are you really saying that with your own PID parameters, the temperature only drops 1C when you tuirn the fan on? if so, I would be interested to know how your own PID parameters compare with the two sets computed from M307.

    I'm saying that some time ago I ran M303 on my smoothie-on-SBase system, followed by M500, and have been using those settings without problems, with the same hardware, fan, hot end, and heater, with no significant temp drop when the fan came on ( <1C ). The fan is ducted but does blow on the bottom 1/3 of the heater block and also on the nozzle, of course.

    The M301 produced by smoothieware's tuning is:

    M301 S0 P26.5370 I1.4191 D124.0605 X255.0000 Y255

    The M307 produced by RRF ( M303 P0.5 S275 with fans on, this time)

    M307 H1 A339.6 C145.8 D17.6

    This overshoots temp by more than 10C, so I don't know what it will do when I kick the fan on 😄



  • administrators

    Hi Steve,

    Thanks for your reply.

    To avoid overshoot during initial heating, you should tune the heater with the fan off.

    Quite frankly, I find it very hard to believe that the temperature drop is only 1C using the exact same hardware with RAMPS or Smoothieboard, unless the firmware you were using before brings the fan up to speed slowly instead of suddenly as RRF does. Your M307 heater parameters indicate that your hot end has a very large dead time (17.6 seconds), so it is impossible for any PID system to respond significantly faster than that. Even with a more typical dead time of around 5 seconds, PID can't react fast enough to the cooling of the heater block suddenly being increased.

    RRF generates two different sets of PID parameters from the heater model given by M307. The first is a conservative set designed to minimise overshoot during initial heating. The second is a more aggressive set designed to react quickly to changes in temperature when the target temperature has already been reached.

    Do you know what the X and Y parameters in Smoothieware's M301 command do? They are not documented at http://reprap.org/wiki/G-code#M301:_Set_PID_parameters.

    I plugged your M307 parameters in and looked at the resulting PID constants:

    M307 H1
    Heater 1 model: gain 339.6, time constant 145.8, dead time 17.6, max PWM 1.00, in use: yes, mode: PID
    Setpoint change: P4.4, I0.03, D53.6
    Load change: P4.4, I0.13, D53.6

    The PID parameters you were using in Smoothieware suggest a much lower dead time. Your M307 value of 17.6 seconds does seem rather high because 5 seconds is more typical for hot ends. What hot end are you using?

    I wonder whether auto tuning has grossly over-estimated the dead time of your hot end. You could try setting the dead time in M307 to 4 or 5 seconds instead of the value reported by auto tuning. That will give you PID parameters closer to the ones you were using in Smoothieware.

    HTH David

  • Hi, David -

    Well, I didn't capture any of the temp graphs because I didn't think I would need 'em 😄

    I tried running it with the fan on to see if that would handle it better; that's what I did with smoothie. It would overshoot by a degree or two and drop back. I'd be fine if I could get to that point.

    I had not physically touched the hot end in some time until today ( I started fighting with this yesterday, so) when I was checking to see if perhaps the thermistor had pulled out of the heater block and was just under the silicon, but it wasn't. I also examined connections to make sure there were no issues.

    I'll try manually adjusting the dead time, thanks! If not, maybe I'll try reducing the max pwm the fan gets to see if I can at least get printing again.

    EDIT; Oh, it's a B3 Pico hot end.

  • Am I understanding "dead time" properly as the interval between the application of a PID power change and the visible result?

  • administrators


    Am I understanding "dead time" properly as the interval between the application of a PID power change and the visible result?

    That's more or less what it means. In practice the temperature starts rising a little before the dead time, but reaches a steady rate of increase a little later than the dead time.


Looks like your connection to Duet3D was lost, please wait while we try to reconnect.