Alarm Code

Thanks for the replies.
I will print this out and TRY to absorb the wealth of knowledge presented.

Alarm code for incinerator system damper actuators.

[attachment]


The first two rungs look to see if a damper has been commanded to move and if it has, after time, looks for the resulting feedback.

The next two rungs checks for the damper indicated in both positions at once.

All alarms latch and must be reset by someone. This is to catch intermittent or bouncing events.

The last rung looks at all the fault bits and if one is set, latches a "catch all" alrm to inhibit things throughout the program.

Use the bit addresses in the panelview to display the alarms. Use an object in the panelview to reset the alarms.

rsdoran said:

[H]ow can they successfully acknowledge an alarm that isnt cleared?

Click to expand...

Simple Example:

Operator presses the E-stop. Alarm message pops up, and the operator presses ACK to remove the alarm popup from the screen.

With the popup gone, he uses the HMI to check this and that, takes a break, cleans up the mess, gets ready to run again.

He presses START, and nothing happens.

IF he were to go to the ALARM SUMMARY screen, he'd see that the E-STOP ALARM is still active. But unless he's well trained, he'll start making guesses as to why the START button doesn't work.

This is the kind of thing that needs to be alarmed. It's what I was saying in talking about phase alarms. If you are going to prevent the system from running, you MUST tell the operator why.

This would be a phase alarm: START_PB + E-STOP = alarm. If there are other interlocks besides the E-STOP, each of those would have a seperate alarm.

It takes time to program all of these, but the benefits are measurably worth the effort ($$$ Lost to Uncertainty >> $$ Time to implement)

---

Norm:

Thanks for pointing out my file structure. I was going to, but, as I said, there was too much information to convey all at once. Not only does it allow for easy Excel autogen (of code and annotation), but also for-next indirect addressing using only one pointer.

Like you, I prefer to have my B files displayed as /Bit, rather than word/bit. I started this method using the classic panelviews, and got to thinking in terms of "ALARM #047", so it make sense to use B210/047. I should have typed the addresses like that in my code, but since I intended to show that I manipulate them on a word level (or rather, a file level using indirect addressing in a SLC or the FAL instruction in a PLC-5), I wrote them that way.

One technique/trick I use to monitor a specific alarm is to use the CDMs (Configurable Data Monitor) in RSLogix. They take indirect addresses. So I find an unused register (N10:21), and build a CDM to look at each alarm bit, like so:

[attachment]


I'm curious about your method. If you latch alarms, when do you unlatch them? On the ACK? But if ACKing them unlatches the alarm, but the alarm condition is still present (like my E-stop example above), doesn't that re-latch them, causing the HMI to re-trigger them? Or maybe only sometimes, depending on HMI scan rate?

Allen, an impressive piece of work.

Ron asked "how can they successfully acknowledge an alarm that isnt cleared?"

My answer is, "They can't". In my systems I latch the alarm bits and if a critical fault hasn't cleared when they hit ACK then the alarm stays latched. Things like high motor temp or loss of lubrication would be critical alarms. For what I call informational or non-critical alarms (controlled variable slghtly out of spec but not dangerous) I may allow the alarm to clear but it will come back after a time delay.

To help maintain sanity and allow for clear thinking I put a separate SILENCE on my systems. That lets the operator kill the horn screaming in his ear but doesn't clear the alarm or the message/visible indication.

The ISA developed standard alarm sequences for annunciators years ago, and the various types they developed are still useful. It covers automatic reset (A), manual reset (M), silencing, and several other functions. I only have it in hard copy, but it must be available on the web someplace.

Operator presses the E-stop. Alarm message pops up, and the operator presses ACK to remove the alarm popup from the screen.

Click to expand...

Precisely why I don't use the "canned" alarm banner. There's no reset--only acknowledge and clear. Neither of these operator inputs cause anything to happen in the processor--like the resetting of latched alarms. (I always latch to catch intermittent faults)

I configure an entire screen for my alarms. The PLC senses when an alarm occurs and commands the pview to the alarm screen. On that screen are individual alarm objects, or multiple grouped alarm lists, depending on the number of alarms and available space--along with a reset object. If the operator hits reset and the alarm condition is still present, the PLC alarm latch will re-trigger and thae alarm indication will not clear--he knows he's still got an alarm. He may only reset from the alarm screen so he immediately knows if the reset was successful, or not.

If he changes screens without resetting, it's his problem. Included in the system is a "go to" alkarm screen object so he can always grt back to the "reset" object.

How do you get the PLC to call up a screen?
Thanks

Go to terminal setup under the "control tags" tab. There will be a screen number tag window. Read the help topic on this tag. Basically, if the PLC writes a number to this tag address (integer), the panelview will go to that screen number. If there is a zero in that PLC address, the screen is released. While the value in the address is NOT zero, none of the "go to screen" objects in the application will operate. The PLC has screen control in this condition. To return control to the application, write a zero the screen tag address.

In my logic, when an alarm occurs, I momentarily (2 or 3 seconds) write the alarm screen # to the address, then, after the time, re-write a zero. This sends it to the alarm screen, then releases the control, and it stays on the alarm screen till the operator re-selects another one.

