ATX Power Supply On and Off
-
I am using the option to turn the ATX power supply on and off using the controller. The problem that I run into is that I will try to execute a command and forget to turn on the ATX. I have had it lock up or create heater faults because it isn't able to actually execute the command. I made a tweak that sends the command to turn on the ATX supply if an action is selected that would require it. It would be nice to see this implemented in DWC.
-
I'll look into using the power monitor on the Duet WiFi to refuse the command and return an error message if you try to use a heater when there is no VIN power.
-
Actually, it might be nice to simply turn on the power when it is needed, and turn it off when it isn't. The latter is less helpful, since the motor idling never actually turns them off, but in conjunction with motor "parking" and thermostatically-controlled fans that would save us ever having to manually switch the ATX power. Even just turning it on when needed would be a nice simplification.
Currently I put M80 in my start-of-print G-codes and M81 in my end-of-print G-codes, which mostly handles the problem: I have to manually turn the power on if I want to tinker with the machine (e.g. run probe tests) and I have to manually turn the power off if I cancel a print and then give up (rather than trying again until it succeeds). This is slightly complicated by the fact that I don't ever want to turn the power off when the hot end is too hot, but I have a "cool down and shut off" macro which does an okay job.
I'll also point out that the M122 voltage monitoring is not very helpful, or at least, the "lowest voltage" basically always reads 0, though "current" and "highest" do have meaningful values. It would be good if "lowest voltage" could be "lowest voltage while ATX power is on", though I suppose you'd want to leave it a couple of seconds to stabilize.
-
Maybe instead of using a auto on-off feature, which could imply some safety issues, it would be useful to store an restore the current state of atx.
I also use the M80/M81 command's in my start end custom codes and am quite happy with it, however I also sometimes forget it when priming or adjusting the machine. So e.g. in the bed leveling macro the current state could be stored, atx activated and after command's executed the original state could be restored.
(It would be counterproductive to switch it off if it was on before, but making sure it is on to execute the command's also makes sense) -
Good point regarding the homing routines and such. I'll add M80 commands to mine as turning on twice leaves it on and is more elegant than; "what state is the ATX, if off turn on" and overall it saves the head slap as the duet goes through the motions of moving the steppers and waiting for it to hit a limit with no V_IN present.
Perhaps there should be an option on M80 to hold (with suitable timeout & error) until V_IN is detected?
-
I think I'll edit my end of build g-code to wait until the temperature sensors are reporting a lower than 80°C value before moving onto the M81 to shut off the ATX.
-
Good point regarding the homing routines and such. I'll add M80 commands to mine as turning on twice leaves it on and is more elegant than; "what state is the ATX, if off turn on" and overall it saves the head slap as the duet goes through the motions of moving the steppers and waiting for it to hit a limit with no V_IN present.
Perhaps there should be an option on M80 to hold (with suitable timeout & error) until V_IN is detected?
M80 holds until you send M81.
ATX PSUs have some disadvantages when used to power 3D printers, so they are falling out of favour.
-
Yes I realise you don't need to be forever sending the command to keep the power on, but if you use an atx, or you have setup a relay to kill the power to the heaters using the atx on signal then sending more than one M80 does no harm.
My other comment may have caused the confusion. What I meant was a modifier to the M80 command that made it blocking until v_in was seen but with a timeout so it didn't block indefinitely. A comparison is the modifier on the G1 command that makes it watch the limit switch for that axis.
Edit: thanks for the note on the disadvantages of using ATX power supplies. I didn't spot that bit in the choosing a power supply bit of the Duet wiki. I'll read it again more carefully!
-
Thanks for the clarification. Yes I could make M80 blocking for a while until VIN is satisfactory. However, an alternative is for you to add a G4 dwell command immediately after the M80 command to delay for a short while.
-
The use of G4 is a good idea to let the power levels settle a little.
From what I understand there is a feature in the system to drop the signal to the power supply if there is a heater fault detected. Is that on as default? If so setting the heater bed or cartridge heater to 5-10°C above ambient and a wait for temperature would be another way of achieving this with the current firmware release. I'd shy away from doing this with the hot end as I wouldn't want to unnecessarily age the polymer in the hot end and it's the heater more likely to go badly wrong of there is a failure of some description.
I'm going to start having a read through the firmware source code with a view to better understanding it soon. Small chunks at a time relevant to current issues at the time should help and reduce the quantity of my questions! I appreciate the time you take to respond to these and similar questions that I've posted on Reprap forum (post there when I think the issues may be less specific to the duet), thanks! I'm rarely comfortable working from a crib sheet with little knowledge of how things are working outside of the prescribed path. It makes me a frustrating employee for routine tasks but I'd like to think better for R&D!
-
There is no facility yet to turn off the power supply when a heater fault is detected. It's on the list to add when we have implemented logging, so that the cause of the power going off can be determined subsequently.
-
Just seen this. Really can't get used to the forum needing you to press subscribe again after each new post!
Link to "Control of Actions after Heater Fault" repeat request
I'll reference this thread by web link. In a nut shell for safety sake I think there should be an option to call M81 after heater fault as a higher priority than logging. You've got some really nice features for detecting when the heater is going out of control but the current actions of heater fault offers no protection against failed close circuit mosfet or SSR. Addtional thermal fuses and snap switches are an additional point of failure that would rarely (if ever) be tested.
I'll add any further comments about the M81 action on fault to the "Control of Actions after Heater Fault…" thread.
-
Really can't get used to the forum needing you to press subscribe again after each new post!
Does checking "Automatically subscribe to every thread you comment in" in your user settings not cover that?
-
Mine is ticked.
-
I do not have a PSU that can be switched electronically. Is there an not too difficult relay kind of trick to add this feature to PSU's that don't have it? Seems a meaningful addition to be able to shutdown PSU after say 15 minutes of ending a print, or when the HE reaches < 50C after ending a print.
-
You can use the PS_ON output to control an SSR that is connected in series with the mains input to the PSU.
-
You can use the pin to ground a 5V coil relay that's got 5v on the other side of it. I didn't looking in to it too closely but you could probably pull the 5V from the board to go to the other side of the relay coil. You'll need to add a flywheel / flyback diode to the relay too in order to protect the board.
I use that relay to kill the mains power to the power supply that I'm using to feed V-IN and the heaters.
-
Don't bother using an SSR. They fail closed circuit. Relay + diode much better.
-
Currently I put M80 in my start-of-print G-codes and M81 in my end-of-print G-codes, which mostly handles the problem: I have to manually turn the power on if I want to tinker with the machine (e.g. run probe tests) and I have to manually turn the power off if I cancel a print and then give up (rather than trying again until it succeeds). This is slightly complicated by the fact that I don't ever want to turn the power off when the hot end is too hot, but I have a "cool down and shut off" macro which does an okay job.
I don't use PSon and PSoff currently, but I think I might for safety from now on, probably via a relay.
However I do use it with another printer which runs from an xbox PSU.
In Marlin I get around the hotend cooling problem, by using M109 R40, then M81 in my end gcode, or on Duet you might also put it in your cancel.g. The firmware then waits for hotend temp to drop to below glass transition temp for any material (40, 50 would do but you might get heat creep after power off) before shutting off the power.
Does M109 behave in this way in RRF?
-
Don't bother using an SSR. They fail closed circuit. Relay + diode much better.
They only fail closed circuit if you overload them, and most of them can tolerate very large current surges. A mechanical relay can also fail closed circuit under overload, because the contacts get welded together.
Whatever solution you choose, test it regularly by using it as your standard method of powering the printer off.
