Relays and failsafe

[Ageir]

Hi!

I'm working on a greenhouse automation project. I got two water solenoid valves connected to a standard 2xRelay board with optocouplers to control them. I need some help on how to solve it electronically so that the Relays turns off automatically (failsafe) if the python program crashes or the RPi hangs for some reason. The relays are active low and I can turn them on and off with python but if i exit the program with ctrl-c for example the relays are still on.

Is there a way to make a failsafe electronically?

Just running the python program in a bash-script with an extra "turn off" script after the solenoid script is not ideal and might not work all the time. And I'd like to keep using the relays if possible because I like the optocouplers and runring the solenoids on a separate power supply. I got a lot of sensors, both analog and digital that might not work so good with the 3A solenoids turning on and off.

Any ideas?

Thanks in advance!

[PiGraham]

One option it to sue a simple and hopefully reliable timer to drive the relays and send pulses to reset the timer from your code. A 555 timer is one possibility. If your program crashes or there is a fault on the Pi it's more likely the GPIO will be in a fixed state rather than pulsing. The timer will timeout and the relay will turn off. You put the output switching of the pulse in your program loop. Turn on, delay, turn off, do other things, loop.

If you have two valves plumbed in series and drive them with separate circuits it should be quite reliable, taking several faults in different parts to occur at the same time to cause a flood (or waste a lot of water).

It's important to monitor for faults and alert is a fault does occur, otherwise faults can accumulate and just one more failure will let the water out. A Water flow sensors in-line with the valves might be a good option there. Monitor the flow signal from the Pi to check if valves are open. Alternate turning off the valves to check that each valve off when the other is on does stop the water.

[mikronauts]

What you are looking for is a watchdog dimer + safety circuit.

One way of implementing such a circuit (as you are driving the relays high) would be to use a dual input AND gate to drive each relay.

For each relay, one input to its AND gate would be the current Pi GPIO, the other the output from a watchdog circuit.

For the watchdog circuit, use any handy microcontroller, programmed as follows:

- output is normally low, until you get a "keep alive" pulse from the Pi every 10ms - 50ms (you decide the needed interval)
- once you get a keep alive pulse, set the output high (which will allow Pi control of the relays)
- if you do not get another keep-alive pulse in the needed interval, set the output low

This could also be implemented with a shift register, or counter, and a 555 timer.

DO NOT use another Pi for the watchdog controller, you need as simple as possible - an Arduino, AVR or PIC chip, nothing with an operating system.

[Ageir]

Thanks for the tip on watchdog timers. Didn't know the name for it.
I'll try to solve it without an external uP and just use the RPi for now.
Since it's not that time critical I'm sure the RPi wil be fine.
Setting up apscheduler in python will probably work. Setting it to pulse the timer every 0.5 or 1 second.
A 1-2 sec delay for shutting down the solenoids is fine.

While searching for watchdog timers I stumbled on these from Maxim:
https://www.maximintegrated.com/en/prod ... ml/tb_tab0
Edit: Also found these:
http://www.st.com/content/ccc/resource/ ... 176077.pdf

They might be overkill, or what do you think? Instead of the 555.

Not sure which one is appropriate for my use though. Open-Drain or Push-Pull?

From what I understand I need an AND gate as well to connect the Solenoid GPIO pin and the timer. Any suggestions?


And also I'm wondering if one circuit for both is enough, or one for each solenoid.

A lot of questions. Mostly thinking out loud here. If you got any ideas I'd appreciate it

[Burngate]

Keep it simple.

In your first post, you say it's active-low and has an optocoupler. That sounds like a Sainsmart relay board.
So you may be able to use something like this.

watchdog-rel.png (4.45 KiB) Viewed 5896 times

When you drive the GPIO high, the first capacitor discharges so that it has only about 0.7v across it.
Driving it low transfers charge to the second capacitor. If they're the same size, they'll both end up with about 1v across each.
Keep driving the GPIO high then low, and the lower end of the second cap will settle around 2v below the 3v3 rail.

