Wonderware alarm acknowledgement question

defcon.klaxon

Lifetime Supporting Member
Join Date
Feb 2015
Location
Far NorCal
Posts
616
Hi guys,

I've recently taken some Wonderware (Archestra/InTouch) training and it really helped to understand how they envision development happens. Unfortunately because there was so much to go through, we couldn't get in depth with some of the topics and one of them was how alarms properly work. We did some labs, but we weren't able to drill down to understand all the facets of the alarm system so I have a few questions I'm hoping you all can help me with.

So let's say my PLC has several digital outputs for alarms...say, for a well pump control, there is motor overload, moisture, and high temp (on if condition is true, off if condition is false). I'd create a tag in InTouch for each alarm and then link them to the PLC data, easy enough. But let's say I want an alarm indicator to turn red and blink when each alarm is active, stop blinking but stay red when acknowledged (but alarm condition is still present), and turn off when alarm condition is not present and any previous alarm has been acknowledged...how would one do that? Because the alarm is discrete, it only has two values, true or false. So how can I tell if the alarm condition is still present, but the alarm has been acknowledged?

This is where the training kind of left off...we used dot fields and alarm groups for the example labs, and for analog values like a tank level, it sort of made sense...for a tank level we used tanklevel.hilimit and tanklevel.lolimit to light up some indicators, but the actual alarm fields are "low" and "high" and there's no "limit" verbiage when actually setting up the alarm so it's kind of confusing where these "magic dot fields" actually came from. My guess is that there are a lot of dot fields that I'm not even aware of, and maybe there's an ack'ed or unack'ed field for alarms? When I've looked around for more info, the sheer volume of InTouch documentation is pretty overwhelming.

Anyway, that's what I'm wrestling with at the moment and if anyone can provide some insight, that'd be greatly appreciated.
 
Yes, individual tags and alarm groups have a .Ack and a .UnAck field.

You may also use Active X scripting to acknowledge alarms in a variety of manners within the distributed alarm display object.
 
Yes, individual tags and alarm groups have a .Ack and a .UnAck field.

You may also use Active X scripting to acknowledge alarms in a variety of manners within the distributed alarm display object.

OK cool, thanks! I did some searching around on Google and was able to find a document with all the dot fields (thanks to your providing the .ack and .unack fields, I knew what to search for), so that will be super helpful.
 
OK cool, thanks! I did some searching around on Google and was able to find a document with all the dot fields (thanks to your providing the .ack and .unack fields, I knew what to search for), so that will be super helpful.


I have found the InTouch help files and manuals to be extremely helpful as well.
 
If you go into the properties of your distributed alarm display/AlarmViewerCtrl, You can set what colors you want it to flash with, and what color you want an active alarm to be when it becomes acknowledged, but still present. If you want it to leave the display only after it has been acknoledged, I believe that it is configured to do this by default. If an alarm returns to its normal state before it is acknowledged, you should recieve a different alarm of the state "UNACK_RTN", or unacknowledged return. This will stay on the display until you acknowledge it. If you want the alarm to clear when it returns to its normal state, in the alarm configuration called "Return Implies Acknowledge", or something to that effect. This will clear the alarm from the display and wont provide a return alarm at all. Sorry if I misunderstood your question or if you had already figured it out!

Good luck,
SandwichMagic
 
Ok, so I have been reading about the dot fields for alarms and I've got things pretty well figured out as far as how alarms show up in the Viewer. Now I'm trying to get a certain functionality to work, and I'm not entirely sure how:

Let's say I have a system of multiple well sites, each with an icon on a map and the icon changes color based on site status:

pump running - icon is green
pump off - icon is grey
unacknowledged alarm - border blinks red and continues to blink as long as alarm is unack'ed, even if alarm condition is no longer present
acknowledged alarm - border is solid red
alarm condition returns to normal - border is solid black

