Temperature safety checks
-
RepRapFirmware flags each heater that reports -273C as fault, which you could check if you use DWC. AFAIR PanelDue doesn't display heater states (yet).
If a heater fault is flagged, RRF won't actually turn on the heater and M116 (wait for target temperature) will pass right away because the firmware will think the faulty heater is already its target temperature. That's why you don't see any errors but see the XYZ drives moving once you've started a file print.
-
James,
I think DC42 has recently implemented a lot of safety checks to try and catch if a heater falls out during a print for example, as well as the pre-print temperature rise checks. I can confirm that if you get the wiring wrong and the heater doesn't heat as expected, it will generate a fault condition and you have to turn the machine off and on again before it will allow you to turn that heater on.
When you come to wire it up, here is a little tip that caught me out and I know I'm not the first - E0 is H1 (the bed is H0). I knew this but still managed to wire my hot end heater to the wrong terminals. That's how I can confirm that you'll get the fault condition.
Ian
-
There is a M code (M562 I think) that resets any heater fault so you don't have to turn the Duet of to clear it?
Doug
-
Ok, just seems odd that even if it prevents a heater from heating if it detects that it is bad that it will continue to try and print and possibly grind away at the filament. Shouldn't it maybe pause? Maybe have a definable trigger or something. I am going to try and wire it up this weekend. @deckingman, now sure I follow about the extruder being H1. I am looking at the board layout and I see E0 and E1 then the larger Heated bed connector. I don't see H0 / H1.
-
@deckingman, now sure I follow about the extruder being H1. I am looking at the board layout and I see E0 and E1 then the larger Heated bed connector. I don't see H0 / H1.
Hi James,
It seems I have confused you even more - apologies. You won't see H1 on the board it's just the way that the firmware references heaters. H0 is the bed, H1 is the first hot end (extruder) heater. So you would normally define your first tool (T0) as using H1 and you physically connect the heater to E0 on the board.
HTH
Ian
-
A few notes on posts above.
- as Doug says, you can use M562 H# to clear a fault on heater number #
- PanelDue displays the temperature in white on magenta if the heater is in the fault state
- in the next release I will change it to pause or abandon the print when a heater fault occurs
-
Hi James
As Ian has said all channels on the board start numbering from 0 so when remapping drives (for example to use external drivers):
1st drive = D0 (mapped to X axis by default)
2nd drive = D1 etc1st heater = H0 (bed heater connection)
2nd heater = H1 (1st extruder, E0 connection)
3rd heater = H2 (2nd extruder, E1 connection)When defining a tool the drives ignore the XY and Z axis and start numbering from the extruders :
0= first extruder drive
EtcThe details are in the documentation here
https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#Heater_and_thermistor_section -
Good tip about M562 - thanks guys.
-
Maybe this is paranoia, but if thermal misbehaviour is detected, doesn't it make sense to shut down all heating and movement, and in fact use PS_ON to shut down the whole high-voltage end of things?
I'm thinking of, for example, a situation where a heater MOSFET fails shorted: this shows up as an unexpected rise in temperature on the corresponding thermistor, detectable as a rising temperature in spite of the heater being nominally off, so the firmware knows something is wrong. Setting the PWM to zero won't do anything, since the MOSFET is shorted, but shutting down the 12/24V supply would prevent a fire.
Of course, many people don't use the PS_ON pin - I do mostly because I have an ATX - but a separate 5V supply and a relay seem like a reasonable safety measure.
-
Maybe we could initiate a customized sequence, perhaps like a "fault.g" file that executes when a fault condition is encountered.
-
Smoothieware does an emergency stop on a heating fault, including turning the power off if possible. I'm considering implementing the same in RRF.
I think it would be fairly simple to use the PS_ON output to control a SSR that controls the mains supply to the PSU.
-
Would there be any way to dump info of the current state before shutdown? Maybe XYZ(E) coordinates at the moment of fault, etc.
-
If it helps, Marlin also responds to non-approved thermal behaviour by shutting down everything including the main power. Perhaps it would make sense to have a detailed case-by-case test along the lines of: https://github.com/MarlinFirmware/Marlin/issues/2066 ?
I realize our 3D printers are too wimpy for their motion to be a hazard to life and limb, but it might still make sense to have a Big Red Button that also triggers a fairly thorough shutdown, say if the user notices unintended flames. But that might be best handled with a simple switch on the mains input.
closed Thermistors malfunction tests results #2066
-
Ok, finally have the board connected and the temperature checks seem to work better now. I actually had an open in one of the extruder wires and it did the no rise alarm.
I did notice something with the bed temperature and don't know what it causing it. The gcode sets the bed to 55c then sets the extruder temp but after some time the bed acts like it stops heating. I get no alarms on the paneldue console or through the web console. The Active temperature shows the correct temperature (55) but the bed is showing around 33c and the light on the SSR is not on anymore.
-
What does DWC say the state of the bed is when it stops heating: off, or fault?