The relay board opto will take that 2v, switching the relay on and also discharging the capacitor.
So you'll have to keep cycling the GPIO to replenish the charge.
Stop cycling the GPIO and the relay will switch off.

You'll have to choose capacitors depending on how often you cycle the GPIO, how much current the opto takes, and what delay you want before it switches off, but my first thought would be about 10μF

[Ageir]

I read the spec sheets for those watchdog circuits and realize that they won't work. They output a square wave with a length that's the same as the timeout. They are for triggering a reset only.

I'll try making a monostable circuit with a 555 timer. Like this: http://www.ohmslawcalculator.com/555-mo ... calculator

And connecting both relays to an AND gate each. Connecting the 555 timer output to both AND gates will shut down both relays if a trigger isn't sent in the selected interval. or won't that work?

Edit: A NAND gate is what I need. Since the 555 goes low on failure. And the relay is active low so it should default be true, unless a trigger is sent and the GPIO and is high, only then should the output to the relay be low.


@mikronauts was talking about connecting a shift register or counter to the 555 as well. For what purpose? Not sure what you mean there.

I'm wondering how to connect the RPi to the monostable circuit. In the diagram in the link above there's a trigger switch, somehow I have to connect it to the RPi. Not really sure how. I can't just connect it to a GPIO. or? Connecting it to an electronic switch triggered by the GPIO maybe? I'm a noob when it comes to these things

[pcmanbob]

Hi Ageir

Another way to make a fail high circuit

With the input configured in this way the 555 is only triggered on a rising edge from the GPIO , so if the GPIO stays on the 555 will still time out. output only goes low when the 555 output is high/triggered. 555 cant be re-triggered until timed out.
with the values shown time out occurs in about 10-15 seconds depending on component tolerance.
Output will always be high unless the 555 has been triggered so even on power up output is high.
values and transistors selected only because they happen to be what was in my odds bin.

you may find you don't need the resistor connected to the output transistor collector but included it just to be sure.

Edit. forgot to mention Vs is 5V.

[Ageir]

Ah, thanks!

555 cant be re-triggered until timed out.

I didn't realize that. Was relying on that you could. Then it won't work as I like.
Any other circuit that lets you re-trigger before time out?

[pcmanbob]

Ah, thanks!

555 cant be re-triggered until timed out.

I didn't realize that. Was relying on that you could. Then it won't work as I like.
Any other circuit that lets you re-trigger before time out?

But if you have re-trigger before time out and your Pi fails with a high on the GPIO output the timer will be re-trigged constantly so defeating the object of the fail safe circuit. The time out function is what is providing the fail safe function.

[PiGraham]

Ah, thanks!

555 cant be re-triggered until timed out.

I didn't realize that. Was relying on that you could. Then it won't work as I like.
Any other circuit that lets you re-trigger before time out?

There are ways to retrigger a 555.e.g. https://m8051.blogspot.co.uk/2013/02/re ... rcuit.html

Search "retriggerable monostable". See LS74HC123

[Ageir]

But if you have re-trigger before time out and your Pi fails with a high on the GPIO output the timer will be re-trigged constantly so defeating the object of the fail safe circuit. The time out function is what is providing the fail safe function.

Ah! I thought it was triggered by raising of fallig edge. Not on constant high.

[Ageir]

Search "retriggerable monostable". See LS74HC123

I got 0 hits searching for LS74HC123, you must have misspelled it.

[pcmanbob]

But if you have re-trigger before time out and your Pi fails with a high on the GPIO output the timer will be re-trigged constantly so defeating the object of the fail safe circuit. The time out function is what is providing the fail safe function.

Ah! I thought it was triggered by raising of fallig edge. Not on constant high.

OK did some more testing using the existing circuit with a diode for retriggering , if you pulse the input at 0.5 sec intervals with an 0.5 sec on pulse you can keep the output active low for as long as you like but if input stops triggering or goes constant high output will time out.

[Burngate]

Search "retriggerable monostable". See LS74HC123

I got 0 hits searching for LS74HC123, you must have misspelled it.

