Issue
TAC has discovered an anomaly where R2 BACnet networks operating with the BACnet jar version 523b or earlier may stop updating object values after a period of time, typically over a 24 hour period. In certain large BACnet networks, the polling mechanism in the BACnet service can get into a "deadlock" condition, causing polling to cease. The only way presently to recover from this condition, with version 523b, is to restart the Universal Network Controller (UNC).
Environment
I/A Series R2 (Niagara) station with the BACnet service, version 523b or earlier
Cause
Operating with the BACnet jar version 523b or earlier may stop updating object values after a period of time.
Resolution
Refer to TPA-RKFD-08-0010.00, "Issues with I/A Series R2 BACnet Integrations" for Solution and Action.
BACnet jar 527i (along with the revised bacnet.properties file) was recently released to help prevent the "deadlock" condition from occurring, thus ensuring consistent polling and updating.
In addition, the new jar allows for composite math precision limitation in rewrite determination. Composite math results in values being sent to BACnet controllers from the UNC being slightly different than those being written to and read from the controller itself. For example, if the UNC writes "50.0," the controller will be "49.99999." Since these two values are not the same, the UNC will attempt to re-send the value. With the implementation of the "MinimumFloatDifference" property in the bacnet.properties file, this difference will now be ignored. In past releases, this has caused extra writes, and more importantly, unnecessarily increased the amount of traffic on the network, resulting on slower polling of other BACnet objects.
Our recommendation is to upgrade any UNC with BACnet integrations to the 527i BACnet jar. The files are contained in a .ZIP file - bacnet-2.305.527i.zip. The .ZIP file contains the jar files, the bacnet.properties file, and a READ_ME_FIRST file that has detailed instructions for installing the files.
