Allen Bradley PLC-5 Alarming

I have a system where I am planning to add a significant amount of alarming, and want to do it with a memory efficient method that executes as quickly as possible. I am using an Allen Bradley PLC-5.

The general behavior that I am looking for is to have 3 "levels" for each alarm (based on time). As soon as the alarm conditions are true, an "Error Exists" bit should be energized. At some point in time after that, a "Warning Exists" bit should be energized. At some point in time after that, a "Fault bit" should be set. Both the error and warning bits should clear when the input conditions clear. A fault will require the operator to manually reset the fault bit from the HMI.

The times used for each transition (Error to Warning to Fault) will potentially vary for each specific alarm (depending on severity and/or system response time).

Here is a general template that I came up with, but I can't help thinking that there has got to be a faster, less memory intensive way of getting the same behavior. Any thoughts?

Thanks,

Marc

My thought is that you will have to spend one timer for each alarm because the required timedelay for each can (will) vary.

You can save a little by making your own timer logic and fine tune it to only use exactly the required memory.
You could let it time downwards from the SP to zero (rather than the normal for AB timers upwards from zero to the SP).
Then you could potentialy reduce the memory requirements for each timer from 3 words to 1 word.

JesperMP said:

My thought is that you will have to spend one timer for each alarm because the required timedelay for each can (will) vary.

Click to expand...

That's what I was concluding too.

JesperMP said:

You can save a little by making your own timer logic and fine tune it to only use exactly the required memory.
You could let it time downwards from the SP to zero (rather than the normal for AB timers upwards from zero to the SP).
Then you could potentialy reduce the memory requirements for each timer from 3 words to 1 word.

Click to expand...

Do you mean subtracting last scan time from an integer and doing my compares that way? I took a quick stab at that approach, and came up with logic that used more incremental program words than the data words that I would save by changing timers to integers. Do you have a trick that I am missing? Or did I interpret your recommendation incorrectly?

Thanks for the feedback though!

Marc

it's hard to improve on "simple" ...

Marc,

this may not be exactly what you want to hear ... but in my personal opinion I’d leave it just the way you wrote it in your first post ...

yes, you MIGHT be able to save a word here or there and MAYBE come up with something more “elegant” ... but I doubt VERY seriously that you’ll be able to make it any more “understandable” ...

anyone who’s familiar with ladder logic should be able to instantly tell exactly what your program is designed to do just by looking at the rung you’ve posted ... that’s a SIGNIFICANT advantage when it eventually comes time for someone to actually troubleshoot the system ...

so are you REALLY running out of memory? ... or are you worried about scan times? ... or just looking for something a little more “artistic”? ...

honestly, unless there’s a valid reason to change it, I’d leave it just the way it is ... from the KISS viewpoint, it ain’t likely to get much better than what you’ve already got ...

Very nice. The only change I would suggest is a result of my personal prejudice against things like set/reset and latching. I would change the "Fault Exists" to a normal coil, add a "Fault Exists" holding contact in series with the "Conditions to Generate Alarm" contact, and put a Normally Closed "Alarm Reset" contact ahead of the timer.

It shouldn't create much additional memory required, since you need to unlatch each coil with the reset anyway. Besides, I figure saving ten minutes of debug time is worth a lot more to me than bytes and bytes of memory! My way everything for that alarm is on the one rung, and status is immediately obvious to the most casual observer.

The way I perform warning/fault searches is to create a new binary file (say B15) and during the initial scan Fill B15:0 for 20 or more words with -1

FILL
SOURCE -1
DEST B15:0
LENGTH 20

The first 10 words are fatal alarms, the next 10 are warnings.

I have each fault condition hold one bit [B15:0/0] of the B15 ON if no fault - it drops to 0 if a fault occurs. If the bit drops, it stays off until a reset PB is pushed to stop intermittent faults shutting the macine off then clearing themselves (i.e.- low liquid level that raises when the pump shuts off)

To search simply compate B15:0 to -1, then all is OK there. Compare B15:1 to -1, etc.

Heres a quick sample:

Thanks to everyone for your feedback - I'll probably bite the bullet and leave things pretty much the way my first post shows (though I might incorporate Tom's suggestion).

This particular processor is the supervisory PLC in a 5 PLC network. It is an old ControlNet 1.25 unit that twice "lost it's memory" (without generating an IBD file). I could never find an absolute root cause for the event(s) that wiped processor memory, but in working with Rockwell, the most likely culprits were:

1. Excessive comms noise (I have since cut about 80% of the messaging out by restructuring the system).
2. Excessive processor utilization while on-line editing (I have dropped it from about 92% down to about 65%)
3. Old firmware (which I haven't fixed)

Since processor utilization was suggested as a potential culprit, I am concerned that by adding in all of this new alarming I may become more susceptible to whatever caused the memory loss faults. I just wanted to explore any other ideas that folks had that would give the functionality we want while minimizing memory utilization (I am less worried about scan-time).

Thanks again to all who have posted. If anyone else has other ideas, I'm still open to suggestions.


Marc

just for any beginners out there ...

Marc,

this isn’t meant to start a lengthy debate ... but you mentioned:

... though I might incorporate Tom's suggestion ...

Click to expand...

I assume that you’re talking about using a “seal-in” construction rather than the “latch/unlatch” construction in your original post ...

first of all ... there is absolutely NOTHING “wrong” with Tom’s suggestion ... but using a “seal-in” will result in a slight difference in the program’s operation under certain conditions ... I’m quite sure that you and Tom are both well aware of the differences ... but since many less-experienced readers follow these threads looking for ideas, maybe we need to follow through just for the sake of completeness ...

suppose that we use a “latch” construction to turn on “alarm bit A” ...
suppose that we use a “seal-in” construction to turn on “alarm bit B” ...

so both bits are now turned on signifying an alarm for condition “A” and an alarm for condition “B” ...

now suppose that the power to the PLC fails or is turned off ... OR ... the PLC processor is placed in the Program Mode ... OR ... something causes the PLC processor to fault ...

next suppose that the power to the PLC is turned back on ... OR ... the PLC processor is placed back in the Run Mode ... OR ... the fault is cleared and the PLC processor is restarted ...

question: what are the conditions of the alarm bits now? ...

answer: “alarm bit A” which was “latched on” is still ON ... but ...
“alarm bit B” which was “sealed-in” is now OFF ...

and so to the point ... how do we REALLY WANT the alarm bits to function in a “restart” condition? ...

in MANY cases the “seal-in” approach that Tom suggested would be absolutely perfect ... specifically, if the processor is shut down, for ANY reason, then we might want to “wipe-the-slate-clean” and automatically turn off any previously existing alarms when the processor is eventually restarted ...

in OTHER cases the “latched” approach might be more in order ... specifically, if the processor is shut down, for ANY reason, then we might want to “retain” any previously existing alarms when the processor is eventually restarted ...

finally ... there are perfectly valid reasons to prefer one method over another ... some situations REQUIRE one method ... other situations REQUIRE the other ... the big issue is to understand that there ARE subtle but critical between the two methods ... the important thing is that unless you are aware of the differences, you might not catch a potential problem until one of those tricky “what-if” scenarios pops up AFTER the program has been written, debugged, commissioned and then left alone out in the field ...

For Next loop

I suggest that in order to minimize repetitive programming you use
indirect addressing in each instruction in your example and then
put these alarm rungs in a For Next Loop. An index value will be your indirect address reference.

Ron,

Absolutely right. For folks who want to see the implications of the difference Ron refers to, you should look here for another of Ron's posts.

In my case, I am explicitly resetting all of the "latched" faults on "first scan", so there is no significant difference in behavior for the two constructions.

Marc

Re: For Next loop

Jiri Toman said:

I suggest that in order to minimize repetitive programming you use
indirect addressing in each instruction in your example and then
put these alarm rungs in a For Next Loop. An index value will be your indirect address reference.

Click to expand...

Jiri,

One thing that I was considering was to break my construction slightly, and have the TON occur as the only output of the "error" rung. Then, I would use a For-Next loop or something similar to loop through the evaluations of which bits (Error/Warning/Fault) to OTE or OTL. I'm debating the implications of readability (see Ron's first post) versus memory utilization (see my third post).

Thanks for the input.

Marc

Yes, I agree, if you use For Next loop the readability of your program
might be an issue. This is particularly an issue if you have
someone of lesser skill in plant trying to troubleshoot by using your ladder logic and all he sees is one timer that does not really change.
You need to weigh the pros and cons. I have had apps where I started out thinking that all logic should be long handed instead of looping and half way through the sheer amount of rungs required forced me to
change it.
The other problem is that if you don't loop then each little change to your logic will require that you do it in all those repetitive rungs. OEM's on the other hand should use the looping for two reasons.
1. The speed of design and changes as stated above
2. The code is less readable thereby forcing the customer to come back to them.

Good luck

Jiri's idea is a good one if you want compact code. It does have the down side of being almost impossible to debug in a crunch, however.

How about creaating classes of alarms based on what time delay you think each ought to have, then grouping all alarms with the same time delay together in a bit file. Then you can use an FBC to compare the alarm words of each class against a "zero" file. Any alarm turned on will cause the .FD bit to go high, which you can then use to drive that class's timer. Once the timer times out, you annunciate the alarm. QED

AB Timer presets

One thing I do as a matter of design policy is not hard code a timer preset value, I always use a move instruction to load the timer preset from an integer word. This allows for easier changes in preset values and also allows the use of one timer for different functions. It also means that a series of timers that use the same preset can be set by changing one integer value.

Before all you Siemens and Mitsubishi programmers jump in, I do know you can reference an integer word directly in those PLC timers.

John,

I frequently (though not always) do the same thing with timer presets. I think it is good practice to avoid hard-coding of "parameters" whenever possible. The other thing I sometimes do is put the timer presets on a "Maintenance" page on the HMI, allowing system configuration changes without going on line.



Jeffersonian,

That is an interesting idea, but I don't think that I can do it this time. I need the alarms to trigger individually. If I used one timer for any of errors of a given class, then a second error in the same class will trigger a fault early.

Have I misunderstood what you propose?



As far as debug of looped code, if I do what I proposed in my reply to Jiri and change to use the Timer EN bit as the "Error" bit (rather than the separate bit that I have shown in my first post), then I think that might be a reasonable compromise. I'll have to look at whether the memory savings here outweigh the "readability" losses.

Thanks again to everyone for replying!

Marc