http://www.ti.com/lit/ds/symlink/cd74hc123.pdf

[Ageir]

OK did some more testing using the existing circuit with a diode for retriggering , if you pulse the input at 0.5 sec intervals with an 0.5 sec on pulse you can keep the output active low for as long as you like but if input stops triggering or goes constant high output will time out.

Thanks! Can it be re-triggered before the interval? If it's constant low?

Which program are you using to make the diagram?

[pcmanbob]

OK did some more testing using the existing circuit with a diode for retriggering , if you pulse the input at 0.5 sec intervals with an 0.5 sec on pulse you can keep the output active low for as long as you like but if input stops triggering or goes constant high output will time out.

Thanks! Can it be re-triggered before the interval? If it's constant low?

Which program are you using to make the diagram?

So 3 input options are :-
constant low > output constant high
constant high > output triggers low on rising edge but times out and returns to high
0.5 sec high followed by 0.5 sec low repeating > output triggers low and stays low

I use tiny cad https://sourceforge.net/projects/tinyca ... =directory

[Ageir]

So 3 input options are :-
constant low > output constant high
constant high > output triggers low on rising edge but times out and returns to high
0.5 sec high followed by 0.5 sec low repeating > output triggers low and stays low

Thanks, will try it. Just need to buy the components.

I use tiny cad https://sourceforge.net/projects/tinyca ... =directory

Does it do simulation as well or just for drawing schematics?
I use Linux on my desktop though.

[Ageir]

Search "retriggerable monostable". See LS74HC123

I'll probably try this approach as well as the 555 version suggested.

It has two types, which one is more suitable with the RPi?
Are the GPIOS TTL or CMOS? Or does it matter at all?
I'm guessing the HCT type since it register 2V+ as high and can be connected directly to the GPIO
I'll probably use a MCP23017 (5v) instead of using the RPi GPIOS directly, if that makes any difference. I doubt it.

HC Types

2V to 6V Operation
High Noise Immunity: NIL = 30%, NIH = 30% of VCC at VCC = 5V

HCT Types

4.5V to 5.5V Operation
Direct LSTTL Input Logic Compatibility, VIL = 0.8V (Max), VIH = 2V (Min)
CMOS Input Compatibility, Il 1µA at VOL, VOH

If I understand it right I need a 423 since the 123 will be triggered when the reset pin goes high, ie reboot?.

They are all retriggerable and differ only in that the 123 types can be triggered by a negative to positive reset pulse; whereas the 423 types do not have this feature.

[pcmanbob]

So 3 input options are :-
constant low > output constant high
constant high > output triggers low on rising edge but times out and returns to high
0.5 sec high followed by 0.5 sec low repeating > output triggers low and stays low

Thanks, will try it. Just need to buy the components.

I use tiny cad https://sourceforge.net/projects/tinyca ... =directory

Does it do simulation as well or just for drawing schematics?
I use Linux on my desktop though.

I only use it for drawing schematics I don't think it does simulation . they only list a windows version, but I am sure you can find a Linux program that will do the same.

[pcmanbob]

So 3 input options are :-
constant low > output constant high
constant high > output triggers low on rising edge but times out and returns to high
0.5 sec high followed by 0.5 sec low repeating > output triggers low and stays low

Thanks, will try it. Just need to buy the components.

Been doing some more testing with this circuit, found you can drive it nicely with software PWM. I say software PWM because then if your program crashes or locks up PWM will also fail being software driven.
these were the base settings I used.

Code: Select all

GPIO.setup(18, GPIO.OUT)
circuit = GPIO.PWM(18, 1) # set pwm to 1Hz
to start pwm
circuit.start(50)		  # set duty cycle to 50%
and to stop pwm
circuit.stop()

even when the PWM was messed around with which might happen if you are doing other things like checking a sensor for example I found it still worked even with duty cycles as low as 10% and as high as 75% , even if the duty cycle exceeded these values and caused the circuit to time out once the duty cycle returned to 50% the circuit reactivated and continued working.
So it looks like software PWM is a nice easy way to drive this circuit.

