ATX PS On Pin: Pulse a Heartbeat Signal for External Watchdog?
-
Most of this makes sense to me, but doesn't the G4 command pause printing until the macro is completed? Do the macros run in parallel with the print? Seems like half of the print time would be waiting for the successive G4 dwell commands.
Maybe I could use two endstop input triggers, one triggered on rising to set M80, one triggered on falling to set M81, and let the RC circuit set the frequency.
-
i have heard so many horror stories about fires etc that i am thinking this kind of tech is past due as an available product. DC42 Dave, any thoughts on that ? Here is a link to a similar thread in the folgertech forum. a user is designing his own fire detection system. Maybe the duet could have another daughter board for something like this or as discussed above, a way to detect failures and kill power. I run a 110 vac bed heater and 12 VDC gaming rated pc power supply which is capable of delivering way more power than the duet board could\should draw. I built in some fuses and over limit protection but many have had much better ideas and implementations than mine so definitely looking to upgrade safety. print volume is 300x30x450mm so 40+ hour prints are not all that uncommon. That is a very long time to baby sit the machine. Still loving my wifi and have even made 2 sales for you guys LOL Thanks again for all you do. I am actively working to pay it forward…
-
I got the heartbeat signal and watchdog relay to work (thanks dc42 Dave for the hints), but I have a problem during execution of Macros.
After a bit of trial and error on a breadboard, I have a solid heartbeat with a 0.9 second period. I used the PS_ON pin wired to the E1_Stop input pin and two triggers. One trigger, firing on a falling edge on E1 endstop input, gives an M81 command to open the ATX PS_ON pin. The other trigger, firing on a rising edge on the E1 endstop input, gives an M80 command to close the ATX PS_ON pin. A simple RC circuit introduces logarithmic delay on changes to the E1_Stop input pin voltage whenever the PS_ON pin is cycled. This removes the need for any G4 pause while printing a g-code file.
However, whenever I run a macro or use the movement buttons on the DWC, the hearbeat freezes and trips my watchdog relay. Is there a workaround other than not running macros? I suppose I could set the watchdog timer delay long enough to ride out any foreseeable macro duration, but I would prefer a quick response time to a freeze-up while printing.
Just curious what is causing the delay in response while running a macro. Is it the call to the triggers? The changes I have made in g-code are minimal, in fact the triggers are one line each: M80 for one trigger, M81 for the other, that's it.
-
I think the problem is that the M81 command waits for all movement to stop before it executes.
Instead of using M80/M81 and the ATX power pin, I suggest you use one of the pins on the expansion header, then you can use M42 commands to set it low and high. See https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins.
-
Looks like these general purpose pins (100-103) behave differently than the PS_ON pin. Does setting one of them to "0" connect the pin to ground internally, setting it to "1" connect it to 3.3V? Are they sinking or sourcing?
-
That's correct. They both source and sink.
-
Sorry, I am having a hard time locating these pins on the Duet WIFI wiring diagram. Maybe I am reading the chart wrong.
Maybe it is just too late and I should get some sleep…
-
Success! After sleeping on it for a while, I figured dc42 Dave must have been referring to the Duet WIFI Logical Pins 60-63. I couldn't get Pin 60 to work, but Pin 61 did the trick (E3_STOP on the expansion header wiring diagram). I substituted the E3_STOP pin for the PS_ON pin in my RC circuit, and revised it somewhat to account for the the pin sourcing 3.3v when pulled up to logic "1". Now macros have no effect on the watchdog timer heartbeat.
Thanks dc42 Dave for the help!
-
i have heard so many horror stories about fires etc that i am thinking this kind of tech is past due as an available product. DC42 Dave, any thoughts on that ? Here is a link to a similar thread in the folgertech forum. a user is designing his own fire detection system. Maybe the duet could have another daughter board for something like this or as discussed above, a way to detect failures and kill power. I run a 110 vac bed heater and 12 VDC gaming rated pc power supply which is capable of delivering way more power than the duet board could\should draw. I built in some fuses and over limit protection but many have had much better ideas and implementations than mine so definitely looking to upgrade safety. print volume is 300x30x450mm so 40+ hour prints are not all that uncommon. That is a very long time to baby sit the machine. Still loving my wifi and have even made 2 sales for you guys LOL Thanks again for all you do. I am actively working to pay it forward…
All you really need is a 5v USB wall charger to power the duet, and an external mosfet board for Psu DC supply. Or use an ssr to control the AC side to the psu. Both can be controlled by the ps on pin. Getting the right functionality for psu off in the event of a heater abnormality I'm not sure about but it can't be that hard to do.
As already mentioned thermal fuse for bed is doable.
-
All you really need is a 5v USB wall charger to power the duet, and an external mosfet board for Psu DC supply. Or use an ssr to control the AC side to the psu. Both can be controlled by the ps on pin. Getting the right functionality for psu off in the event of a heater abnormality I'm not sure about but it can't be that hard to do.
This is all good and well as long as the processor is still capable of controlling the PS_ON pin output. But, the original intent of the this post was to account for the case where the Duet board processor has frozen up and unable to change the state of the PS-ON pin, or take any other action to reduce the risk of a dangerous situation.
-
If I decide to add firmware support for a heartbeat on PS_ON, what frequency would you want, and what duty cycle?
-
JustDave, makes sense and its a novel approach.
-
Frequency of one cycle per second is sufficient, and a duty cycle of 50% is fine.
-
I think the problem is that the M81 command waits for all movement to stop before it executes.
Instead of using M80/M81 and the ATX power pin, I suggest you use one of the pins on the expansion header, then you can use M42 commands to set it low and high. See https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins.
This worked beautifully until I upgraded from 1.18.1 to 1.20RC3, now once again my heartbeat stops until macros such as auto-calibrate and home-all are completed.
-
Is this the reason that my 1.18.1 M42 commands are now waiting for macros to complete before executing?
Version 1.18.2/Bug Fixes…
"M42 gcode commands were not synchronised with movement"If so, is there some other command I can use that will execute during a macro instead of waiting for it to complete?
-
Why not send the M42 command before calling the macro, or at the beginning of the macro?
-
Original intent was a heartbeat of 1 cycle per second to prove the processor was healthy, which worked great in 1.18.1. Now the M42 has to wait for a long move to complete, which can take up to 20 seconds at first layer speeds. I would rather not wait that long to cut power to a non-responsive Duet board.
What about a M400 parameter (S-1?) that forces "do it now" rather than "wait for current moves to finish"?
Or, back to my original request of a heartbeat on the PS_ON pin…
If I decide to add firmware support for a heartbeat on PS_ON, what frequency would you want, and what duty cycle?
-
I figured out a way to get a perfect heartbeat…
M307 H3 A-1 C-1 D-1 ; Disable heater 3 to make it available for Watchdog timer
M42 P3 S0.50 F2 ; Switch I/O pin 8 (HEATER3) on expansion header at 50% PWM at 2 HzWorks great; inspired by this posting: https://www.duet3d.com/forum/thread.php?id=1866#p17119
Gotta love this forum.
-
Ok, but bear in mind that the PWM on that pin is generated by a hardware peripheral inside the MCU, so it's presence doesn't mean that the firmware is still running correctly.
-
At this point, I’ll take what I can get. I appreciate the feedback. Any way I can rescind the “answer” token?
Edit: marked as unsolved
