Asset Manager (/C/Ncam_AssetManagerHome.

App)  
Marketplace (/Marketplace_Home)  
Software (Https://Www.Niagara-
Central.Com/Service/Esd/Software/Download/View)  
Licensing (Https://Www.Niagara-Central.Com/Service/Home)  
Resources (Https://Docs.Niagara-
ARCHCommunity.Com)  
University (Https://Www.Tridiumuniversity.Com/)  
Tridium (Http://Www.Tridium.Com)
HOME (/S/) TOPICS GROUP (/S/GROUP/COLLABORATIONGROUP/DEFAULT) BOOKMARK FEED (/S/BOOKMARK-FEED) ARTICLES (/S/KNOWLEDGE-A

BACnet tuning suggestions

Document contains tuning suggestions for BACnet driver properties.

Jun 18, 2020 • Knowledge

TITLE
BACnet tuning suggestions

URL NAME
BACnet-tuning-suggestions

SOLUTION
BACnet Tuning Suggestions

The BACnet system will be tuned by the system integrator using what the integrator knows about the system and the customer’s requirements. The best
way to learn to tune a system is to segregate your points into different tuning policies and start making changes until you get better performance. Currently
this is the only detailed document pertaining to tuning BACnet networks.

Common Problems-

One common issue is queue full exceptions. If you notice queue overflow messages in the station dialog, it is important to know which queue is
overflowing. There are many different communications mechanisms in BACnet and they use different queues. If the write queue is reporting an overflow
then you may need to configure your tuning policies so that write-on-start is not enabled on some of the points - otherwise the JACE may start with a to-
do list that is larger than the queue can handle. Alternatively, you may try increasing the queue size. By default, the BACnet Worker has a default queue
size of 1000. This value can be increased. This property is located under the Server object on BACnet Comm (see BACnet driver tuning properties
below).

Increasing the Min Write Time will prevent points from being written too frequently and this may help if the write queue is overflowing. Increasing the
Max Write Time will reduce the frequency that the same value will be overwritten (to be sure that it was not changed by another system or reset during a
restart of the BACnet device) and this may also help (see BACnet driver tuning properties below).

The tuning policy can control whether the points will use COV or not and whether or not they use "Confirmed COV". The COV subscription lifetime is
also set on the tuning policy. Some devices will not support COV and on these devices, the tuning policy settings for COV are not ignored. Some devices
will only support a limited number of COV subscriptions and when this number is exceeded then we will default to using polling on the other points.
BACnet does not have a mechanism for a device to report how many COV subscriptions it supports, but the device will refuse a new COV subscription
request when the limit is reached. If you know the limit, then you can set it on our object for that BACnet device - by default it is set to "max". COV can
also be enabled and disabled at the device level on the BACnet device object. If it is set to disabled, then the tuning policy settings for COV will be
ignored.

On the tuning policy you can control Write_On_Start, Write_On_Up and Write_On_Enabled.
1. writeOnStart controls whether Niagara will attempt to write values to all the writable points that have non-null values in our system when the
Niagara station starts.

2. writeOnUp controls whether Niagara will attempt to write points in a BACnet device when the device goes from a down state to a not-down state.

3. writeOnEnabled controls whether Niagara will attempt to write points in a BACnet device when the device is enabled.

On the tuning policy you will be able to set the poll frequency to fast, normal, or slow. This will correspond to the Fast-Rate, Normal-Rate, and Slow-Rate
that you can configure under Poll Service under the Network Port. Note that some of the points that are assigned to a tuning policy may be associated with
different network ports (i.e. IP port vs. Ethernet port vs. MSTP port 1 vs. MSTP port 2) so the "slow" frequency (for example) can be a different time
period for points that are associated with different ports.

docBacnet note

docBacnet has some special stale time tuning policy notes - module://docBacnet/doc/aBacnetTuningPolicyNotes.html
In general, you should never set the "Stale Time" property in a Tuning Policy shorter than the poll cycle time, or else points will go stale in the course of
normal polling. Instead, set the stale timer to be longer than the largest expected poll cycle time. This period can vary depending on how many Px
graphics are being viewed, and so on.

Also, note that for each point, the stale timer is measured from the last time the point was updated. This means if you have a 10-minute stale timer, and an
8-minute poll cycle time, you will have some points with values nearly 8 minutes old. If you stop polling, those points will begin going stale roughly 2
minutes after polling has stopped, and not 10 minutes.

This has resulted in some confusion--where the expectation was that after viewing a graphic, any points in it 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.

docDriver note

The more general (not BACnet specific) tuning policy notes say this about stale-time:
Stale Time Applies to all proxy points.

If set to a non-zero value, points become "stale" (status stale) if the configured time elapses without a successful read, indicated by Read Status "ok."

If set to zero (default), the stale timer is disabled, and points become stale immediately when unsubscribed.

By default, proxy point status "stale" is indicated by tan background color. In addition, stale status is considered "invalid" for any downstream-linked
control logic. For more details, see About "isValid" status check.
 
Note-
Stale time is recommended to be specified at least three times the expected poll cycle time. Most peer-to-peer networks do experience collisions and
missed messages. Setting the stale time short will likely produce nuisance stale statuses. If a message is missed for some reason, then another poll cycle
time or two is allowed for the message to be received before setting the stale flag.

Other Considerations
Transport Lockup Threshold should be greater than "one plus the number of ADPU retries" times the ADPU Timeout. AX insures that this is the case, but
you have to change this yourself in R2 if you increase the ADPU Timeout or the number of retries.

We don't do a lot of segmentation and there aren't any established rules here but 2000 to 6000 ms should be good for the ADPU Segment Timeout.

Servicing the token passing on MSTP uses a lot of CPU. If you decrease the baud rate that should help quite a bit if you are having an issue with CPU
usage. Usually it�s only a problem at 76.8k, although 38.4k could also be a problem. Look at the qnx spy pages to see how much CPU the various MSTP
processes are using.

Each COV subscription will add to the load on the client queue. While COV is typically more efficient than individual point polling, for points that update
frequently it is probably much less efficient than RPM. So you may want to make a change at least on some of the more dynamically changing points so
that they do not use COV (if your device supports RPM). If you reduce the COV subscriptions then you may not need to increase the client queue size to
get rid of QFE's.

Another observation is that the number of ADPU retries defaults to three. We don't see a lot of devices in real systems that will respond on the second or
third try. It might be a good idea to reduce the number of retries to one. That can reduce the load on the client queue and make for faster response since it
will more quickly give up on devices that are not responding. If you reduce it you don't need to reduce the Transport Lockup Threshold, but you can if you
want to. We should never reach that threshold normally so reducing it should not normally have any effect.

Some of the problems and diagnostic tools that are found in a peer-to-peer CSMA/CD network (like Lonworks) do not apply to an MSTP token passing
network. Since the network uses a token there are few collisions. Collisions generally occur when one device thinks the other device is too slow, so it
regenerates a token at the same time the slow device replies to a message, or something similar. If there are problems with noise or bad wiring, then those
problems may result in lost tokens. This will cause the master to generate a new token after a certain timeout period, and that will result in a message in
station output.

Improperly terminated or biased networks can sometimes lead to problems. In short runs you may get away without having any termination or biasing.
However, BACnet MS/TP does specify termination and biasing. Sometimes people put termination on, but no biasing, which can lead to an indeterminate
state of the line at each device’s receiver. This can cause problems. And make sure that 25-30 devices are not full load, or you may run into problems with
the drivers ability to fully pull the line low or high for a 1 or 0.

Also see- https://www.niagara-community.com/s/article/Troubleshooting-BACnet-MS-TP (https://www.niagara-community.com/s/article/Troubleshooting-BACnet-

MS-TP)

BACnet driver tuning properties-

There are several properties on the BACnet driver that provide tuning functions. The below list contains the properties and brief description of its function.

Properties under BacnetNetwork/BacnetComm:

/Server/Worker

maxQueueSize: can be set as large as needed; it is just an arbitrary limit on the max size of the queue of incoming requests from other BACnet clients to our BACnet
server.

/Transport

clientQueueSize (serverQueueSize): is the queue size for client (server) requests at the transport layer - default of 100 can be easily increased as it doesn't incur
additional memory overhead.

lockupThreshold: timer for when Niagara thinks something unusual has gone wrong with the transaction. Niagara expects that it will either (a) get a response from the
device - success or error, or (b) time out without a response from the device after apduTimeout * (retries + 1). The lockup threshold is therefore programmatically and
automatically set above this, and if this timer is reached without either (a) or (b) happening, then it's an indication something is locked up in the transport layer and
the transaction is reset.

apduTimeout - Our default time value is typically the best number. You don't want to make this timeout very long. This is how long we are waiting for a response from
the device. Any device should be able to respond in 2 seconds. If it doesn't then  something major is wrong and that needs to be fixed.

/Network

routingEnabled: Is Niagara acting as a router? This should pretty much always be true; BACnet requires that a device connected to multiple networks route between
them. If you have another device already routing to a network and don't need this station to route, you shouldn't create a port for that network. If a network
misconfiguration is detected, this gets set to FALSE, unless "maintainRoutingEnabled" is set to TRUE.

maintainRoutingEnabled: controls if Niagara will keep its network layer intact when a packet is received that indicates network misconfiguration. Default value of false
is probably better changed to TRUE in most cases. If left false and a misconfiguration is found, the enabled network ports are removed from the local router table and
will need to be disabled/enabled in order to allow discovery on those networks.

 minimumRouterUpdateTime: timer for detecting router loops when multiple devices claim to be the router to a network. Receipt of two I-Am-Rout-To-Network
messages for a given DNET within this time frame will indicate a network misconfiguration. Set to 0 to disable this check.

routerDiscoveryTimeout: when Niagara attempts to discover a router in order to forward a message, it will try this long before giving up and telling the original sender
we can't route its message.

terminationTimeValue: used only for PTP connections; has no bearing otherwise.

Hidden slots (you must go to the slot sheet and un-hide via config flags)-

Slots on BacnetNetwork slot sheet-

worker: The BacnetNetwork's "async" queue for actions that need to be done during station operation, but which take enough time they can't be done on the engine
thread. For example, uploading a device, subscribing for COV, etc., anything that requires BACnet comm, but isn't already on another thread. Polling, pinging, etc. are
already on their own threads.

writerWorker: BacnetNetwork's "write" queue for posting proxy point writes. This will coalesce successive writes to the same point.

Should address QueueFullExceptions such as this -BacnetDevice {FCU613_082007}: javax.baja.util.QueueFullException javax.baja.util.QueueFullException. Recommend
this value be set to 1.5 times the number of writable points.

NOTE: The write worker is used to subscribe COV., single threaded. Only one point at a time. The poll scheduler will work much better assuming devices utilize
readPropertyMultiple and have a sizable maxApdu size. COV should only be used when values are static and always need to be subscribed. Never use for px subscribe.
Only when needed for alarming.

CovWorker: Hidden property on the BACnet Network. Un-check the 'Hidden' Config flag to expose this on the property sheet. This is a queue. You may need to
increase this queue to keep it from overflowing if there are a large number of points doing COV.

submitDeviceManagerJob, lookupXXX (all lookup actions): should not have a need to interact with these actions

MS/TP Link layer (under Network): Max Info Frames: Limits the number of messages the Jace can send before the token must be passed.

Other reference material-

Some notes in docBacnet - module://docBacnet/doc/aBacnetTuningPolicyNotes.html

There are some notes about the BACnet polling changes in different versions in docBacnet - module://docBacnet/doc/aBacnetPollingChanges3_2.html
and there may be more details in the release notes as well.

BACnet virtual points are a feature available in AX 3.2 and greater. For more information read docBacnet -
module://docBacnet/doc/aBacnetVirtualPointsPx.html

There is some general information about tuning policies in the docDriver guide - module://docDrivers/doc/aTuning.html

*** Always use the latest released BACnet driver that is supported by your license so you are using the most up to date software ***

Was this article helpful? 5 0

Files (0) (/s/relatedlist/ka94G000000XaYtQAK/AttachedContentDocuments)

Question Post

What would you like to know? Ask

rtincher (/s/profile/005D0000005RQHQIA4) (Customer) asked a question.

Edited February 4, 2021 at 11:51 AM (/s/question/0D54G00007U1vxmSAB/regarding-httpswwwniagaracommunitycomsarticlebacnettuningsuggestionsthis-is-greatly-needed-info-
for-sis-is-there-any-plans-to-generate-a-tech-doc-further-commentsquestions-below-n4-49-all-bacnet-ip)

Regarding https://www.niagara-community.com/s/article/BACnet-tuning-suggestions

This is greatly needed info for SIs. Is there any plans to generate a tech doc? Further comments/questions below. N4 4.9, All
Bacnet IP.

In this post, apduTimeout is listed under Transport. I do not see it under /Transport. I am not using a Jace. apduTimeout I found is on the LocalDevice. Is this a typo or should I see
something under /Transport?
 
Mine is a large site. 2300 controllers, 77,000 proxy points distributed on 5 different UDP Ports (47801, 47862, 47805, 47806 and 47807) to a web supervisor. Server class, 3.7Ghz,
32Gb (4Gb Max Heap currently). CPU runs 3 to 5%, Heap used climbs to 1900Mb then resets to 800Mb.
 
 All of the Bacnet Properties I have changed below came from find, trial and error. I found them, attempted to understand them with available documentation and web searches, make a
Expand Post

JACE
(/S/TOPIC/0TO4G000001IDW3WAK/)

4 answers 112 views

Like Answer

mhobbs (/s/profile/005D0000005RcslIAC) and mtoppings (/s/profile/005D0000005RPtjIAG) like this.

More answers 1 of 4

rtincher (/s/profile/005D0000005RQHQIA4) (Customer)

3 months ago

Like

Write an answer...

FOLLOW

RELATED ARTICLES

Tuning the RDBMS Driver (/s/article/Tuning-the-RDBMS-Driver) 9.63K

Troubleshooting BACnet MS/TP (/s/article/Troubleshooting-BACnet-MS-TP) 12.73K

Bacnet Tuning Policy notes (/s/article/aBacnetTuningPolicyNotes4) 958

About Bacnet Tuning Policies (/s/article/aBacnetTuningPolicies4) 213

AX Control Objects: Tuning PID Loops and Commissioning (/s/article/AX-Control-Objects-Tuning-PID-Loops-and-Commissioning) 692

TRENDING ARTICLES
Troubleshooting FOX connections
(/s/article/Troubleshooting-FOX-connections)

Study Guide-BQL
(/s/article/Study-Guide-BQL)

Mobile Tutorials: App Creation

(/s/article/Mobile-Tutorials-App-Creation)

Study Guide-Modules and Components

(/s/article/Study-Guide-Modules-and-Components)

Mobile Tutorials: Field Editors

(/s/article/Mobile-Tutorials-Field-Editors)
NIAGARA COMMUNITY       

Home (/s/)
Articles (/s/knowledge-article)
Profile (/s/profile/home)
Log In (/Login?nav=comm)
Sign Up (/Sign_Up)
Community (/Comm_Home)
Marketplace (/Marketplace_Home)
Software (https://www.niagara-central.com/service/esd/software/download/view)
Licensing (https://www.niagara-central.com/service/home)
University (https://www.tridiumuniversity.com/)
Tridium (http://www.tridium.com)
Resources (https://docs.niagara-community.com)
About Us (/Comm_AboutUs)
Contact Us (https://www.tridium.com/us/en/Learn/about-us/about-tridium)
Stay Connected
   (https://www.Facebook.com/Tridium)    (https://www.twitter.com/tridiuminc)    (https://www.youtube.com/user/TridiumInc)
(https://www.linkedin.com/company/tridium)
Need Help?

North and South America (AMER)

Email: support@tridium.com (mailto:support@tridium.com)
Phone: 877-305-1745

Europe, Middle East, and Africa (EMEA)

Email: ordersemea@tridium.com (mailto:support@tridium.com)
Phone: +44 (0) 1403 740290

Asia Pacific (APAC)

Email: ordersap@tridium.com (mailto:support@tridium.com)
Phone: +86-10-56697209

Terms of Use   (/Comm_TermsOfUse) Privacy Statement   (/comm_PrivacyPolicy) Subscribe   (https://pages1.tridium.com/2018-GDPR---Website-

Form_Sign-Up-page.html)Global Unsubscribe   (https://pages1.tridium.com/2018-GDPR---Website-Form_Custom-Unsubscribe-Page.html)

The company is an independent business© 2019 Tridium Inc. All rights reserved.
entity of Honeywell International Inc.