[PiGraham]

Been doing some more testing with this circuit, found you can drive it nicely with software PWM. I say software PWM because then if your program crashes or locks up PWM will also fail being software driven.

That loses a benefit of such a watchdog, which is to monitor your own code. SoftPWM will likely use a separate thread or process, maybe an interrupt service routine, and that may keep running if your own program loop fails. I suggest using explicit on and off commands in your main loop. That way the controlled device will only be on if your main loop is looping and, we presume, in control.

To illustrate, suppose your program has a bug where a function called from the main loop may wait forever for some status that never occurs. Since you don't get back to the main loop the output turns off when the timer times out, but your process still exists and soft PWM probably still runs and would not let the timer time out.

[pcmanbob]

Thanks for the comment PiGraham.

This was Ageir's original request.
"Relays turns off automatically (failsafe) if the python program crashes or the RPi hangs for some reason. The relays are active low and I can turn them on and off with python but if i exit the program with ctrl-c for example the relays are still on."

He made no mention of wanting to monitor his own program loops, but yes explicit on and off commands in your main loop would be beneficial in that case.

I have tried to test the pwm to see if it stops when the program stops, using Ctrl-C to stop the program does indeed cause pwm to stop, also tried making the program crash by having another pin set for pwm and increasing the duty cycle on that pin only until it exceeded 100% , again pwm on pin driving circuit stopped, also tried letting program finish and having no pwm stop lines, and again pwm stopped in this instance in a high state but the circuit still timed out.

so it looks to me that if the program hangs or stops software pwm does to in what ever state it may be in.
if you can suggest how to cause the program to crash in some other way I will try testing it.

[PiGraham]

Thanks for the comment PiGraham.

This was Ageir's original request.
"Relays turns off automatically (failsafe) if the python program crashes or the RPi hangs for some reason. The relays are active low and I can turn them on and off with python but if i exit the program with ctrl-c for example the relays are still on."

He made no mention of wanting to monitor his own program loops, but yes explicit on and off commands in your main loop would be beneficial in that case.

I have tried to test the pwm to see if it stops when the program stops, using Ctrl-C to stop the program does indeed cause pwm to stop, also tried making the program crash by having another pin set for pwm and increasing the duty cycle on that pin only until it exceeded 100% , again pwm on pin driving circuit stopped, also tried letting program finish and having no pwm stop lines, and again pwm stopped in this instance in a high state but the circuit still timed out.

so it looks to me that if the program hangs or stops software pwm does to in what ever state it may be in.
if you can suggest how to cause the program to crash in some other way I will try testing it.

The crucial bit was

if the python program crashes or the RPi hangs for some reason

I read that as any fault in the program of system that causes a loss of active control should result in the output deactivating. A software fault such as getting stuck in an infinite loop waiting for a status that will never occur would be such a case, and soft PWM won't save you there. I suspect that only is the process exits will soft PWM stop which would be consistent with your finding for Ctrl-C. There are countless potential software errors that will not terminate the process but will cease to provide correct control of the output.
Try an infinite while loop.

[pcmanbob]

I already know an infinite loop wont cause the PWM to stop, when I was trying to get the PWM signal to vary I had the Pi doing some silly maths multiplications each multiplication was taking several minute to complete.
I think until we know more about Ageir's actual program and what he wants to protect against, it is pointless doing any more testing or making assumptions about how his program works.
But thanks for your input, I will continue with the support should Ageir come back and ask for more help.

[mikronauts]

I was thinking about using a shift register or counter as follows:

- 555 timer generates pulses for counter,Pi keeps clearing the counter, otherwise final count "disconnects" relay control from the Pi via logic. (active low logic from Pi, NOT overflow OR'd with Pi's output fed to relay, overflow also stops 555 incrementing counter)

- 555 timer clocks shift register, Pi resets it, output used to gate relay driving by Pi (ok, this one is weirder)

@mikronauts was talking about connecting a shift register or counter to the 555 as well. For what purpose? Not sure what you mean there.