Alarm Code

mwatkins

Member
Join Date
Jun 2002
Posts
73
I was wondering if I could see some different examples of alarm codes for machine conditions (ex. high temp, incorrect position,excess cycle time, ect.) used with a alarm silence, and a reset button.
And using it with a Panelview Alarm Screen.
Thanks
 
Good Question

I am also interested in this subject. I (we) are embarking on a PV 550 to PLC 5 setup, multiple scrolled messages, plus timed and on demand reports. Finally alarm logging and display. I just set up the DH+ comms with the sample plc5 DH+ supplied ladder logic to check out the system now it is time to delve into the world of PanelBuilder32 and figure out how it is doing things and then make it do what is needed.
 
Nt exactly what you need, but have a look at the panelbuilder 32 CD.
There is a demo blackjack program written for a PV900 and an SLC.
Regards Alan Case
 
Alarms, an Introduction:

This is going to be a long reply. I can feel it. The first part of the reply is non-Panelview, non-PLC-brand specific (although I'll be using AB addressing conventions).

When dealing with alarms and OITs, there are some very fundamental questions that MUST be answered before you write a single line of code.

If I ever want to "crash" a kickoff meeting with a client, I just ask these questions, and watch the chaos unfold:
  1. What is an "alarm"? Which part or parts of the process should stop when an alarm occurs?
  2. What is your complete alarm list?
  3. What should happen when an alarm gets "Acknowledged"? Should the process resume?
  4. Should the operator have the capability to "Acknowledge" each specific alarm? Can he acknowledge ALL alarms with one button?
  5. What should happen if the operator doesn't acknowledge an alarm?
  6. If the process stops, should the process not be allowed to restart until the alarm is acknowledged, even though the alarm condition has been cleared?
  7. Do you want an alarm beacon and/or horn? Do they activate on all alarms, or just specific ones?
There are no right answers, and no lack of opinions as to how the system should operate. Management likes alarm horns. Usually before startup is over, either the horn is permanently forced off, the wires have been pulled (or cut, or ripped out), or someone has shoved paper into the horn to silence it.

Knowing the answers to these questions is the start to good alarm code.

First, let me say that I program what are generally considered by many PLC programmers to be "large" systems. 200+ I/O, several 1000's of rungs. Hundreds of alarms. So what follows could be considered 'overkill' by some, and is overkill for some applications.
 
Once you know where you are heading, you can start defining your alarms. I usually classify alarms into six groups.

The first group is Discrete Alarms. These are alarms whose condition come solely from the presence (or loss) of a discrete signal. Loss of signal is almost always best, for safety reasons. E-stops, "high" level switches, "Drive Failure" inputs are examples of this type. If my PLC memory permits it, I allocate 1 alarm coil for every discrete input point, even if that DI isn't a discrete alarm. And I'll reserve some coils for future input modules. This allows me to know just where an alarm is going to be, no matter how the system changes over the course of the project, or its life cycle.

In addition to each alarm coil, I also have a corresponding bit for "Alarm Enable" This bit allows me to disable an alarm on the fly. Usually, there is no coil setting the bit, just a value in the data table.

But sometimes I'll program the bit to eliminate "nuisance alarms" when certain conditions are true.

The usual code for Discrete alarms is dirt simple:

HI_LEVEL HI_LEVEL_ALM_ENABLE HI_LEVEL_ALM_COIL
I:3/1 B211:3/1 B210:3/1
-------| |-------------| |-------------------( )


`
To be more efficient, and because, as I said, I've reserved one alarm for EVERY DI, I might do it this way:

Move with Mask All DIs into Alarm Coils. Mask=Alarm Enable Bit
+--------- MVM ---+
-----------------------| Source: I:3.0 |
| Mask: B211:3 |
| Dest: B210:3 |
+-----------------+


`
To be even more efficient, I'll indirect the above, and put it in a For-Next loop (LBL/LMP pair). Usually not, though. It can be tough enough tracking the alarm bit through the word move. Adding indirect means that the maintenance department must KNOW what I'm doing, which means I must know before I write the code that I'll be spending some quality time with them.

=========

The second group of alarms are the Analog Input alarms. These alarms occur when an analog input value crosses the alarm threshold (above or below). For these, I usually allocate four alarm bits per Analog input point: "High-high", "High", "Low", and "Low-Low". Depending on the customer, and the PLC, I might increase the number to six, adding "Out-of-range, High" and "Out-Of-Range, Low" (if those conditions aren't covered by "High-High" and "Low-Low").
In order to prevent "nuisance alarms", I set a deadband for each alarm. Usually it's enough just to have a common deadband for all the alarms associated with a given point, but if need be, I can make each individual alarm have it's unique deadband.

Typical analog alarm logic looks like this (only HIGH and LOW logic shown):

High Level Alarm
TEMP_HI_ALM_ENABLE
B211:10/6 +------------ COMPARE --+ +---------------- COMPARE ------+ T224:6
-------| |---+--| TEMP TEMP_HI_LIMIT |--+--| TEMP TEMP_HI_LIMIT TEMP_DB |---+-----(TON)
| | F31:1 >= F215:6 | | | F31:1 >= F215:6 - F215:9 | |
| +-----------------------+ | +-------------------------------+ |
| | | TEMP_HI_ALM_COIL
| TEMP_HI_ALM_COIL | | T224:6/DN B210:10/6
+----------| |----------------+ +-----| |--------( )

Low Level Alarm
TEMP_LO_ALM_ENABLE
B211:10/7 +------------ COMPARE --+ +---------------- COMPARE ------+ T224:7
-------| |---+--| TEMP TEMP_LO_LIMIT |--+--| TEMP TEMP_LO_LIMIT TEMP_DB |---+-----(TON)
| | F31:1 =< F215:7 | | | F31:1 =< F215:7 + F215:9 | |
| +-----------------------+ | +-------------------------------+ |
| | | TEMP_LO_ALM_COIL
| TEMP_LO_ALM_COIL | | T224:7/DN B210:10/7
+----------| |----------------+ +-----| |--------( )


`
Again, all of the above can be put into a For-Next loop (there's a special trick for timers) and so for a large system will 100 analog input points, with 4 alarms each, the entire analog alarm code consists of 7 lines of code!
For small systems, or where indirect addressing is not allowed, I use Excel to auto-generate the code.

===========

The Third classification of alarms are the Discrete Output alarms. These alarms are triggered when the expected DIRECT feedback from a discrete output doesn't occur within a set period of time. These are your valve and motor faults. I reserve two alarm bits for each DO: "Failed to Start/Open" and "Failed to Stop/Close", again, whether that point will be alarmed or not.

First, some code (for a valve with "Open" and "Closed" limit switches):

XV123_OPEN_ALM_ENABLE
B211:20/12 XV123 XV123_CLOSED T225:12
--------| |-------------| |--+-----| |----+-----+----(TON)
| | |
| XV123_OPEN | | T225:12/DN XV123_OPEN_ALM_COIL
+-----|/|----+ +----| |-------------( )



`
============

The fourth classification of alarms is the Analog Output. These are rarely used, and generally not a good idea. The basic idea behind them is, like Discrete Output alarms, is to verify that the feedback is tracking the output.

The problem is that if the analog output is PID controlled (which it usually is), the output is fluctuating, and so even if you do have feedback on the control valve, you will have response lags and need to include a deadband since the feedback won't match exactly the value of the output. (Note: I'm referring to valve position, not process variable (temperature, pressure, flow rate) when I refer to feedback.

Usually what you are REALLY interested in is whether the valve opens at all, not whether the actual position is within ±10% of the commanded output. A simple check of "If Valve Output > 10% start Timer. On Timer done, if Valve Position < 5%, then Alarm Coil" is sufficient.

=============

The fifth alarm class is what I call Phase Alarms (after the S88 phase model). These are too general to able to provide much specifics on, but the idea is that the phase is attempting to try to control a process variable ("Heat to Temperature X", "Meter in Y gal of water"). When the phase is running, it should be given a certain amount of time, either to accomplish its goal, or to at least affect the system. If the totalized flow doesn't change for 15 seconds, then you should stop the phase. It could be that a manual valve is closed, or that the level sensor which is telling you that there's enough water is broken, or that water is flowing past the flowmeter without turning it, or ???. So you stop the process, and TELL THE OPERATOR WHY you stopped it.

Sample Code:

PHASE03_RUNNING +----- EQU ---+ T227:3
--------| |------+---| PHASE03_PV |-----+-------(TON)
| | LAST_PV | |
| +-------------+ | T227:3/DN PHASE_ALM_COIL
| +-----| |----------( )
|
| +----- MOV ---+
+---------------------| PHASE03_PV |
| LAST_PV |
+-------------+


`
Other alarms might go in this category as well. For example, a Light Curtain DI may not be an alarm by itself, but "Light Curtain" + "Start PB" would be. That alarm might be programmed with the phase alarms, or I might put it in with the DI alarms

==============

The last catagory of alarms are the PLC-specific alarms. These vary with PLC model capabilities. "Low PLC Battery" is the most common. Sometimes you can get the "Out-of-Range" analog input alarms from the PLC (example: AB PLC-5 BTR, words 2 & 3), and not need the extra code in the analog sectoin. I'm not going to go into details here. They could be considered a specialized type of DI alarm.
 
Last edited:
The Alarm Engine

Once the alarms are programmed, you need to know what you are going to do with them. Do they stop the process or not? The usual answer is YES (especially with phase alarms, but also with discrete output alarms).

The trouble is, if the motor output is no longer energized when the "Failed to Start" alarm occurs, the alarm coil will drop out. That reduces the alarms to one-shots (or one-scans). While the PLC can act on them, they are active for too short a period for any HMI to detect and display them. One solution, such as Chakorules posted, is to use latches instead of coils.

This is well enough, but that immediately raises the question "When do you unlatch them?". There are only three ready answers: you either leave a bit that the HMI will read (not necessarily the alarm coil bit) ON for set period of time long enough for the HMI to see it; you have the HMI confirm that it has seen it ("handshake"); or you leave it on until the operator says that HE'S seen it (acknowledge).

The problem with the timer technique is that, no matter how long you leave the bit on, there's always a chance that the communication will be bogged down, or the HMI will be down, and the alarm will be missed.

The problem with handshaking is that most HMIs (or SCADAs) don't do it, or even can't do it (This speaks well toward "roll your own HMIs). Another problem is that if you have more than one HMI on your network,

you'd want all the HMIs to handshake, otherwise your alarm may appear at one station, but not another. But you really only want to set one bit, not one bit per HMI.

Which leaves Acknowledging the alarm. Again, you need to know if the operator is going to acknowledge individual alarms, or all alarms at once, or both. And while some alarms drop out as soon as they occur (motor failures), others do not (high temperature; e-stop). It's nice to be able to continue to show the alarm at the HMI, even after the alarm has been acknowledge, until it's been cleared.

Here is the code I use to accomplish it. Again, it isn't specific to Panelview. I've used the same code on FIX, Wonderware, RSView, Panelview, and several other systems.

Generate a oneshot for the alarm
ALM_COIL ALM_ENABLE ALM_LAST ALM_ONS
B210:0/0 B211:0/0 B212:0/0 B213:0/0
------| |----------| |------+-----|/|--------( )
|
| ALM_LAST
+----------------( )

Alarm oneshot triggers "Unacknowledge alarm" which seals until acknowledged
ALM_ONS ALM_ACK ALM_UNACK
B213:0/0 B221:0/0 B214:0/0
-------| |----+---|/|------------------------( )
|
ALM_UNACK |
-------| |----+

Convert ACKnowledge command (set by HMI) to oneshots.
I.e., HMI sets ACK, PLC clears ACK after one scan.

ALM_ACK ALM_ACK_LAST ALM_ACK
B221:0/0 B222:0/0 B221:0/0
------| |-----+------|/|----------------( )
|
| ALM_ACK_LAST
+-------------------------( )


If an alarm is either active, or unacknowledged, send it to the HMI
ALM_COIL ALM_ENABLE ALM_TO_HMI
B210:0/0 B211:0/0 B220:0/0
-------| |---------| |---------+---------( )
|
ALM_UNACK |
B214:0/0 |
------| |----------------------+


`
Which is OK, but I really don't want 4 rungs per alarm. So the above code is performed on the word level:
Code:
[B]
         ALM_ONS     ALM_COIL    ALM_ENABLE           ALM_LAST
    CPT: B213:0  = (B210:0   AND  B211:0   ) AND (NOT B212:0)

         ALM_COIL  ALM_LAST 
    MOV: B210:0    B212:0
 
 
 
         ALM_UNACK   ALM_ONS    ALM_UNACK        ALM_ACK
    CPT: B214:0   = (B213:0  OR  B214:0) AND (NOT B221:0)
  
 
  
         ALM_ACK     ALM_ACK        ALM_ACK_LAST
    CPT: B221:0  =  (B221:0 AND (NOT B222:0))
 
         ALM_ACK   ALM_ACK_LAST
    MOV  B221:0    B222:0
 
 
 
         ALM_TO_HMI   ALM_COIL     ALM_UNACK
    CPT: B220:0  =    B210:0   OR  B214:0
 
[/B]
`
And, of course, to handle lots of alarms, the above word-based code is put into a For-next loop, so that all my alarm processing is handled at once.

With this base, now it's time to add the bells and whistles (pun intended). Lets say you have an alarm horn, which will blare whenever a new alarm occurs. Well, there is an entire register of "new alarm occur"s conditions, AKA alarm one-shots (B213 in the above example). If the oneshot registers are not equal to zero, there must be a new alarm, which will trigger the horn, which will stay on until "Silenced".

If the horn only is active on select alarms, you can use a masked comparison to filter out which alarms don't count (unless it's easier to just code the ones that do count).

Is there an "ACKNOWLEDGE ALL" PB on the HMI? If so, just fill the ALM_ACK register with '1' (AB Instruction: FLL #B221:0 -1) on a one-shot of the ACK_ALL.

Do you want to hold up the process until the alarm has been acknowledged? Use ALM_UNACK (B214: ).
 
Panelview and Alarms

NOW to the Panelview-specific stuff. I'm going to talk about Panelbuilder32 programmed PVs here, not the classic or enhanced. Some of the stuff applies to all, some doesn't. Caveat emptor - what follows is what I've figured out, or sometimes guessed at. I've been known to be wrong. Posting (honest) wrong answers is a great way to learn, if you've got the stomach for it. I'm willing to take whatever lumps that follow.

I'm not going to cover the material that can be found in the online help, or Panelview manual. I'm going to try to explain what ISN'T in the manual. For those who like to play along, everything I'm about to say is with regards to the Alarm Configuration popup in Panelbuilder32. If you don't have it, most of what I'm going to say won't make any sense (which might be true, even if you DO have it).

There are essentially three ways to trigger an alarm in the Panelview, depending on how you configure the alarm trigger. By "trigger an alarm", I mean setting a bit in the PLC, and having the correct text message show up on the screen.

The third way has the trigger type as "Value". You poke a number that corresponds to the alarm message number for that trigger, into the Trigger Tag. The problem with this method is that, like the above code, you usually set a bit in the PLC to indicate an alarm, not move a value into a register. And if two alarms happen simultaneously, you can loose an alarm, unless you build a FIFO. More trouble than it's worth, IMHO.

The second way has the trigger type as "LSBit" (Least significant bit). Although it triggers an alarm on the high of a bit, it only looks at the first bit it comes to in the bit string (not necessarily a single word - more on that in a bit (no pun intended)).

The first and best, way has the trigger type as "Bit". With this type, you set a bit, and the alarm is triggered. The really nice thing about using this type is that you aren't limited to one trigger per alarm. With a single trigger tag, you can trigger up to 128 alarms (the same applies to LSBit types).

Create a BIT tag, say DI_ALM, with an address of B220:0/0, and use it as a bit type trigger.

Although it looks like this is only capable of looking at a single bit, when you go to the Alarm Messages tab, you can use that trigger with a value of anywhere from 0 to 127. This will monitor bits B220:0/0 to B220:0/127 (=B220:7/15).

Unfortunately, alarm acknowledgment isn't this good. I remember the classic Panelviews having the same three options, and the alarm ack followed the pattern of the alarm trigger. If you had a bit string (128 consecutive bits) for your trigger, the ACK would also be a bit string. Not so with Panelbuilder32.

Your Ack tag must be an integer (or BCD or other whole word). And when the ACK button is pressed when an alarm (#6) is highlighted, instead of setting bit 6, the Panelview writes a '6' in the ACK Tag. All is not lost, you just have to use indirect addressing to point to the individual ALM_ACK bit in the code above: (OTE B221:0/[ACK_TAG]).

I'm not going to go into the other fields on the Alarm Triggers tab ("Handshake", "Remote Ack", and "Remote

Handshake" tags. The "Ack All" box, despite its name, merely contains a number. When the ACK ALL button is pressed, that number gets written to the ACK tag. Putting '128' in there might be a good idea. Or perhaps -1 (I haven't tried it - I don't use it).

My system has two Panelviews, so I want to have an operator acknowledge an alarm at one, and thereby clear the alarm banner on the other. I also am not acknowledging individual alarms, so I just monitor ACK_TAG for a non-zero number (and don't program alarm zero), and acknowledge all the alarms.

I also use the Optional fields on the Setup tab, and have a bit tag PLC_ACK_ALL in the Remote Tags for ACK ALL. I set this bit for 2 seconds whenever I get a non-zero in any of my ACK tags. This causes the alarm banner to close in both panelviews (even if there are multiple alarms). I don't use the Remote ACK ALL Handshake, because both Panelviews are configured with the same application, and therefore either would set the handshake bit.

The Remote Clear All Alarm tag does everything the Remote ACK All tag does, plus it removes alarms from the Alarm History list (an alarm list object with both ACTIVE and INACTIVE Alarm Conditions displayed).

Whew! That's all I've got in me for now. Hopefully this is enough to kick of a good discussion about alarming, and Panelview's methods in them.
 
Too long

It was too much information, too fast.

The problem was, to talk about Panelview alarms (post 10), I had to talk about acknowleding.
To talk about acknowledging (post 9), I had to talk about why you acknowledge, how the alarm code fits in.
To talk about the alarm code (post 8) (which is what the original poster had asked for), I had to talk about the stuff you have to think about before you do alarms (post 7).

That's the ultimate problem with this forum - to get to even the intermediate stuff, you've got to lay down a big foundation.

The other problem, of course, is Phil's 10K limit on posts (that's why I had to break it into 4 chunks).

At least I got it out of my system.
 
Alarms

Panelbuilder-xx will give you a foundation and some basic tools for alarming purposes but I have found that in most cases you will need to customize your alarms to your system/operators. So just take notes of the suggestions you get from this forum and you will come away with a pretty good idea on how to implement. One problem I have ran into more than once is that an operator would AK an alarm and then forget about it. The problem there is that the fault would go unchecked and the alarm would not sound again unless the fault was cleared and then faulted again. So I put certain alarms on a TON (timer)and had them repeat every so often, visual or audible, for as long as the fault remained. In most cases the operator would be in alligators up to his waist with several alarms and would simply forget but with the alarm repeating after being acknowledged would serve as a reminder.

Food for thought
Roger
 
Nothing personal but this kind of stuff confuses me, how can they successfully acknowledge an alarm that isnt cleared? I know this is a variable subject but if you have ANY alarm then shouldnt the alarm conditions be corrected before the acknowledge is accepted?

Just asking.

Ever noticed many things confuse me?
 
PV Alarms

I probably forgot to mention that I was referring to Panelview alarms.

No, you can't have all alarms continue to be audible as long as they exist, most alarm systems have visual and audible, the audible can be silenced by the operator at any time but the visual usually stays until the fault is cleared.(in my experience)

On the standard Panelviews such as 1400e, you can silence the alarm while the fault condition still exists. In programming I basically said set this bit if a fault occurs and keep it set for as long as the fault is present. The only way the alarm would become audible again is for the fault to be cleared and then fault again. You could see the fault on the alarm history/status screen and see that the fault still exists(active) but there will be no audible due to it being silenced by the operator.
Sometimes the operator would have twenty or thirty alarms going off at the same time, mass confusion, and would lose track of some of the alarms that were silenced. Some alarms were not important at the point of disaster but they became very important after the system was stable, and they would be forgotten after the panic was over.

Does this help?
 
Last edited:
Allen: Outstanding My Man beerchug

Ack All:
I usually program the ACK ALL value to be somthing much larger than I would ever possibly use in the given application. Most of my apps have around 100 alarms so I program ack all for 999.

If Ack_val == 999 then I clear all alarm bits.

Address Entry Tip
I've found that, at least for me, using the /Bit (vs. the Word/Bit) method of addressing makes reading the alarm code easier. I also try, not often enough, to auto generate code and comments with Excel and this helps alot becuase you're not constantly resetting things every 16 lines.
AND
Then the bit number matches the Value/Bit column in the Alarm Message list so instead of trying to figure out, "hmmm is B15:3/5 bit 52, 53 or 54?" you just type B15/53 and be done with it.

chakorules: Good show Too!

I also use latches for alarm conditions. I use individual ack's using allens mentioned indirect addressing method and your FLL for the ack_all and startup.

An Alarm related warning
On a recent job I had a PV1000 Keypad only, DH+ Firmware 4.10. Whenver I downloaded an ap that had an alarm message containing an Embeded variable, the whole PV would lock up with some alarm number not found in the documentation or online. A call to tech support wasn't much help in finding out the meaning of the alarm but told me how to dump the PV memory to reset it which, by the way, is wait until startup test 32 finishes and then to hold the lower left and upper right keys, simultaneously until you get back the message on how much memory is free in the unit. Sometimes I had to do this twice to make it work...

Other Tidbits
Illuded to in Allens excellent posts but not specifically mentioned, would be to keep all alarm bits in their own file (or files if you are using enables and such as Allen did)

Look where he says:
Generate a oneshot for the alarm
His alarm coil bits are in file B210
The enables are in file B211
The alm_last's in B212
The alm_one_shots in B213
and the un_acks in B214

To the uninitiated this seems like a lot of extra work
BUT
All the files line up!!!!
This is what allows him to auto generate his code in Excell and be done with his 250 alarms before 1st brake while the rest of us peons are still typing message text in the Alarm list for our 3rd alarm. (hint: you can cut and paste a whole list of alarm text from excel to the alarm list but only if the copy and paste sizes match up exactly)

I'm sure there are many more gems in allens posts for the rest of us to dig up so do like rsdoran and print it out and study ;)
 

Similar Topics

Hello, I am new here and looking for some help with issue we have dealt with. We have a machine that its do testing on heat exchanger units, job...
Replies
2
Views
85
I'm trying to design a custom alarm page as I'm preparing for a project launch. So far I have learnt that I need to use CiCode functions such as...
Replies
6
Views
4,266
I am fairly new to the plc world and I am stuck on writing the proper logic for a particular alarm condition. I am using a photoeye to detect a...
Replies
7
Views
2,235
Hello, I made a change in alarm setup in factory view studio, where I changed a alarm message text. After that I made a run application and...
Replies
0
Views
68
I am trying to enable an external alarm via computer speakers for Factory Talk Network Distributed Edition. I am using Alarm and Events setup. I...
Replies
7
Views
126
Back
Top Bottom