Sign in to follow this  
Followers 0
semilogical

CLX Add-on for First Out Annunciator

4 posts in this topic

I have developed a first out annunciator based on the ISA 3A model, it works fine in ladder but the manner in which I wrote it tends to confuse some of my fellow programmers. I use indirect addressing so the basic 8 rungs of programming does not have to be repeated, rather re-referenced as the indirect index is incrimented. My goal is to have a first out annunciator for the control logix platforms, we are moving more towards them as they are SIL 2 rated. In using the CLX we are also trying to move to function block as our main code. Before I go all hog wild writing the program in function block I was wondering if anyone knows of existing add-ons that are available for exchange? I consider re-engineering the wheel to be a great waste of time. Our programs are typically repeatable with the exception of the number of system shutdowns that have to be alarmed in a first out manner. All but the first out annunciator is being transformed from ladder to Function Block, our style is easy and quick with the excepton of the dreded First Out Annunciation. Any help, pointers or pre-developed add-ons that are not copyrighted would be greatly appreciated.

Share this post


Link to post
Share on other sites
AB has quite a bit in their sample code library. They have a whole "library" of process control AOI's in there. Check with your local AB rep as they tend to advertise this thing quite frequently at their shows and such.

Share this post


Link to post
Share on other sites
Greetings semilogical ... what type of input modules are you using for this project? ... if they're not an "isolated" type, you might want to take a look at the following thread before you go too far with this project ... the point is that most PLC "first out" recorders don't work the way you might expect them to ... there are several posts related to this subject in that thread - and a possible solution toward the very end ... secret handshake: it's not the "code" that usually presents the problem - it's the electronics involved with the input module ... http://www.plctalk.net/qanda/showthread.ph...mp;postcount=25 Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
Ron, I read through the thread you referenced. Very interesting as I see these kinds of things come up all the time. Edge-triggered logic that looks for a sequence of events can work fine as long as you make the assumption that the order of events and/or the precise sequence of events is of no consequence. Otherwise, any time that you have the opportunity for events to happen out of order (called a "logic hazard" in boolean logic terminology), the exact scenario you described can and will happen. Wikipedia describes this scenario: http://en.wikipedia.org/wiki/Hazard_%28logic%29 In PC programming terminology it is also called a "race condition"...that whenever the order of events becomes critical and it is possible for events to happen "simultaneously" (which violates Einstein's theory of special relativity and is the programming world's version of the uncertainty principle in physics), eventually the undesirable scenario will happen. That being said frequently with series SAFETY circuits, this is not a problem. With other types of interlocks however, it's a big problem. With safety circuits, the general design theories tend to work based on two different events. Once a hazardous condition is detected, the safety relay trips. It stays tripped until the hazardous condition is corrected, AND an operator manually resets the system, as per NFPA 79 for machinery design among other places where this idea is mentioned. You see the same design repeated over and over such as with the purge timers in burners. For example, current design safety relays frequently have two sets of contacts in series so that in the event that one set fails for whatever reason, the second set can still trigger the relay. They also have a set of auxiliary NC contacts wired in series. Recommended practice is to wire the "RESET" function in the safety circuit in series with those NC contacts. Then if either of the two physical relays is stuck in the closed position, the system can't be reset and put back into the running state. The relay remains in the open state until the reset function triggers to reset the relay back to the closed state. And as usual, the system is wired such that the "safe" state with the safety relay is the de-energized one. If all the inputs are latching, then once the safety relay (master control relay) triggers, the PLC can use the delay of the safety relay itself or an internal timer to wait for the "smoke to clear" before going ahead and checking the inputs. Alternatively, the PLC could be inserted into the "reset" logic sequence and the PLC could read all the inputs when a reset sequence is activated just before the safety relays are all reset. Or if the PLC doesn't do anything which would be considered "edge triggered" and doesn't create any internal state changes that would be noticeable, then this wouldn't be a problem either. An example of where timing is critical is if the faults are being logged. An example of a noncritical circumstance is where the PLC inputs are being used for a simple alarm/fault display (just a word or an indicator, not a logging alarm system like most HMI's have). The best thing to do with these interlock chains by the way is to look at them very carefully and insure that they are easy to troubleshoot, which usually means to avoid non-latching circuits. There is nothing more frustrating than having a chain of a dozen different interlocks, most of which clear and give no indication whatsoever as to what the problem is when the interlock trips out. By the way it really doesn't matter how fast those various microcontroller-based devices are. They have the same problem that PLC's have. A PLC actually is a microcontroller. The only difference is that it has a high level programming language loaded into it which insulates electricians from having to deal with C or assembly language. Traditionally ladder logic languages are operated with interpreters which have been traditionally considered much slower than compilers, which is typically what you'd use on a microcontroller (BASIC Stamps and the various 8052-based BASIC-52 type devices excepted). The speed of the microcontroller however has no impact on the timing on the hardware side. The interpeter/compiler issue is changing even as we speak. The big arguments for using microcontrollers over PLC's are costs, speed, and flexibility to handle algorithms that are difficult to do in ladder logic. That being said, PLC's now come in all shapes, sizes, and prices. They have compilers as well so the speed tradeoff just isn't there. And many have structured text which is effectively Pascal and can handle numerically intensive programming that would be prohibitively difficult in ladder logic. Edited by paulengr

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0