Configuring Heater Fault Detection & PS_ON Trip



  • Morning all.

    Unfortunately the gcode wiki is not clear on the configuration of how the duet does the equivalent of M81 or more precisely deactivate PS_ON.

    There is no direct reference to PS_ON on the wiki and the only gcode that appears to control the heater fault behaviour appears to be M143 and M570

    My aim is to ensure PS_ON is dropped as soon as a 'heater fault' is detected by the firmware. This won't disable my fans, the duet, or my stepper motors.

    M143: Maximum heater temperature

    M143 H0 S125 A0 C0   ; Raise a heater fault if heatbed exceeds 125C.
    M143 H1 S265  A0 C0  ; Raise a heater fault if hotend exceeds 265C.
    M143 H0 S5 A0 C1     ; Raise a heater fault if heatbed falls below 5C.
    M143 H1 S5  A0 C1    ; Raise a heater fault if hotend falls below 5C.
    

    It is not clear what "Switch off permanently" in the wiki means. Will this do the same as if I had cycled the heater status to "Off" on the web control? Will it also drop PS_ON, or is that only achieved by a "Heater Fault" state?

    Will exceeding maximum or falling below minimum temps cause the PS_ON to be dropped instantly?

    M570: Configure heater fault detection

    M570 H0 P10 T10 S2 ; Allow a heat bed anomaly to persist for 10 seconds (P10) 
                       ; on the before raising a heater fault. Allow a 10C deviation 
                       ; from set point (T10) After 2 minutes of heater  fault
                       ; cancel the build (S2).
    
    M570 H1 P5 T15 S5  ; Allow a hot end anomaly to persist for 5 seconds (P5 -
                       ; default) on the before raising a heater fault. Allow a 
                       ; 15C deviation from set point (T15 - default) After (S5) 5  
                       ; minutes of heater fault cancel the build.
    

    So with the above will the heater fault drop PS_ON, or only the cancel build?

    Final Questions!

    As a minor curtsy to mechanical relays will the firmware turn the heaters off before calling PS_ON if it detects a fault through one of the methods above? We're not only protecting against MOSFET failures (in which case turning off heaters would do nothing) but also accidental configuration code errors, or a thermistor coming adrift. In these cases disabling current to the heaters will reduce contact ark on opening the relay contacts. In reality this is only likely to delay the PS_ON signal by a tiny fraction of a second, and so cause little additional risk.

    Is there anything else (aside from physical wiring etc!) that effects what drops PS_ON?



  • Maybe final questions was optimistic! 😄

    Are both M143 and M570 still only active during a build process?

    Ideal would be M143 permanently active, M570 while heaters are active, and a new version of M570 that raises a fault if there is a temp change of more than a set rate (ie what could be expected by opening a workshop roller door, or turning on heating in a room) while the heater is idle or off.

    As with everything config options should be available for users to disable the behaviour if they choose to do so, but I think defaults should be full safeties to allow for issues with the SD card preventing the config being read in.


  • administrators

    @DocTrucker said in Configuring Heater Fault Detection & PS_ON Trip:

    It is not clear what "Switch off permanently" in the wiki means. Will this do the same as if I had cycled the heater status to "Off" on the web control?

    I believe so. I'll ask the person who implemented this feature to clarify the wiki.

    Will it also drop PS_ON

    No.

    Will exceeding maximum or falling below minimum temps cause the PS_ON to be dropped instantly?

    No.

    M570: Configure heater fault detection
    M570 H0 P10 T10 S2 ; Allow a heat bed anomaly to persist for 10 seconds (P10)
    ; on the before raising a heater fault. Allow a 10C deviation
    ; from set point (T10) After 2 minutes of heater fault
    ; cancel the build (S2).

    M570 H1 P5 T15 S5 ; Allow a hot end anomaly to persist for 5 seconds (P5 -
    ; default) on the before raising a heater fault. Allow a
    ; 15C deviation from set point (T15 - default) After (S5) 5
    ; minutes of heater fault cancel the build.

    So with the above will the heater fault drop PS_ON, or only the cancel build?

    Only cancel the build. Currently, heater faults do not drop PS_ON. I am looking at making dropping PS_ON an option in M570 or M143, or perhaps making it automatic if the maximum temperature configured by M143 is exceeded by a certain amount.


  • administrators

    PS - in RRF 3.01RC3 you will be able to set up a background task to monitor heater temperatures and turn off PS_ON if limits are exceeded. But I want to provide a more integrated way.



  • So as far as you're concerned regardless of whether the machine is building or not building in RepRapFirmware 1 and 2, PS_ON does until the user triggers M81 manually?! 😮

    I hope I've miss understood you there.

    The Fire Safety wiki gives the impression that is automatic in Hard shut down of heaters section.



  • @dc42 said in Configuring Heater Fault Detection & PS_ON Trip:

    Only cancel the build. Currently, heater faults do not drop PS_ON. I am looking at making dropping PS_ON an option in M570 or M143, or perhaps making it automatic if the maximum temperature configured by M143 is exceeded by a certain amount.

    Does that contradict your release notes for version RRF 1.20?

    @dc42 said in WHATS_NEW.md:

    When a heater fault occurs, the print is now paused and all heaters are turned off except bed and chamber heaters. After a timeout period, the print is cancelled, all remaining heaters are turned off, and the firmware attempts to turn the power off as if M81 had been received.

    If that is so then the cancel build triggers M81 / drops PS_ON? Unless you reverted this behaviour?


  • administrators

    I got that wrong: if the heater fault persists then the firmware does try to turn the PSU off via the PS_ON pin. This only happens if you were printing a file from the SD card when the fault was raised; otherwise the assumption is that you are by the machine and know what is happening.



  • I've amended my heater faults section of configuration file to the following:

    M143 H0 S120 A0 C0    ; Raise a heater fault if heatbed exceeds 120C.
    M143 H1 S260  A0 C0   ; Raise a heater fault if hotend exceeds 260C.
    M143 H0 S5 A0 C1      ; Raise a heater fault if heatbed falls below 5C.
    M143 H1 S5  A0 C1     ; Raise a heater fault if hotend falls below 5C.
    M570 H0 P10 T10 S0    ; Allow a heat bed anomaly to persist for 10 seconds (P10) 
                          ; on the before raising a heater fault. Allow a 10C 
                          ; deviation from set point (T10) After 0 minutes of heater 
                          ; fault cancel the build (S0).
    M570 H1 P10 T15 S0    ; Allow a hot end anomaly to persist for 10 seconds (P10)
                          ; on the before raising a heater fault. Allow a 
                          ; 15C deviation from set point (T15 - default) After 0  
                          ; minutes of heater fault cancel the build (S0).
    

    I can short, or open circuit the thermistor in a build process to simulate a high or low temperature. The expected behaviour of the system would be:

    • Get build running.
    • Open / close circuit thermistor. (Will look into what resistor value to use to give <5C reading rather than dead short)
    • Machine should run on for 10-15 seconds before raising a heater fault.
    • Heater fault should cancel the build instantly and drop M81 (according to release notes for 1.20).

    The issue here is if M143 (min/max temp) catches the error before the M570 (excessive deviation from setpoint) will the M143 heater fault not have a timer on it to cancel the build and drop M81...


  • administrators

    @DocTrucker, are you saying that a heater fault raised by M143 during an SD card print isn't starting the timer, the way that an "excessive deviation" fault does? If so, that's not intended behaviour.

    PS - which version of RRF are you using? I just check the code in RRF 3.01-RC2 provisional, and each of the 4 places where a heater fault is raised also calls the code that starts the timer.



  • Sorry, not being clear. I'm trying to understand the expected behaviour and setting up a test to test the behaviour of the faults so I can see how my machine would handle faults.

    Also realised my school boy error on the thermistor. We're using negative temperature coefficient sensors , and so a short would read high.

    So both M570 and M143 raise faults during a build, and heater faults from either source will cause the cancellation of the build and subsequent PS_ON drop [edit: if they persist longer than the M570 timeout].

    I'll do the test with no filament in the hotend, and I'm tending towards a pair of variable resistors one in series with the thermistor and one in parallel. The series one will be at the zero ohm end of the pot to begin with and the parallel one would need a full resistance of an order or two magnitudes greater than the thermistor. Increasing the series resistor would fake a drop in temperature, and decreasing the parallel resistor would fake an increase in temp.



  • I run first generation Duets (v0.6 & v0.8.5) on the latest 1.26.1.

    I've got a v0.5 D3 that I am collecting required parts for - only waiting for an SD card and finishing the target machine now. I've forked the RRF3 github and look to get that running soon.

    I've also got a XPLD board with a RADDS board to allow me to look at different step sticks, but that's a much later date!



  • M143 C1 - Thermistor has gone open circuit.
    M143 C0 - Thermistor has gone short circuit, heater shorted to ground, or MOSFETs/SSR failed short circuit.
    M570 - Duet has lost control of the heater & defines how long faults persist before build cancel / PS_ON drop.

    So that's three levels of configurable fault detection. Ideally the fault condition would never go past M570, and the few seconds delay prevents electrical noise causing issues. M143 is essentially raising a fault that says it has gone very wrong very quickly.

    There is another trigger of Heater Faults though that is based on the heater auto tune results. If the temperature doesn't raise quick enough then a fault is raised too. I guess real world trigger for this are excessive cooling on the heater block, the heater cartridge has failed, or the heater cartridge (or thermistor) is no longer in contact with the heat block.

    Is there a way to calculate what this trigger rate is based on the auto tune results? Likewise how do calculate how much below the target point the current temp has to be before the heater is jammed on 100% duty?

    Edit: Not looking to completely rely on the Duet for safety, this is just my first line of defence to catch a fault hopefully before it causes a costly failure.



  • Ok, that was a real head scratcher.

    So for my tests I think the safest way to do this is to disconnect the heater cartridge completely and fake the thermistor for five tests. These are as follows:

    1. Standard running. Build should run fine with a temp resistance of 360Ohm. Faking a temp of 210C.
    2. Lower temp deviation. Greater than 487Ohm, less than 243kOhm. Faking a temp lower than 195C.
    3. Upper temp deviation. Less than 271Ohm, more than 162Ohm. Faking a temp greater than 225C.
    4. Min temperature. Greater than 270kOhm. Faking a temp less than 5C.
    5. Max temperature. Less than 148Ohm. Faking a temp greater than 260C.

    This is base on a thermistor set up with "B4725 C7.060000e-8". Standard E3D V6 thermistor.

    As there is a delay in M570 for fault conditions (cover for nosy inputs etc) I'm hoping that a simple array of resistors with switches to enable or disable branches should be adequate.


Log in to reply