There is also a status screen tag which reports to the PLC which screen is presently displayed. If you want to get fancy, you could remember the pre-alarm screen and return after reset.

Ron asked "how can they successfully acknowledge an alarm that isnt cleared?"

Click to expand...

I think a lot of the terminology originated with the annunciator panels of bygone days. A typical sequence would be:

1. Alarm condition occurs - audible device sounds & relevant light starts flashing
2. Operator presses 'silence' button to stop the noise
3. Operator takes note of which light is flashing and presses 'acknowledge' button
4. The flashing light changes to steady on. Any subsequent alarm will start the noise again and flash its light
5. In an automatic reset system, the alarm light will go out when the alarm condition is cleared.
6. In a manual reset system, the operator has to press a 'reset' button after clearing the alarm condition to extinguish the light
   [/list=1]
   Note that in the auto reset system, the light can go from flashing to off when acknowledged if the condition is cleared prior.
   
   Some systems had individual acknowledge and/or reset buttons for each alarm or groups of alarms.

Gerry:

Thank you. That's exactly the difference between the two methods, except that instead of lights, its a line of text on the HMI's canned Alarm Summary screen.

Again, it comes back to what I said at the beginning: What do you mean by 'Acknowledge'.

If you insist that the operator can't acknowledge the alarm until the alarm is cleared, then use a system like Tom's or Chris' (chakorules).

If you want the PLC to 'remember' that the alarm has been acknowledge, and to clear it from the list once it's been both cleared and acknowledged, then use my alarm engine.

One note of caution: Not all HMI's allow you to acknowledge an alarm that's already been acknowledge (for example: Panelview). So if you are going to use the former strategy, you have to re-annunciate an active alarm after the HMI sets the acknowledge bit (assuming you are acknowledging individual alarms, and not all alarms with one PB).

---

John Paley:

Your post brings up a very interesting point.

Imagine an output with a single "Output Is Energized" feedback (Motor/Aux contact; or Valve/Open_LS)

There are two ways to program the alarm coil:

METHOD 'A'

  OUTPUT                          TIMER

---| |-----+----------------------(TON)

           |

           |  FEEDBACK   TIMER.DN   ALARM

           +------| |-------| |------( )

 

 

METHOD 'B'

  OUTPUT      FEEDBACK             TIMER

---| |----------| |----+-----------(TON)

                       |

                       | TIMER.DN   ALARM

                       +------| |------( )

`
For 95+% of operating conditions, those where the FEEDBACK will never come on in time, the two rungs behave identically.

The major difference between them is that Rung A will generate an alarm if the FEEDBACK drops out for even a single scan after the timer is done, while Rung B, FEEDBACK must be off for the entire length of the timer to trigger the alarm.

Now consider Ron Beaufort's superb POST on MrPLC.com , regarding the differnces between DC and AC inputs (which I hope he will reproduce on this forum - it should be required reading for ALL PLC programmers, not just AB)

Because the PLC is powered by DC, it can survive minor interruptions in power. DC inputs can too. AC inputs don't.

So if FEEDBACK is an AC input, what Rung A produces is not just a "Failure to Energize" alarm, but also serves as a "Power Lost while OUTPUT was energized" alarm.

Depending on your plant, and the cleanliness/reliability of your power, this can be a good thing, or a bad thing. There's no way to make a generalization, but it's something else to consider.

Allen,

Rung A will generate an alarm if the FEEDBACK drops out for even a single scan after the timer is done

Click to expand...

That's right--we want to give the damper time to move AND THEN make sure it stays put after movement. Notice, too the alarms are latches. If the thing is off long enough to stop the process, I darn sure want to catch it. And I don't want the process to restart until somebody knows why it stopped. (Although most operators can't remember what the darn thing said, anyhow)

Because the PLC is powered by DC, it can survive minor interruptions in power. DC inputs can too. AC inputs don't.

Click to expand...

These alarm circuits are not designed to catch interruptions in power. Sometimes we look at power, but we feed power directly to an input for that, then disable all other "like power" alarms if the power alarm is triggered. Disabling prevents cascading alarms (darn, I've got 13 alarm indications--which one is real??). This "disabling" of alarm rungs is good practice with e-stop type alarms, too.

I've had lots of trouble with e-stop strings with those latching buttons. Some of our OEM's use a N.O. set of contacts on the same button as an indication that the button is pushed. I found out the hard way that just because the N.O. contact isn't made doesn't necessarily mean that the N.C.contact is made! It's easy to monitor the state of all buttons in a N.C. string if you make "home runs" with all the wires.

[attachment}


jjjj

Ladder

[attachment]

Horn Alarm on New Alarm

Can someone show me an example of the ladder logic for two alarms, that would trigger a horn whenever a new alarm occurs based on the discusssion below? Once the horn is silenced, how does it activate on a new alarm.

"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)."

MTPLCUSER said:

Can someone show me an example of the ladder logic for two alarms, that would trigger a horn whenever a new alarm occurs based on the discusssion below? Once the horn is silenced, how does it activate on a new alarm.

"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)."

Click to expand...

Holy thread resurrection batman ! This topic is 16 years old, start a new one if you have a question.

Also as this appears to be a homework question you need to be prepared to do some groundwork before anybody will help.