topic_solved Duet 3 cuts power to RPi4 when SSR is latched via PS_ON pin.
I am trying to solve the problem with my power on/off control circuit but so far nothing. I have this (https://www.amazon.com/gp/product/B07DSXWPC1/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1) SSR that I am trying to use to turn on/off PSU via M80 command. I set the SSR to Active High via jumpers and connected the PS_ON to IN1 and 5V_IN to COM connector (or vice versa, I dont know if matters) . I supplied the power to SSR via a seperate PSU that is not connected to anything else.
The problem is when RPi4 boots up, issues M80 command and latches the SSR, then after a 1-3 seconds later RPi shuts itself down but the SSR keeps latched on and duet3 still powered on with all LEDs are lit. I suspect SSR is drawing too much power from 5V_IN port. I tried other combinations like setting the SSR to Active Low or only plugging PS_ON and leave the COM empty but so far nothing.
Do you think this SSR is not usable with with Duet 3 PS_ON pin? Or can I solve the problem with a 5V 10A PSU to supply the seperate power to RPi4?
A Former User last edited by
Could you include a picture or schematic of how all this is wired?
astrn last edited by
Sorry for the diagram. I am not good at it and draw a very simple one.
You can disregard the timer relay and push button. So basically SSR is working fine and can drive 110v coils on contactor easily. The problem is when I connect the SSR to PS_ON on duet 3 RPI4 shuts itself down when it engages M80. It boots normally until it engages M80 from config.g file. Its not showing on diagram but for testing purposes I also powered the duet 3 via a seperate 24v psu that is not even connected to contactor. The result was same. Rpi4 shuts down itself down after 1-3 seconds later when M80 is initiated and its red power led still on while SSR kept latched on after M80 and duet 3 keep powered normally without any problems even though Rpi lost its power.
To test it, I even disconnected the SSR from contactor connection alltogether, powered the duet 3 with seperate 24v psu that is not connected to contactor and get the power to ssr from another 5v seperate psu that is also not connected to contactor.
The thing is when I replace the ssr with a smaller one it works fine. But the smaller SSR wont be enough for my purposes here.
Ok update. I discovered the problem but not the definitive reason or solution so far. I am using unused 2 gpio pins (one is unused ground and the other is GPIO26 and set to pull_up) that is going to be connected to momentary push button on RPi4 to control a power off script. When its connected it must be drawing too much power since its a fairly long cable. I disconnected that cable to see if there is a problem and viola it solved the issue. Cable itself is not connected anything so far and checked it with multimeter if there is a short but its seems fine. Any thoughts?
Wow I cant even connect a single 24AWG 6inch cable that is literally connected to nothing, not even a ground. RPi lost its power once it triggers M80. When there are no cable present it works just fine. How sensitive are those GPIO pins? I am using RPi3 on my prusa with a fairly long amount cable connected to GPIO and its working fine.
Also I found the real issue here. Somehow when M80 is triggered it interferes with the custom python script I am using to control the power on/off behaviour and initiating it. I simply see no way how it interfaces itself with it. So its not power related but a scripting problem. I am using this script with different GPIO port numbers. https://www.hackster.io/glowascii/raspberry-pi-shutdown-restart-button-d5fd07
Is it possibly a bug present with M80 command and GPIO pins are interfacing somehow?
The most weird thing is it only initiates the script when a cable longer than a inch that is connected no nothing to any unused GPIO pins.
achrn last edited by
I don't know what your contactor is doing. I'd just use the relay to switch the mains - you're using it to switch mains anyway, so it isn't safety issue (I could understand an approach where you decide not to let mains onto a board of questionable standards compliance). The relay is well up to the currents you're using, so why not just use it? (Though this doesn't seem likely to be your problem).
Incidently, it's not an SSR - that means 'solid state relay', i.e. AC-friendly (usually) big transistorish thing. What you have is an actual relay, with coil and flappy contacts. FWIW I don't like putting PSUs on SSRs anyway - I prefer a 'proper' relay.
I note that the relay board says it's opto-isolated, but you are apparently using a configuration that pulls the 'in' input to 5V below common. I would normally interpret active low as being active when in is pulled down to common, and off when it's much above. Without knowing what your relay board contains, it's hard to comment.
You say ignore the timer relay, but your initial comments (it goes off a few seconds later) suggested to me the timer was fighting the control signal and over-riding it. Again, without know what is actually wired up it's hard to tell but I'd take it out of the circuit.
However, your later comments sound more like a GPIO floating and picking up a voltage and it's just a lottery when it hits a switching threshold. Are you really sure you've got a pullup on the GPIO? What if you put an actual external hardware pullup on?
Have you checked nothing else is using the same GPIOs (what GPIOs are you using - I trust they don't clash with what teh Duet is using)?
You could also just switch the relay from the Pi - have a GPIO drive the relay board (if it switches reliably on a 3.3V signal). That would eliminate any concern you have about M80 'interfacing' with GPIO (though that sounds unlikely to me). Obviously you'd then need something different on the Pi switching the power, and you lose the ability to cut power from gcode or have the duet decide to cut its own power.
astrn last edited by
I solved it. It was a simple low voltage/current issue of Rpi. Now I am powering it via seperate PSU rather than with duet 3. It works flawlessly.