Programmable Relays Solve Complex Applications

By John Grocke, Published Aug 05, 2013, 12:00am EDT (Info+)

Many times integrators are presented with complex applications, such as machine interface, mantraps, lighting control, or complex timing scenarios, that cannot be easily accomplished with standard access control functions or IP camera inputs and outputs. Often these problems are solved with great difficulty, using a box full of "ice cube" relays, timers and counters with a nest of wiring or an expensive and complex programmable logic controller (PLC). A simpler and more economical solution is to use a programmable relay, as pictured below:

What ** * ************ *****?

* ************ ***** ** ** **********, *******, expandable *********** ***** *** **** *** ******* **** relays, ****** *** ******** *** ** well-suited *** ***** ********** ********. **** programmable ***** **** *** ******* *******:

  • * ****** *** * ***** *******
  • *********** ****
  • *****-** ***-**** *****
  • **** *** *** ** **-*** ***** and ********** ****** ******.
  • ** ******** *** ******* *** ********** status *** ***********.
  • ********** **** *** ********** */* ******* for ********* ********.  

******** ** ******** ********* ********** ***-***-***** ************ relays *******'* **********,*******' ****!********'* ***. ************ ***** ******* **** ********* a ***/**** ***** **** **** *** screen, *********** ******** *** *** ***** *** be********* ****** *** ***** $***, ****** **** * ****-********* ******** for ******* ********. ***** ************ ****** *** quite ******* *** **** *** ****** most ******* ******** ** ****** ******** boxes, ** ***** *****:

Programming ********

*** *****'* *** *** ** ********** through ******* **** ** *** *** (which *** ** **********) ** ** an ******** ******* ******** ******* *** RS-232 ** *** *****. *** *********** software ******** **** * ***** ********* of *************** **** ** ******* *********** ****** *********. *** user ****** ***** ******* ****** ** functions **** * ****** ******* ** a ****-**** ***** ****** *** ***** the ****** ** ** ****** * ******** connection. **** *** ****** ** ********, * simulation **** ****** ******* *** ********* the *******'* ************* **-****** ****** *********** it ** *** *****'* ***. ***** ******** of *** *********** ******** *** ********* online **** **** *** *******, *** *************** ****** **********. (****: They ** *** ******* ******* * yet) 

Applications ************

*********'* ******* *********** ********, **** *** * *** ******** of ******* ************ **** **** ************ by ***** ** ********** ************ *****.

*** ***** ******* ** * ****** 3-door ******* **********:

****'* * ******** **** *********** ****** for ************ ******* **** *********** ******** analytics *** ********* **** *** ******* detect ****** ****** * ***** **** before ********** ** *****.

****'* ******* ****** ** *********** * traffic ***** ** * ***-*** ************ at *** ******** ** * ******* garage.

Recommendations & ***********

