BFormat example: naming points, VAV scenario

This example involves a driver network of VAVs for 60 zones using 60 identical devices, each with identically-named proxy points, but under a uniquely-named device component. For simplicity, assume that the devices are named: VAV1, VAV2, …to VAV60.

Several proxy points in each zone require an alarm extension. You could manually rename the points for all 60 devices (a task that could take hours), or use BFormats to configure all VAV point names in a single operation.

Manually renaming the points in each zone

This would involve entering unique names for all BFormat-capable properties under each alarm extension. In some cases, you may also have to modify related properties under the device’s offNormalAlgorithm slot. Although not required, these changes would ensure that alarm records viewed in the alarm console provide unique source values (names) for each alarm. Without these unique names, only the station ords identify each VAV. For example, it can be difficult to isolate the zone and RoomTemp point for a specific alarm by looking for the point’s ord.

Replicating properties using BFormats

This method will save you time. You begin by replacing the default values for several BFormat-capable (text) properties of one VAV’s alarm extension such that generated alarms contain more useful source data, then you replicate the VAV application to the remaining 59 VAVs.

• VAV1, VAV2, etc. are Lon device objects.

• Points is the point device extension.

• Inputs is a Lon point folder.

• RoomTemp is a numeric Lon proxy point.

• proxyExt is a Lon proxy extension.

• OutOfRangeExt is a RoomTemp alarm extension.

• sourceName is a RoomTemp property. Instead of entering a value for this property on each of 60 property sheets, the following BFormat script resolves to a unique name for each VAV in the alarm console:

  %parent.parent.parent.parent.displayName% %parent,displayName%

  This name contains two variable scripts separated by a space. The variable on the left resolves to four parent nodes in the tree structure to arrive at the device name (VAVn). The variable on the right resolves to the proxy point name, in this example, RoomTemp. In the alarm console the alarm source displays as VAVn RoomTemp, where n is a number between 1 and 60.

• toNormalText is a RoomTemp property that sets up a message when a point in alarm returns to normal. Instead of entering a value for this property on each of 60 property sheets, the following BFormat script customizes the message for each VAV:

  %alarmData.sourceName% is OK now.

  This script resolves to the VAV name.

• OffnormalAlgorithm is the title of a group of properties on the property sheet.

• highLimitText is a RoomTemp property that sets up a message when the point returns a temperature above the defined limit:

  %alarmData.sourceName% is too HOT!

• lowLimitText is a RoomTemp property that sets up a message when the point returns a temperature below the defined limit.

  %alarmData.sourceName% is too COLD!

Here is the tricky part: All the alarm text properties are relative to the alarm record component generated by an alarm, and not to the alarm extension responsible for generating the alarm. Alarm text properties in the alarm extension OffnormalAlgorithm include:

• toNormalText

• toOffNormalText

If the extension is an OutOfRangeExt, alarm text properties include:

• highLimitText

• lowLimitText

  These OutOfRangeExt properties override any entry in the toOffNormalText property of the alarm extension parent.

The location of these text properties in the alarm record means that you cannot use the %parent.displayName% script for the alarm text properties, at least not if you expect to get any useful results. But because each alarm extension’s sourceName is now 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 , when RoomTemp in VAV1 triggers a high limit alarm, the alarm data message text displays: VAV1 RoomTemp is too HOT!, and when it returns to normal the alarm data message text displays: VAV1 RoomTemp is OK now..

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 this BFormat script: %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 displays VAV1 RoomTemp is above 74.5 degrees!. This technique may be useful if routing the alarm, for example, to a cellphone, where a minimum amount of alarm data text, including only the timestamp and the message text, are needed.