Tag Alarm Aggregation
in progress
D
Deon Korb
Getting a summary of alarms requires computationally expensive polled system.alarm.queryStatus() functions or isAlarmActiveFiltered() expressions.
It is commonly required to have this summary available for summary display purposes, such as any alarm present on a UDT or any alarm in an area (under a starting tag path).
Providing an automatically updated count on a folder level, similar to what is available per tag where alarms are configured, will solve this problem
Log In
P
Paul Griffith
in progress
Alarming "aggregate" properties will be available on folders and UDT instances in 8.3.0.
C
Cory Grube
This would eliminate one of the most cumbersome (and most fragile) parts of my applications.
Some value-adds:
-Only need to aggregate alarms on specific folders/UDTs, or on those that are actively subscribed to (minimizes performance impact).
-Readable qualified tag path property for alarm table filtering (no more manual tag path manipulation)
-Complementary ISA-101/High Performance HMI alarm symbol component that can bind directly to this alarm attribute
n
nick.minchin
Cory Grube: Why cumbersome? there are alternatives to IA providing this at the moment that aren't cumbersome at all. They just take some time to develop, but once developed, are super easy to roll out. For example, GW timer script to read all alarms on period and write stuff into a script library list of dicts variable. Then a UDT with tags to call a script library function to filter the library variable to the location it's instantiated within and then summarise/count the number of alarms. It's then just a matter of adding those UDT instances into the folders that you need an alarm count
n
nick.minchin
a
ash power
Yes Please.
I currently have a rather complex compressor UDT - which has many tags with varying alarms of varying degrees.
At the highest level of abstraction I want to know if my compressor is good or bad (single bool) - so I can take action when required.
At the moment I don't see a way of doing it that isn't maintained list of all my alarms.
Maybe a custom script but it is not my strong point at the moment.
If a UDT could see the presence of an alarm in any of its children that would be great
G
Greg Sachs
ash power I know this is old, but I have done this via expression tag with expression: try(isAlarmActive("[.]/Alarms/*"),0)
Presuming a subfolder of Alarms which contains your fault.
P
Paul Griffith
under review
j
jason.israelsen
Yes, this feature would be nice. I've been interested in something similar.
Note, the related feature request for the following: