Hi all, I’ve recently had the time to identify a good baseline setup for the perspective alarm status table. The table provides some great functionality which requires particular setup, while some default behavior is ‘quirky’ and requires specific workarounds to implement certain functionality.
The purpose of this post is to consolidate all the information in one place and provide a guide which others can follow if they’re simply looking for a high quality baseline configuration.
The format implemented in this guide creates a table which looks like this:
Scope
- Templating
- Tag UDT setup (for Display Path and Label fields)
- Columns
- Formatting linked to styles
- Ordering
- Column widths
- Filtering
Templating
Create a view and instantiate an alarm status table. This table will be configured with all desired properties so that the view can be used as a template and instantiated on multiple screens, with one centrally defined configuration and centrally defined formatting.
Tag UDT Setup
Best use of the alarms table requires specific setup in your device type UDTs.
DisplayPath
If the DisplayPath alarm property is not configured, the DisplayPath column will show the whole path of the alarm including the tag folder structure, tag name and alarm name. Generally speaking this is pretty good but sometimes can be too long.
If you’d like to show only some subtext of the alarm’s path syntax like the below can be used on the UDT’s alarm’s Display Path:
split({PathToParentFolder},"/")[1,0] + " / " + {RootInstanceName} + " / " + {InstanceName}
Spaces before and after the slash can help visually distinguish the sections of the path.
Label
If the Label alarm property is not configured, the Label column will show the name of the alarm. The name of the first alarm configured on a tag defaults to “Alarm”, so this is typically not very useful. It is often better to use this field to provide some plain English description of what the tag and/or alarm is, often taken from an instrument list or IO list.
Configure the device type's UDT to have a parameter called Description (string type), and bind the alarm’s Label property to the Description parameter. When tags are created, fill in their Description parameter.
Columns
Click play, click the settings cog wheel, and select the following columns: Active Time, Display Path, Is Acked, Is Active, Label, Priority and State.
Creating the Styles
To allow the formatting of all alarm tables to be centrally administrated, create a style for each combination of priority, active/cleared and Unacked / Acked.
In each of these styles, define text color, text font-weight, and background background-color.
Background Colors
My recommendation for background colors is:
- Critical: Fuchsia
- High: Red
- Medium: Orange
- Low: Yellow
- Diagnostic: Blue
The idea here is that high, medium and low priorities should be encountered on a regular basis, but critical priority alarms should occur very rarely or never. Red/orange/yellow is easy to follow every day, while fuchsia stands out brightly.
Select the next-most desaturated version of the color from active / unacked to active / acked, cleared / unacked to cleared / acked.
Text Colors
Select white text to match with the top two saturation levels of fuchsia, blue and red, and black text to go with everything else.
Font Weight
Select bold font for all active / unacked, except for diagnostic priority.
Linking the alarm table formatting to the styles
Each alarm table format property which you want to link to a style must first be added and set to “null”, then the style class reference added. If the “null” property is not added, the default property will be re-initialised when the page is opened again. (!! - Very strange behavior but that’s how it works).
Example
-
Under the ‘rowStyles’ property, for a given Activation / Ack combination, identify the alarm priority you want to reference to a style.
-
Click the arrow to open up that priority’s configuration.
-
Replace the hex code for ‘backgroundColor’ with “null”.
-
To the right of the priority name, click the plus.
-
Click Value.
-
On the newly created value, replace “key” with “classes”.
-
Use the dropdown selector to select the style to reference to.
-
Save the view. Close and open the view to make sure the default properties have not overwritten the style.
Repeat this and add a null backgroundColor, color and fontWeight, plus appropriate ‘classes’ reference, for every combination of activity / ack status and priority (20 in total).
Each ‘null’ configuration will cause a warning to appear at the top of the object properties banner. This is just too bad and we will live with it to provide the functionality.
Once all the styles are configured and linking performed, it’s possible to set up a test page with some dummy tags and ack / clear them as needed to validate each of the format combinations.
Ordering
The default ordering sorts the State column alphabetically, which means that Active / Unacked alarms appear below the Active / Acked alarms (!). Bad.
The solution to this is:
-
Enable the isAcked and isActive columns
-
Set their width to zero so they don’t appear
-
Set the sort order of the isAcked column to ascending.
-
Then set the activeSortOrder to 0:isActive, 1:isAcked, 2: priority, 3: activeTime.
This will set Active / Unacked alarms higher than Active / Acked alarms.
Also set the sort order of the column activeTime to descending.
Column Widths
Set the Priority, State and Active Time columns StrictWidth to True, and the following widths:
Active Time: 160
Priority: 90
State: 210
Filtering - basic
Set the basic object filtering as follows:
Filtering - custom
The alarms table can be filtered based on custom logic. This can allow table instances to be used for specific areas of the plant, with the alarms filtered on strings in the display path (for example).
Right click on the table and select Configure Scripts. Select filterAlarm.
The script is basically:
def filterAlarm(self, alarmEvent):
displayPath = str(alarmEvent.get('displayPath'))
if "myFilterString" in displayPath:
return True
else:
return False
Where “myFilterString” is some subset of the display path that you're looking for which represents a process area or machine, depending on how your tag folder convention works. Eg “Conveyance”, “1300”, etc.
The filter string can also be passed in as a custom property on the status table, which itself can come from a parameter on the view. This allows the whole view to be multi-instanced on different pages, just with a different filtering parameter.
The custom property binding to the view parameter:
The view parameter:
Summary
The above configuration creates an alarm status table which looks like this, can be multi-instanced and is centrally configured in one view, implements configurable string filtering based on the Display Path, and uses centrally configured styles for the formatting.