**** ** ****:

  • ****** **** ** ********* ** *** DC ********, ** **** ** ***** the ****** ******* *** **** ***********. We ********* ***** ***** ** ***** ******. 
  • *** ****** ** *** ************ ***** *** ******* sensitive, ** ******* ******** ** "***" and ****** **** ******* ******* ******** is "**".  * ***** ****** **** be ******** ** ***** *** ***** and ** ******* *** ******* ** switch ******* *** ******'* ******* ****** or ****** ******* ****** *****. ****** that *** ****** ***** ** *** ****** or ****** ******* ***** ** ***** for *** ******** "**" *******.
  • **** ** ******* ** *** **** ***** contacts,**** ** *******. ** ** *** ****** ** generate ** "**" ********* *** * 12VDC ************ *****, * **** ** 12VDC ********* ** ********* ** **** case ** *** ***** ********* ****.
  • **** * ******* ****** ** */* expansion ******* *** ** ********* ** the **** ***** ***, ****** *** at ***** ** ****** *** ** outputs, ********* ** *** ************.
  • **** *** ******* *********** ******** ******** do *** ******* ******* * ***. It **** **** ** ** *** on * ******* * ******* ** with * **** ********. ** ********* IDEC's ******* ******* ** ******* *** have *** ******** * ********.

Comments (15)

This is the aspect of 'security integration' I find most interesting and enjoyable - physically integrating non-security systems to security systems.

Being familiar with the scope of these products opens up a whole layer of applications beyond simple surveillance and access control. Want to turn on and dispense gasoline from a pump with an access badge? Use programmable relay. Want to turn on every perimeter light if a PIR detects motion after dark? ... use relays.

Like the post notes, relays are what make complex applications possible. Great article!

Thanks Brian - I have found dozens of applications for programmable relays through the years. It's a handy and economical tool to for an integrator to have in their basket to tackle the unusual stuff.

Is there a reason to prefer programmable relays to using camera I/O or a separate Ethernet I/O module integrated to the VMS? The side of me that wants everything integrated would tend to prefer all my I/O be in one location, but maybe that's just me?

Ethan - If you can manage the I/O all through one system, obviously that would be preferred method. The programmable relay comes in handy when the VMS or EAC system doesn't have the interface, I/O logic or functionality to achieve the desired results, such as the above examples.

I would offer a few words of caution to the uninitiated:

Until you are confident in your Ladder Logic prowess, I would recommend getting your hands on the simulation software and try programming and testing your solution before making promises to the customer. Seemingly simple situations can get complex fairly rapidly (as you can see from the videos). There are college courses dedicated to this topic, and while you certainly can teach yourself via Google, it is not necessarily a trivial undertaking.

When approaching any life-safety related issues, you are going to want to make doubly sure that you know what you are doing, and that you thouroughly test your solution. As the number of inputs grow, understanding all the different ways/orders/timings in which those inputs may be activated becomes increasingly complex (often exponentially so). Certain situations may be covered by regulation that would proclude you from creating a "home grown" solution, and require the use of approved task-specific controllers (I would have assumed traffic light falls in that category - but maybe not).

Very useful devices these programmable relays are. Not to be confused with a PLC (programmable logic controller) which indeed has a difficult learning curve using ladder logic and/or Boolean algebra.

The relays are much easier to wrap your head around and definitely do have a place in the toolbox. They make it possible to bridge the gap to a hybrid "interconnected system". Not full fledged integration which can cost a whole lot more....and may not be as effective.

They help keep the Rube Goldberg factor at bay. Good article.

I have always understood "Programmable Relays" to mean the cheaper smaller variants of PLC's. Every product I am aware of (be it marketed as PLC or PLR) offers similar functionality to the examples in the video. They offer the basic logic blocks (AND,OR,XOR,NAND, etc) as well as a number of more advanced functions (timers, counters, input debouncers, etc). They tend to offer both "ladder logic" and "functional block" programming interfaces; the only real difference being layout. I prefer Ladder Logic - especially for more complex tasks. It let's you break your program into smaller conceptual chunks. The "functional block" interface is certainly easier to get started with, but understanding ladder logic isn't the issue most will trip up on, but how to build complex solutions from the limitted toolset offered.

My point was that even (or perhaps especially) Integrators with programming chops in higher level languages may be surprised at the difficulty involved. As stated; demo versions of the software are freely available. Play with it before you propose it as a solution. I certainly did not mean to imply that these are inherently a bad idea.

I once spent a week at Allen Bradley, and I have just enough hands-on design experience to conceptualize the 'PLC' vs 'Programmable Relay' question. Just to add to Talmage's great post:

While they may be equivalent at some level, PLCs are built with more finite logic controls than most relays. Contact closure is one thing, but PLCs have very precise timer/wave change functions, and the degree of PID feedback loop/error checking is deeper. The 'logic' element of PLCs are much more filled out, and rule generation can be developed on calculated or derived inputs, not only empirical.

It's true that ladder logic and boolean are staples of both, but there a definitely some machine design applications where something more than switching power is useful.

I thought of a good way to express the above more simply:

  • If you want to control a VFD, use a relay.
  • If you want to build a VFD, use a PLC.

thanks John Grocke, useful info...

Wow, great comments guys!

Yes, there is quite a difference between a PLC and a programmable relay. In the past, anytime I had to do some PLC work (usually at correctional facility or utility plant) I had a subcontractor that did nothing but PLC controls and programming. PLC programming is a whole different level and a specialty onto itself. The hard-core PLC guys look at programmable relays as toys.

James - the traffic light wasn't at a public road intersection, but on a private property used 25 times a day +/-. The intersection already had stop signs, speed bumps, reflective paint stop bars on the pavement. The owner wanted a simple traffic light as an added extra measure of safety, but didn't want the expense of a full traffic light controller. There's no way I would feel comfortable installing this on a public major intersection, traffic light controllers are complicated PLC systems.

With any programming you do, as James mentioned, use he simulator mode and test the heck out of it. Test, re-test and then test some more. Then put it in the field and test the heck out of it again. Revise, lather, and repeat.

The geek label was thrown down so soon? Wow, it wasn't like we were talking about building your own EAC platform with Arduino or something like that. My third day on the job full-time at IPVM and I'm already a geek. Is that a badge of honor or the cone of shame?

I've used the controlbyweb relay device. It allows for an API based (or URL based) programming interface which is very easy to use. It's a very inexpensive device that is programmable via the web OR it can interface directly via standard SCADA protocols to a number of systems (Honeywell, Johnson Controls, Siemens - etc). I have also used the system to interface with cameras (video motion triggers an event - it raises high to low on the device and triggers and alarm and sends a URL command to the unit to activate a strobe or something).

John G.,

LOL - I started an Arduino comment (as an alternative to PLR's) - but decided to wait until the PLC vs PLR debate died down.

I've just had good results using a stand alone web relay that communicates over ethernet. This eliminates the need for a relay board on the PC. It can even run programs locally and affords very good flexibility and access to designers.

Login to read this IPVM report.
Why do I need to log in?
IPVM conducts reporting, tutorials and software funded by subscriber's payments enabling us to offer the most independent, accurate and in-depth information.
Loading Related Reports