At each site I have a discrete alarm for a well pump; the alarm is "power fail" and it's a TRUE whenever line voltage is lost at the local control panel. So an active, unacknowledged alarm is created; tagname.alarm =1, tagname.ack=0. But before the alarm can be acknowledged, power comes back. So now tagname.alarm =0 and there are no active alarms. Now in the alarm summary, you'll see an alarm with UNACK_RTN as its status, but what if I wanted to keep showing the unack'ed blinking alarm to alert the operator that something went wrong at a well site? Is this typical behavior in SCADA, or have I come up with something non-standard? It seems like there is no built in way for InTouch to show alarm persistence if it's unack'ed and that seems very odd to me. One way to mitigate this would be to have the alarm at the well site's PLC stay on until the alarm was ack'ed, but then I'm sending bits back to each site which eats up tagnames and I wonder if that's not how an experienced programmer would do it.

Sorry if this hypothetical is convoluted, if clarification is needed let me know and I'll do the best I can. I guess the question boils down to, what's the typical way to deal with alarms that are no longer "active" but haven't been ack'ed by the operator?

edit: I'm messing around with the .unack dot field and I think I've gotten the alarm functionality I want but I'd still love to hear what you guys would say about the question and whether or not I'm doing something that is typical in the world of SCADA.
 
Last edited:
I guess the question boils down to, what's the typical way to deal with alarms that are no longer "active" but haven't been ack'ed by the operator?


If it was up to me, I wouldn't incorporate the "unacknowledged" state into the graphics animation at all. I'd also use the "Return Implies Acknowledge" setting in my alarm display.

I understand what you're doing, I've had to do it myself to meet a client's spec, but I don't really see the value in it. If a motor is in an alarm state, then it's in an alarm state. Alarm acknowledgement is for silencing a local annunciator. It doesn't change the alarm state. InTouch can record a text based log file of all alarm activity that will capture all of the various alarm conditions with time stamps, or it can store this data to a database. Therefore, you already have this information available.

I think that displaying the unacknowledged alarm state differently than the acknowledged alarm state in the graphic animation serves no useful purpose, but that's just my opinion. I'm a big fan of the KISS principle by nature.

BTW: When I had to do this, I did it within the PLC logic, but you should be able to do it with scripts. It's been so long ago that I'd have to find a copy of the PLC program to tell you exactly how I did it. ;)
 
If it was up to me, I wouldn't incorporate the "unacknowledged" state into the graphics animation at all. I'd also use the "Return Implies Acknowledge" setting in my alarm display.

I understand what you're doing, I've had to do it myself to meet a client's spec, but I don't really see the value in it. If a motor is in an alarm state, then it's in an alarm state. Alarm acknowledgement is for silencing a local annunciator. It doesn't change the alarm state. InTouch can record a text based log file of all alarm activity that will capture all of the various alarm conditions with time stamps, or it can store this data to a database. Therefore, you already have this information available.

I think that displaying the unacknowledged alarm state differently than the acknowledged alarm state in the graphic animation serves no useful purpose, but that's just my opinion. I'm a big fan of the KISS principle by nature.

BTW: When I had to do this, I did it within the PLC logic, but you should be able to do it with scripts. It's been so long ago that I'd have to find a copy of the PLC program to tell you exactly how I did it. ;)

Thanks for your insight, and I see what you mean. It seems like the client wants the system designed in this way so my hands are kind of tied; it definitely seems to be "the norm" as far as how all the other engineers I work with expect a SCADA system to operate so I just assumed that was standard, but it sounds like others may have different ideas.
 

Similar Topics

I am building a development PC. I've installed service platform and loaded a known working intouch app. On the same PC, I have installed RSLogix...
Replies
2
Views
478
I am building a development PC. I've installed service platform and loaded a known working intouch app. On the same PC, I have installed RSLogix...
Replies
10
Views
1,615
Looking to try and get Alarm and Events data out of a 2012 Wonderware system and send it over MQTT to an MQTT Broker. Basically we have a...
Replies
0
Views
1,016
Hey I was needing help with some alarm scripting in Woderware System Platform. What would be the best way to write a script to auto acknowledge...
Replies
2
Views
2,487
Hello! I am using Wonderware for past six months but still haven't fully cracked it yet! In my current application, on the alarms page I have...
Replies
0
Views
1,190
Back
Top Bottom