In this example scenario, you have a driver network with a single “device” application replicated many times in multiple devices, for example, a VAV application for 60 zones using 60 identical devices, each with identically-named proxy points, but under a uniquely-named device component. For simplicity in this example, devices are named simply “VAV1”, “VAV2”, …to “VAV60”.

For several proxy points in each zone, you need to establish alarming, adding an alarm extension. You could manually rename these points, or type “unique values” in BFormat type properties under each alarm extension, as well as related properties (in some cases) under its “offNormalAlgorithm” slot. This would ensure that alarm records (viewed in the Alarm Console) would show unique “Source” values for any alarm, without having to decipher by station ord (for example) which “RoomTemp” point was in alarm, for example to isolate by zone.

Or (more programatically) before replicating this VAV application, you could edit several Format-type properties of the alarm extension from defaults, such that generated alarms will contain more useful source data.

An example “solution” for this application, showing part of the station’s config structure, including the non-default values entered for Format-type properties under one alarm extension in one of the identically named points, is shown in Figure 2.

Note that the sourceName of the alarm extension has been changed to use two variables: “%parent.parent.parent.parent.displayName%” (plus) “%parent.displayName%”, separated by a space. Given the tree structure in use, now the alarm record will show 4 (parent) levels up for the first part of the source, that is the device (e.g. “VAV1”), then the proxy point name as the second part of the source, for example “RoomTemp”. So, in the Alarm Console the alarm source shows as “VAV1 RoomTemp”.

Alternatively, there is also a “folder-level independent” method to retrieve the device name for any proxy point, instead of the “parent.parent” method. See the next example History extension scenario.

Now, here is the “tricky” part. All the “alarm text” type properties are relative to the alarm record component generated by an alarm, and not to the alarm extension responsible for generating the alarm. So, you cannot use the “parent.displayName” scheme in the alarm text properties, at least with any useful results. Alarm text properties include “toNormalText” and “toOffNormalText” in the alarm extension, and (if an OutOfRangeExt) in the “Offnormal Algorithm” properties “highLimitText” and “lowLimitText” (note if using the latter, these override any entry in the “toOffNormalText” property of the alarm extension parent).

But because each alarm extension’s “sourceName” will now be unique (using the technique above), you can reference it within “alarm text type” properties, along with any desired static text. Except here, the sourceName is an “alarmData” field, from the alarm record.

In the example shown in Figure 2, when RoomTemp in VAV1 has a high limit alarm, the alarm data message text will be: “VAV1 RoomTemp is too HOT!”, and when it returns to normal the alarm data message text will be: “VAV1 RoomTemp is OK now.”

If desired, you could further modify the OffnormalAlgorithm high and low limit text properties to include the numerical (alarm) limit, using another alarmData field. For example, if highLimitText is set to a Format value of “%alarmData.source% is above %alarmData.highLimit% degrees!”, and the extension’s highLimit is set to 74.5, upon a high limit alarm the message text generated will be “VAV1 RoomTemp is above 74.5 degrees!”. This technique may be useful if routing the alarm using a minimum of alarm data text, say including only the timestamp and the message text.

To see what alarmData fields are available for use in this manner, go to a station’s Alarm Console and view the complete details (Alarm Record popup) for any one alarm.