BACnet MSTP – Tusage_timeout, Nretry_token
CAS BACnet Explorer:
Available as a free tool for discovering, browsing, and testing BACnet devices.
BACnet MS/TP (Master-Slave/Token-Passing) relies on deterministic timing parameters to manage token passing between devices on a shared network. Two parameters that directly affect token reliability and network stability are Tusage_timeout and Nretry_token.
These parameters control how long a device waits for another device to use the token and how many times the token is retransmitted before corrective action is taken. Incorrect values can result in excessive retries, delayed communication, or unnecessary polling for new masters.
Tusage_timeout
Tusage_timeout is defined as the minimum amount of time that a node must wait without receiving a DataAvailable or ReceiveError event after passing the token to another node. This timer represents the window during which the receiving node is expected to begin using the token or reply to a Poll For Master frame.
The BACnet standard specifies a default value of 20 milliseconds. Implementations may use larger values, but the timeout must not exceed 100 milliseconds.
If the receiving node does not begin using the token before the sender’s Tusage_timeout expires, the sender assumes the token was not successfully accepted.
Nretry_token
Nretry_token defines the number of times a device will retransmit the token if it believes the receiving device failed to use it within the allowed time window.
The standard default value for Nretry_token is 1. This means the sending device will resend the token once before taking further action.
Token Retry Behavior
The Tusage_timeout parameter is evaluated after a token is transmitted. If the next station (NS) does not begin using the token before the previous station’s (TS) Tusage_timeout expires, the previous station will retransmit the token up to Nretry_token times.
If the receiving device still does not respond within the allowed retries, the sending device assumes the node is no longer participating correctly in token passing. At this point, it will attempt to recover by polling for a new master, starting with the MAC address immediately following the non-responsive device.
This mechanism prevents a single slow or non-responsive device from permanently blocking token circulation on the MS/TP network.
Example Timing Scenario
Consider an MS/TP network where Tusage_timeout is set to 20 ms and Device A passes the token to Device B. Device B has up to 20 ms to begin using the token.
If Device B does not respond within that time, Device A will resend the token. This process will repeat according to the configured Nretry_token value. If Device B never responds in time, Device A will initiate a Poll For Master starting at Device B + 1.
Practical Configuration Guidance
In real-world MS/TP networks, particularly those with longer cable runs, higher baud rates, or slower devices, a Tusage_timeout of 20 ms may be insufficient.
Increasing Tusage_timeout to a value between 50 ms and 100 ms can improve network stability by allowing slower devices more time to respond. The configured value must not exceed 100 ms, as required by the BACnet standard.
Any changes to MS/TP timing parameters should be applied consistently across devices and validated under normal operating conditions.
FAQ
What happens if Tusage_timeout is set too low?
Devices may be falsely assumed to be non-responsive, leading to excessive token retries and unnecessary
Poll For Master activity.
What happens if Tusage_timeout is set too high?
Token recovery may be slower if a device genuinely fails, increasing overall network latency.
Should Nretry_token always be increased?
Not necessarily. Increasing Nretry_token can mask intermittent timing issues but may also delay recovery
from actual device failures.
Are these parameters device-specific?
Yes. While defined by the BACnet standard, the exact configuration and exposure of these parameters depend
on the device implementation.