BACnet MS/TP to IP: Why Your Trunk Is Slower Than You Think

The complaint is always the same: graphics take ten seconds to populate, trends have gaps, an override takes long enough to apply that the operator clicks it twice. The controllers get blamed because they are old. But before anyone prices replacements, it is worth understanding where an MS/TP trunk actually spends its time, because a surprising amount of the delay is configuration you can fix this week.

How a token ring spends its time

MS/TP runs on a single RS-485 pair. One device transmits at a time, and the right to transmit is a token passed from address to address. Everything on the trunk waits its turn: every read your supervisor makes, every write, every alarm a controller wants to report. Token rotation time is the heartbeat of the whole segment, and it grows with device count, traffic, and every misconfiguration below.

The classic one is Max_Master. After passing the token, a master periodically polls for masters at higher addresses so new devices can join the ring. Max_Master defaults to 127. If the highest address on your trunk is 24 and Max_Master was never lowered, the ring spends real time every cycle polling addresses 25 through 127, waiting for replies from devices that will never exist. That is pure dead air, on every rotation, forever, until someone changes one number.

• Max_Master left at 127 on a trunk with a couple dozen devices: dead-air polling on every token rotation.
• Baud rate pinned at 9600 or 38400 because one legacy device on the segment cannot go faster, throttling every other device to match.
• One failing device dropping the token: the ring re-converges, and re-convergence is slow by design.
• A supervisor polling thousands of points on a short interval when most of them change a few times an hour.
• Wiring faults: missing or doubled terminators, star taps, and unshielded runs near VFDs all show up as retries, and retries eat rotations.

What IP changes, and what it does not

BACnet/IP removes the token entirely. Devices talk over switched Ethernet, full duplex, no arbitration, at speeds that make trunk bandwidth a non-issue. That part of the upgrade is real. What it does not fix is polling philosophy: a supervisor that hammers five thousand points every second on MS/TP will hammer them on IP too, and the controllers still have to service every request. COV subscriptions, where the device reports on change instead of answering polls, matter as much as the media change.

The honest migration path is rarely a forklift. A BACnet router per trunk isolates the worst segments and puts the supervisor on IP immediately. Controller replacement then follows the building's own refresh schedule, panel by panel, instead of a single budget-breaking season. The trunks that remain get shorter and quieter as devices move off them.

Check these before you blame the hardware

• Max_Master on every trunk matches the actual highest device address.
• Baud rate is consistent across the segment and as high as every device supports.
• No duplicate device instances or MAC addresses; duplicates produce exactly the intermittent weirdness people attribute to age.
• Supervisor poll rates are deliberate, and COV is used where the platform supports it.
• Termination and topology: two terminators, daisy chain, no stars.

Measure token rotation before and after. If the trunk is healthy and correctly configured and still cannot keep up with what the operation needs, that is when the IP conversation starts, and by then you will know exactly which segments justify it.