PS_ON safety question
-
@Hornetrider There are various failure modes that can be detected. The few I have come across:
- Broken sensor or incorrectly configured sensor - as you mentioned in this case it will show at either the maximum or minimum.
- Decoupled sensor - this is when the sensor reads a valid value, but is not behaving in an expected way. There are various stages, though I have seen 3. [1] heatup test -> when you command a heater to start heating, and the associated sensor is not showing an increase within a certain time period, it can be due to a decoupled sensor. [2] heating curve -> I did not know about this until it kicked in on my printer a while back (the sensor channel was failing^). In essence it measures the profile of the heater and if it heats too slowly, it triggers. [3] this last one monitors the temperature, and triggers if the sensor temperature rises or drops out of a specific range from the target.
^ The PT100 daughter board's first channel was failing and reading incorrect temperatures. Basically it would trigger while showing a temperature of only 170C, when I measured it with a k-type probe on my multimeter, I measured 250C+ -> I posted about it in this forum and the developers said that it is a confirmation to them that this protection actually worked.
There may be other failures as well (like detecting a significant rise in temperature while not actively heating), but the developers may have more details.
-
Hello
maybe it would be good to use a thermal fuse
280 grad / 10A
directly on the hotend, this will cut the power to the heater
(you have to crimp the cable)and same on heatbed 4x thermo fuse (4x10A parallel) with 140 grad
so it will cut off power without elektronics -
The last time I had the chance to have a decent stab at an e-stop circuit that drew from industrial best practice I had two loops (grounded by PS_ON) in which items like this could be added. These would break the circuit that sunk current from the coils of a pair of guided contact relays, whose contacts broke the mains supply to a power supply that powered the heaters and steppers, but not the fans. Technically I had some fault shielding issues but overall it was robust, forced a local reset, and allowed basic visual fault checking.
The difficulty with thermal fuses in the hot end is two fold. Firstly manufacturers rarely allow for their mounting resulting in challenges securly mounting. Secondly it limits a machine to high or low melt point processing without changing the fuse, which itself introduces user error. Sure, for a ptfe lined hot end 280C is definitely error, but about ball park for processing of some hot materials. Raise it high enough for them and the margin between the upper process temperatures for the high temp material, and the auto-ignition temp of the lower is reduced.
Thermal fuse on the heatbed is more feasible, how are people generally mounting them?
-
Any way, thermal fuses is drifting off topic here as what this is discussing is the system already capable (at least by physical specification) of detecting sensor issues, the reported temperature exceeding pre-defined min/max values, and an unexpected thermal rise of more than x degrees per unit of time while idle.
Currently the system ignores these errors unless the system is running a job. What this request is about is allowing the facility to turn off input connected to PS_ON in the event of an anomaly whatever the machine is doing.
My preferences would be:
- Default to dropping PS_ON on heater faults whenever they occur.
- Allow configuration file changes to disable (edit: or delay) this behaviour.
- Allow an additional g code file to be fired on error if required by the user.
Reasoning (referring to same numbered items above):
- Default setup should be as safe as possible. If a user attaches a power supply disable signal to PS_ON the natural assumption is this will disable on fault. Otherwise why not just loop PS_ON (from the power supply or relay) to ground? Likewise requiring users to research through the g code guide to find how to run the machine in the safe way seems back to front.
- Naturally some people will want the option to disable it. At least from a liability point of view I'd expect the distributors of this product to be happier knowing that a user has to actively request the system is running in a less safe way rather than default to it. When the user does this they should be aware that the system needs more babying.
- I have no problem with additional code running on fault, but am against only signalling PS_ON in here for three reasons. a) SD cards fail after a good amount of use. We see that on occasion on these forums and I've seen it with other devices too. I don't want the 'make it safe' bit of code in a corrupted bit of the SD card. b) If the system can't read the SD card on start up it would fall back to default (safest one would assume) levels of unexpected thermal rise or sensor fault and still have the capability of avoiding a fire. c) If you really want to specify when the M81 is fired in a sequence of g code you could disable it with the feature in 2 and then trigger it yourself. Better still would be having a time delay in 2 that would mean your M81 in the g code is nearly guaranteed to fire in the event of fault code being run. The system can then fire it off after a time delay to cover the case where the g code locks, or can't be read.
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
It might be nice to expand M570 with an extra option:
"Toggle ps_on in case of heater fault".With the following options:
0: Off
1: Maxtemp only
2: All heater faults (default)This would fulfil the first 2 preferences of DocTrucker (the delay could be implemented using the S parameter). I agree that a g code file would be nice, and that the ps_on should (by default) trigger regardsless of what's in that file.
I don't think there needs to be a distinction in ps_on behavior between idle and printing, if you can turn it off during set-up.Fault detection is already enabled during idle, so I don't think it is that difficult to implement the above. The only thing still missing is the detection of a rising temperature when that shouldn't happen (due to mosfet or 74HCT02 fail), but maxtemp will eventually kick in to prevent serious damage, so this is less important.
BTW, slightly off-topic, but I'll be working on a dedicated safety board to cover any issues that can't be covered by the Duet. It will trip a relay and sound a buzzer on any of these issues:
- Non-responsive Duet (implemented using a watchdog timer, similar to this)
- Smoke detection (using MQ-2)
- Failed hotend cooling fan (by measuring the current)
- Thermistor senses too high temperature (will accomodate multiple thermistors that can be placed in strategic spots, such as near the Duet, the PSU, bed, etc)
I think I should be able to implement this without using a microcontroller, so it shouldn't fail easily. I'll start a new topic when I've made the first prototype (might take a while though).
-
The too high fault current consideration could be considered for the Duet 3, don't some mosfets do current detection and if not could that be added?
I'll share the schematic for the safety circuit I built. Sometime tomorrow.
-
@doctrucker said in PS_ON safety question:
[...] Better still would be having a time delay in 2 that would mean your M81 in the g code is nearly guaranteed to fire in the event of fault code being run. The system can then fire it off after a time delay to cover the case where the g code locks, or can't be read.
To have even more control of what to do in such alarm case, I propose to trigger a macro, and start a timer. In the macro, the user can do what ever he wants, even not turn off the printer. After the timer expires, RRF should drop PS_ON, unless the user as executed a specific G-Code telling to cancel the timer. This way, if the macro can't be read, we shut down the printer.
As the macro may only be partially read, some of the security may fail. So, the G-Code to disable the timer should be called at the end of the macro. This may require to be able to freely adjust the timer delay, depending of what has to be done in the macro...
-
Yes, that is what I was describing - or attempting to. I agree.
Option to cancel M81 is a fair addition as the user could have also overriden the the default action to fire the M81 in any form so this provides another level of inbetween. Could also be simply your marco is BEEP, flash lights, and pause if necessary to get users attention before the default delayed M81 trigger.
-
I think a macro callback + timer with a default behavior we can cancel is something which could be generalized to other things, even not related to safety (M0 M1, for example, for which I don't like the default behavior)... I'll propose that in another thread.
-
Dredging this up as I would also like to see at least an option to include M81 in the event of a heater fault at idle and judging my the other threads I ran across searching many would. I'm one that likes redundancy to my redundancy. I'm running what most would consider overkill with my printer that has a 120V bed. 2 SSR's and a relay activated by PS_ON for the bed, and the hot end heater also through a relay activated by PS_ON.
Edit: Forgot to mention I do also have a one time thermal fuse in the bed heater.
-
@dc42 can you please update on the procress made on the raised safety requests on this thread?
