Support Forums
Alarm Ack via value change

Hello.
I'd like to ack an alarm tag when an operator selects a reason (in this case, DowntimeCode, for the alarm to be active.

I've been using \AlarmManager\Ack(MyAlarm); as per the documentation to attempt the ack. This is my first crack at using \AlarmManager\ but I hope to use it a lot.

My testing "AckAlm.src" script is as such:

(
 DowntimeCode;         {Selected Reason for Downtime}
 OptAlarm;             {Alarm Tag to be the trigger}
)

AlarmAck [

    If Watch(0, DowntimeCode); 

    [
        \AlarmManager\Ack(OptAlarm);        
        Return(1);  
    ]

]

I can see through the source debugger that once I select a DowntimeCode from a dropdown list that the script does run, but the alarm stays Unack'd.

From my Calc Tag:
Data Type: Analog

Calculation Expression:

\AlmAck([DowntimeCode], [OptAlarm]\Root)

Any suggestions on what I'm missing? I have tried with and without \Root on the expression and a number of variations on the code itself (. and \ notation, \code\AlarmManager...\Root, and such).

Thank you.

Hello. I'd like to ack an alarm tag when an operator selects a reason (in this case, DowntimeCode, for the alarm to be active. I've been using \AlarmManager\Ack(MyAlarm); as per the documentation to attempt the ack. This is my first crack at using \AlarmManager\ but I hope to use it a lot. My testing "AckAlm.src" script is as such: ```` ( DowntimeCode; {Selected Reason for Downtime} OptAlarm; {Alarm Tag to be the trigger} ) AlarmAck [ If Watch(0, DowntimeCode); [ \AlarmManager\Ack(OptAlarm); Return(1); ] ] ```` I can see through the source debugger that once I select a DowntimeCode from a dropdown list that the script does run, but the alarm stays Unack'd. **From my Calc Tag:** Data Type: Analog **Calculation Expression:** ```` \AlmAck([DowntimeCode], [OptAlarm]\Root) ```` Any suggestions on what I'm missing? I have tried with and without \Root on the expression and a number of variations on the code itself (. and \ notation, \code\AlarmManager...\Root, and such). Thank you.

I would consider not doing this and instead set a high tolerance for alarm acknowledge notes, like, 40 characters, and develop a set of 40-character quick notes for acknowledgement notes. It's then easiest for operators to select a drop down quick note instead of writing out 40 characters. It's still possible to abuse, but that's an operational policy thing.

Otherwise, even if you can get this to work correctly with (proper security privileges) you're losing a lot of the functionality of the alarm history (unless you ensure you code writes the proper transaction structure in) and you still have a to develop a method of retrieving your stored reasons.

I would consider not doing this and instead set a high tolerance for alarm acknowledge notes, like, 40 characters, and develop a set of 40-character quick notes for acknowledgement notes. It's then easiest for operators to select a drop down quick note instead of writing out 40 characters. It's still possible to abuse, but that's an operational policy thing. Otherwise, even if you can get this to work correctly with (proper security privileges) you're losing a lot of the functionality of the alarm history (unless you ensure you code writes the proper transaction structure in) and you still have a to develop a method of retrieving your stored reasons.

