The length of time a point value remains fresh depends on the stale time and on the poll cycle time. For each point, the system measures the stale time from the last time the point was updated. A 10-minute stale time, and an 8-minute poll cycle time can result in point values that are nearly eight minutes old. If you stop polling, those points begin going stale roughly two minutes, not 10 minutes later.
This can be confusing when viewers expect that the points in a graphic should stay up for the 10 full minutes (or the configured Stale Time) before going stale. However, the actual time depends on how long ago they were last polled.
The orange highlight indicates that the device is in fault. Often this is because of a duplicate Device ID (same Object_ID in the Device object of multiple devices). This is illegal in BACnet; each device must have a unique Object_ID for its device object.
You can still add such devices to the station, however, all but one will have a Device ID of -1 (unassigned), and be unreachable.
Devices must be locally re-configured to have unique Device IDs. Then, in the station, each BacnetDevice’s corresponding (Config) Device Object must have its Object Id property set to match accordingly. Or, delete the devices, re-discover, and add then again.
Upon station startup, the BACnet driver automatically uploads all Device object properties for each represented BACnet device, after which the station’s BacnetNetwork is fully initialized. Typically, such property uploads are inconsequential if there are mostly BACnet/IP or BACnet Ethernet devices.
However, if a BacnetNetwork includes many MS/TP devices, a long delay at station startup may result. During all these Device object uploads, more critical point data reads and writes cannot occur.
Any BacnetDevice with a Boolean slot named Skip Upload with a value of true, skips this upload at station startup. At any time you can still manually invoke the Upload action on any BacnetDevice to refresh these values—typically, most device object properties have static values.
BACnet proxy points are unique from proxy points in most other field bus drivers because the BACnet protocol reports its own
native abnormal status for data objects. The Framework learns about a BACnet point’s abnormal status from the Status_Flags property of the BACnet object.
Possible abnormal BACnet Status_Flags include the following:
To get this native status, you do not have to create a proxy point expressly for the status flags of a BACnet object. By default
only the selected property is polled and reflected in the Read Value of the ProxyExt. However, you can include the polling of other data (including statusFlags), by adding to the facets of the point.
When you add statusFlags to facets, the driver merges the native BACnet point status with the Framework’s status. Without adding the statusFlags key to the point’s facets, the driver returns only the default Framework status for the proxy point. For example, if the BACnet object is in alarm, the Framework may report it as {ok}.
The default behavior of BACnet proxy points using COV (Change of Value) instead of polling, matches polled-point behavior for status.
By default, the Framework exports all schedule data to the BACnet schedule object. Depending on the target BACnet device’s
implementation by vendor, some properties of its schedule objects may be read-only or may not exist. For example, a BACnet
schedule object may allow writes to its weekly schedule events, but not to its exception schedule (special events, if they
are read-only or perhaps do not even exist). The object may not even have a weekly schedule or an exception schedule (a Schedule
must only have one or the other; it may have both). Finally, the object’s Priority_For_Writing property may be read-only. A fault occurs if a target object cannot handle the data exported to it.