Bacnet - Optimizing a Bacnet Network

Optimizing a Bacnet Network

This Technical Notes will help you optimize a Bacnet network so that the communications between the station and the devices have a clean information transfer.

The following information is a continuation of the video tutorial that is located below:

 

 

As mentioned, in the video, please make sure that the mac addresses are unique and that they follow in sequential numbers as much as possible. The MSTP address of the local device which happens to be the communication card of the “Master” has a default value of 0 (zero) therefore this number cannot be used as a device mac address.  A suggestion would be to start addressing the devices with the #4 so that if any nodes are to be introduced on the network, at the same time as the master, the mac address #1, #2 or even #3 can be set on the other communicating device.

The MSTP port property has a “Link” folder with configuration parameter to communicate with the devices. Port Name is the communication port of the Master (COM2 is the onboard card of an EC-Bos) and Baud Rate is the communication speed of the protocol. (All peripheral devices have to be set to “Auto” so that the master has the priority speed) Max Master and Max Info Frame are adjustable parameters for the (Token-Passing) gathers the protocol information. When a Right-Click is done on the Link “Ms/Tp Configuration” can be executed.  (Max Master default value is 127 and Info Frames is 20) Executing this function will return information on the amount of maximum mac addresses on the network and the required information frame for each device. As mentioned above it is recommended to have the mac address # sequentially so that the token does not look for a mac address that does not exist. If the mac addresses are scattered this will causes a void when communicating.

 

Tuning Policy and Poll services

By default, a driver’s TuningPoliciesMap contains just a single TuningPolicy (“Default Policy”).  For the Bcp type network a BcpTuningPolicy is created. However, you can typically create multiple tuning policies, changing those items needed differently in each one. When creating proxy points under a device for that network, it can be assign each point (as needed) to the proper set of “rules” by associating it with a specific tuning policy. Caution using only a single (default) tuning policy, with all property values at defaults, can lead to possible traffic issues. In general, it is recommended that you create multiple tuning policies, and configure and use them differently, according to the needs of the network’s proxy points.

As a simple example (under a BacnetNetwork), you could change the default tuning policy’s “Write On Start” property from the default (true) to false. Then, duplicate the default tuning policy three times, naming the first copy “Slow Policy”, the second copy “Normal with Write Startup”, and the third copy “Fast Policy”. In two of those copies, change the “Poll Frequency” property from “Normal” to “Slow” or “Fast”, corresponding to its name. In the “Normal with Write Startup” tuning policy copy, you could change its “Write On Start” property back to true. Then, only the “Normal with Write Startup” tuning policy has “Write On Start” set as true. At this point you would then have 4 available (and different) tuning policies to pick from when you create and edit proxy points, where you could selectively apply the policy needed. Doing so will scatter the proxy point polling services at different rates.

Driver proxy points are only polled on the field bus when they are subscribed in the station.  Transient subscription of proxy points is typically caused by viewing them in a px view, property sheet, wire sheet or point manager. Permanent subscription of proxy points is typically caused by adding an alarm extension, having an active history extension, or by linking the proxy point to other components in the wire sheet. Always minimize the number of proxy points which are permanently subscribed, as this essentially defines the minimum number of points which will be polled all of the time. Deleting unsubscribed points, it is not going to affect the poll cycle time or busy time.

The BACnet poll service indicates how many points are being polled. Note that if the devices support read property multiple or COV subscriptions that the "count" value for each poll bucket represents the number of requests being sent, not necessarily the number of BACnet properties being polled. It is suggested to use the COV (change-of-value) reporting for points that change infrequently, if the device supports it.  This can be done by defining tuning policies in the Bacnet Tuning Policy Map for each of the different behaviors you want (COV, fast poll, normal poll, etc.)  Then from the point manager you can assign the points to the appropriate policies.

Looking at the "point count" property will indicate the total number of points being polled. The poll service cycle time indicates the time to retrieve all of the point values. As mentioned this can be improved by distributing the points into the fast, normal, and slow buckets according to their priority and required update frequency.  Cycle time will indicate how long it takes between updates for any given point.  Any time a point is written, it goes into a "dibs" queue, which is polled before polling the regularly scheduled list of points.  If you have brought most of those 5500 points in as writable proxy points, you should make sure to clear the writeOnStart/writeOnEnabled/writeOnUp flags in the tuning policies referenced by the points.  Also, make sure not to set the maxWriteTime too low (0 will disable automatic rewrites, and may be a good idea for many of the points).  Otherwise, you will be rewriting the points every maxWriteTime seconds, which will drive a dibs poll for the point.  If you have enough points rewriting and causing dibs polls, you can potentially starve the regular poll process.

An efficiency of the BACnet communication can be seen when verifying the worker’s queue size. The queue size is defaulted at a value of 1000. This is located under the Bacnet Comm/Server/Worker (Max Queue Size). Once the tuning has been optimized looking and the following path : Right-Clicking “BcpBacnetNetwork” -> “View”-> “Spy_Remote”-> writeWorker -> the queue.size should be 0 (zero). A refresh of the page will update the queue.size value. (In the TuningPolicy increasing Min Write Time decreases queue.size)

Hardware connection with end of line applications (EOL)

The BACnet Master-Slave/Token-Passing (MSTP) driver implements a data link protocol that uses the services of an RS-485 physical layer. Termination of the network with 120 ohms EOL resistors and proper shielding of the cable is required to eliminate interference. A complete information guide on this subject can be downloaded here:Network Guide.pdf

The following was taken from the (Ashrae Standard 135-2008y)

Although EIA-485 practice allows for a third wire to connect transceiver common or reference points together so the receiver common mode rejection voltage limit is not exceeded, the BACnet specification in Clause “9.2.1 Medium” only mentions “shielded, twisted-pair cable.”Due to electrical noise issues, some hardware applications cannot successfully communicate over EIA-485 without a remote common or reference connection and internal isolation. This has been particularly noticed in variable speed drive controllers that can produce local ground noise in excess of the EIA-485 common mode voltage limit. BACnet MS/TP also requires 1500 volt isolation when crossing buildings, but does not specify any mechanism for doing this. This proposed change is designed to describe wiring topologies for a reference wire in EIA-485 and to specify acceptable topologies for interoperable connections for both single-building and multiple-building installations (Found hereAdd-135-2008y.pdf)

9.2.1 Medium

An MS/TP EIA-485 network shall use shielded, twisted-pair cable for data signaling with characteristic impedance between 100 and 130 ohms. In addition to the twisted pair, an additional conductor may be used for common or signal reference if required by the particular device. Distributed capacitance between conductors shall be less than 100 pF per meter (30 pF per foot). Distributed capacitance between conductors and shield shall be less that 200 pF per meter (60 pF per foot). Foil or braided shields are acceptable. The maximum recommended length of an MS/TP segment is 1200 meters (4000 feet) with AWG 18 (0.82 mm2 conductor area) cable. The use of greater distances and/or different wire gauges shall comply with the electrical specifications of EIA-485

Optimizing a Bacnet Network

Add Feedback