Pulsing Relays

[Bruce Cloutier]

When you signal your automation to enable a relay even if you have it set to turn the relay back off after some status change, consider using an extended pulse. This is just insurance against the situation where the relay doesn't actually get commanded to turn off for some reason.

True story: We have JNIORs all over the country monitoring water towers in municipalities. Periodically the water level is reported to a monitoring system. When levels are down the JNIOR is commanded to close a relay engaging pumps that refill the tank. There was a situation where the command to disengage the pumps never came. Now this is just fresh water overflow and outdoors. And, actually this might occur on purpose as some places have a requirement that (say) 20% of the tank contents must be turned over each day. But in this case, well, the home system went through a MS update. It failed to remember that it was pumping.

Now there are a number of solutions that would prevent this from occurring. The application can detect a full tank and shut off the pumps on its own. We are told that it takes about an hour and a half to fill the tank. We've recommended that they pulse the pump relay for an hour or two. At least then the overflow situation won't run on forever (and waste valuable clean water).

So in the cinema, if you are using a relay to run a motor hopefully the motor has a mechanical shutoff at its limits. Still you'll want to insure that the relay is turned off. Maybe pulsing for a time just longer than it takes the motor to go from stop to stop?

I am not sure what analogous situations there might be in the cinema but at least your not going to fill the theater with water (or popcorn or something).

[Carsten Kurz]

Our masking uses position switches on the motor gear. This is old equipment from 1957, but still working. So, normally, it would stop. If it wouldn't, the whole construction would probably come down.
A second measure is a fuse on the motor that I tested to have just the right mA value so that it blows when the motor stalls for a second or two. But that is still not enough - we also use a timeout on the driving pulse - the time it needs for the masking to travel from fully closed to fully open, or the other way round. 12sec.

So far, we were lucky,. I have seen the one or other measure trip/fail, but not all three at the same time.

[Randy Stankey]

Why not automatically default to a failsafe state? That's the way railroad signals work.

If ever power is lost, a lamp fails or some other condition occurs where the status of a signal can't be determined, railroad systems are designed to fail to their "most conservative" state. If a block signal (the signal that instructs a train to continue or stop) fails, the train may not pass that signal and the lights or semaphores must fall to the "stop" indicator. (A dark signal automatically means "stop.") If a route signal (the signal that tells a train whether an upcoming track switch is set to "pass" or "diverge") the system defaults to "pass" or, if the status of the switch can't be determined, it defaults to "stop."

Given this example, it would stand to reason that a JNIOR which is controlling some mission critical aspect of a system would be programmed to default to a "most conservative" position. If a relay is set to "ON," it could drop to "OFF" unless there is another command to override. If there is a relay controlling some piece of equipment that must always be "ON" unless otherwise commanded, the "conservative" position would be reversed.

The JNIOR might be programmed to look for a status signal from its home system and, if that signal isn't received in a certain period of time (seconds or minutes) the JNIOR drops to its failsafe state.

I know that it might be more of a PITA to program, operate or troubleshoot a system that works this way but, in the case of something like a railroad signal, preventing a disaster is more important. In a theater, having emergency exit lights come up in a failsafe condition would be preferable. The same goes for preventing projectors or other equipment from self destructing.

One place I used to work ran an automated assembly line where, if any machine went into an error condition, the entire line would be signaled to stop. In order to restart the line, an operator had to go to the end of the line to check each machine and reset it before continuing upline to check each subsystem before issuing a "restart" command to the main control panel. If any subsystem lost communication with the main control panel, it would issue a "yellow" signal to its "barber pole" indicator and, if a certain amount of time passed and communication was not regained, that machine would go "failsafe" and stop the line.

If such a system were not in place and one machine in the line failed, product could be lost, machines could be damaged or people could get hurt.

Failsafe systems need to be in place to prevent such things which could, well, include catastrophic events or even loss of life.

[Marlon Martins]

This reminded me when i "automated" the lights on our local small cinema. The first time i arrived there, a long time ago, was 2 guys taking care of everything, when was the time to start the movie, he would go upstairs on the projection room, turn off the room lights to start the movie, then when ending, he would run upstairs again to turn on and run back to open the door to let people out.

I pointed this to the owner, saying this was "ridiculous", that can be automated easily, on the cheap. He was a bit skeptical of course, he barely knew me. i put a 4 relay "arduino" board on the server GPO after reading a bit on the pinout, and make the lights turn off/on sequentially (with delays) and automatically of course, adding the macros on the playlist.

During the analysis on "how to do it", was clear the "most conservative" way to do it, was to make the relays be by default "on", and make the projector turn off the lights, instead of making the projector turn on and then turn off. Cause if something fail, the lights are on by default. Then a physical swith on each light on the projection room to be a backup, in case of any problem controlling it

It's working flawlessly for long years. now the cinema is bigger, 2 screens, and a lot of automation, cameras, 4 tv's with raspberry pi showing trailers, etc.

[Bruce Cloutier]

Good points all. Simple pulsing creates the fail safe. They just hadn't covered that in their thinking. We've all been in that situation where once something is working we move onto another priority before we have the chance to run through any 'what if' scenarios. So when an event occurs we hopefully learn from it and make some change to prevent it in the future. Or... which may have happened... you correct the situation and... move on to other priorities.

We have a JNIOR handling real time solar data. The routines involved really should have a watchdog to restart things should something occur. We don't want to lose data. But, we haven't made the change (yet). Actually in that system we've had inverter issues and server issues and the JNIOR just plods on.

I just though I'd toss out the topic to plant it in the back of your minds. Maybe save an uncomfortable situation someplace.

[Frank Cox]

Back in the dark ages I did some plc programming for traffic lights.

Traffic lights have a physical wire from each green that comes back to the control box and a completely separate and independent deadman-type switch that will trip to prevent opposing greens.

[Bruce Cloutier]

There are at least two movies where hackers turn all of the lights green in the city to cause mayhem. Good to know that, well in some places, that isn't possible.

There are just some situations where hardware needs to do the job. Everybody throws microprocessor controls at everything. Um... I shouldn't be complaining.

[Harold Hallikainen]

I think some traffic lights detect an IR strobe or similar to turn lights green for emergency vehicles. I have noticed a white strobe on traffic lights here when an emergency vehicle goes through.

[Frank Cox]

The ones I did weren't that fancy. I did some push-button-for-walk and weight sensors under the road that would stay green until someone drove up on the cross street, but nothing much past that.

A four-way-green would drop out the main controller and start a four-way flashing red until someone came along to open the control box and reset it and (theoretically) find out why it tried a four-way green. As far as I know, in real life a four way green attempt never actually happened anywhere so it never really came up. There was a push-button test switch that would attempt a four-way green during maintenance though.

Police and fire carried a key for the control box that would give you a four way red on demand.

[Bruce Cloutier]

Yeah those traffic systems have gotten fancy/complex in order to keep traffic moving. Multiple intersections are synchronized and the signal can be remotely controlled by people watching cameras. A pretty cool automation application all told. Probably one of the first automated systems for the public.

We get into a lot of interesting applications. We did pass on a bid for traffic controllers at one point. I doubt that I can list all of the cinema tasks that we automate. There are the obvious ones like house lights, curtains (remember those), etc.

[Carsten Kurz]

go on with more cinema tasks!