In my actual system, there is a dropdown list of 14 possible codes to choose from as to why the gas well is missing performance requirements. This data goes into a modified version of the Well Test Widget (if you're familiar with that) and creates a table of all the useful production data, the Downtime Code to explain the variance and has the option to add any notes the operator would like. All I need to do with this chunk of script is to Ack the alarm if the operator actually interacts with and selects a DowntimeCode from the list. Alarm stays active, but it is acknowledged that someone has looked at and explained the problem.

In my actual system, there is a dropdown list of 14 possible codes to choose from as to why the gas well is missing performance requirements. This data goes into a modified version of the Well Test Widget (if you're familiar with that) and creates a table of all the useful production data, the Downtime Code to explain the variance and has the option to add any notes the operator would like. All I need to do with this chunk of script is to Ack the alarm if the operator actually interacts with and selects a DowntimeCode from the list. Alarm stays active, but it is acknowledged that someone has looked at and explained the problem.

You may want to look at the help files for Ack to ensure you are sending the correct information in OptAlarm.

Here are a couple of links you may find helpful:

https://www.vtscada.com/help/Content/Pro_Functions/Ack.htm?Highlight=AlarmSeparatorString

and

https://www.vtscada.com/help/Content/Pro_Functions/LocalScope.htm

Where OptAlarm = LocalScope(\VTSDB, TagName);

You may want to look at the help files for Ack to ensure you are sending the correct information in OptAlarm. Here are a couple of links you may find helpful: https://www.vtscada.com/help/Content/Pro_Functions/Ack.htm?Highlight=AlarmSeparatorString and https://www.vtscada.com/help/Content/Pro_Functions/LocalScope.htm Where OptAlarm = LocalScope(\VTSDB, TagName);

Trihedral Engineering Ltd.

Thanks Dave. I read over every help file I could find about this and couldn't piece it together. I did get a hold of Luc Ouellet yesterday for a quick meeting and we worked it out.

For anyone else looking to leverage this function or feature here are my notes:

The purpose of this was to use the action of selecting a code from the DowntimeCode drop list on the page to ack the alarm state. Operations feels this action is sufficient to say that the Operator has done his due diligence in tending to the issue. Other summary pages will have flashing alarm indicators to determine which wells still require attention. Bonus is that it also saves the operator from having to do the extra step of ack'ing the alarm from an alarm list or alarm page.

My Little Concept Testing Script:

(
    DowntimeCode; 
    IOTagWithAlarm; 
)

[
  AlmTemp; 
]


AlarmAck [                        
  If Watch(0, DowntimeCode); 
    [                        [
    AlmTemp = Concat(IOTagWithAlarm.UniqueID, ":#:HH");
    \AlarmManager\Ack(AlmTemp);        
    ]            
]

I have a IO tag which has a HH alarm set (Tag Name is IOTagWithAlarm).
I have another IO Calc Tag actually calling my script (AlarmAck.src). An analog Calculation with this expression:

\AlarmAck([DowntimeCode],[IOTagWithAlarm]\Root)

For the newer people, the \Root is important because I need the Tag itself, and not just the value.

--

From the Source Debugger, find your script.

Identify the tag/variable that needs the ACK by hovering over it. In this case, AlmTemp was going to be.

62fbad4c0bb5b

The Unique ID is only the section up to the first ":". You'll need to concat the Unique ID with the :#:HH at the end.

Now, when the drop list is used, the script runs and Ack's the HighHigh (HH) alarm on the IOTagWithAlarm tag.

To Ack other alarm states, you can change the end of the string to be:
:#:H
:#:L
:#:LL

I hope this helps others out.
Thanks.

Thanks Dave. I read over every help file I could find about this and couldn't piece it together. I did get a hold of Luc Ouellet yesterday for a quick meeting and we worked it out. For anyone else looking to leverage this function or feature here are my notes: The purpose of this was to use the action of selecting a code from the DowntimeCode drop list on the page to ack the alarm state. Operations feels this action is sufficient to say that the Operator has done his due diligence in tending to the issue. Other summary pages will have flashing alarm indicators to determine which wells still require attention. Bonus is that it also saves the operator from having to do the extra step of ack'ing the alarm from an alarm list or alarm page. My Little Concept Testing Script: ```` ( DowntimeCode; IOTagWithAlarm; ) [ AlmTemp; ] AlarmAck [ If Watch(0, DowntimeCode); [ [ AlmTemp = Concat(IOTagWithAlarm.UniqueID, ":#:HH"); \AlarmManager\Ack(AlmTemp); ] ] ```` I have a IO tag which has a HH alarm set (Tag Name is IOTagWithAlarm). I have another IO Calc Tag actually calling my script (AlarmAck.src). An analog Calculation with this expression: ```` \AlarmAck([DowntimeCode],[IOTagWithAlarm]\Root) ```` For the newer people, the \Root is important because I need the Tag itself, and not just the value. -- From the Source Debugger, find your script. Identify the tag/variable that needs the ACK by hovering over it. In this case, AlmTemp was going to be. ![62fbad4c0bb5b](serve/attachment&path=62fbad4c0bb5b) The Unique ID is only the section up to the first ":". You'll need to concat the Unique ID with the **:#:HH** at the end. Now, when the drop list is used, the script runs and Ack's the HighHigh (HH) alarm on the IOTagWithAlarm tag. To Ack other alarm states, you can change the end of the string to be: **:#:H** **:#:L** **:#:LL** I hope this helps others out. Thanks.
63
4
3
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft