Most MS/TP problems are wiring. I say that in almost every article about trunks, and I mean it. But there is a class of MS/TP fault where the wire is perfect, the meter checks pass, every device has power and a unique address, and one controller still never shows up. Or everything shows up and the whole trunk feels like it's running through mud. Those are usually two settings: Max Master and Max Info Frames.
Neither is complicated once you know what the trunk is actually doing. So start there.
How an MS/TP trunk decides who talks
RS-485 is a shared pair of wires. Only one device can transmit at a time, or the signals collide and everyone hears garbage. MS/TP — Master-Slave/Token-Passing — solves that with a token. Whoever holds the token is allowed to talk. When it's done, it passes the token to the next master up the address range. The token goes round the ring, and every master gets its turn.
Three facts about that ring matter for this article:
- Only masters hold the token. Masters use MAC addresses 0–127. Slaves (128–254) never get the token; they only answer when a master asks them something.
- Each master only knows its successor. A master holding the token doesn't keep a list of the whole trunk. It knows “Next Station” — the next master above it that answered — and passes the token there.
- New masters are found by polling. Periodically, a master holding the token sends a Poll For Master frame to an address in the gap between itself and its Next Station. If something answers with Reply To Poll For Master, that device becomes the new Next Station and joins the ring.
That last point is where Max Master comes in.
Max Master: the ceiling on the search
Max Master is the highest MAC address a master will ever poll or pass the token to. When the highest-addressed master on the trunk looks for its successor, it searches upward from its own address to Max Master, then wraps round to 0. Anything above Max Master is simply outside the search. Nobody ever sends it a Poll For Master, so it never answers one, so it never joins the ring.
Why “too low” is so hard to spot
Here's the classic call. A contractor adds a VAV to an existing trunk. The existing devices run MACs 1 through 30, Max Master set to 31 on everything because that's what the original installer chose. The new box gets MAC 42 because someone picked the next number on a floor plan. It's wired correctly. The meter checks pass. Its status LED shows it's receiving traffic. It never appears in the front end.
Nothing alarms, because nothing is broken from the trunk's point of view. The ring is healthy. It just doesn't include MAC 42. The new device is listening to a perfectly good conversation that it will never be invited into.
You get the same result when a replacement router or a replaced controller comes out of the box with a low default Max Master and nobody changes it. If that device happens to be the highest master on the trunk — or the one covering the gap where a new device lives — its low ceiling decides who gets found.
What “too high” costs
The lazy answer is “set Max Master to 127 everywhere and never think about it again.” On a lot of sites that's what you'll find, and on a lot of sites it works fine. But it isn't free, and it's worth knowing why.
When Max Master is 127 and your highest device is 20, the gap from 21 to 127 is 107 empty addresses. In normal running, the highest master only sends an occasional Poll For Master into that gap, one address at a time, and each unanswered poll costs a short timeout — tens of milliseconds. Spread across many token cycles, that's a modest tax. Most healthy trunks absorb it.
Where it matters more is recovery. When the token is lost — a device resets, a noise burst corrupts a frame, the router reboots — the ring has to be rebuilt, and a master that's lost track of its successor may have to poll its way up through the address range to find the next one. Every empty address below Max Master is another timeout on that search. A ring that rebuilds in a blink with Max Master sized to the trunk can take noticeably longer when it has to sweep a hundred empty addresses. On a trunk that's already marginal, that slower recovery can be the difference between a blip nobody notices and a device going briefly offline in the front end.
So I don't treat 127 as wrong. I treat it as a choice with a small, real cost, and on a big or busy trunk I'd rather size it.
Setting Max Master sensibly
- Number the masters low and contiguous. Router at 0 or 1, controllers upward from there, no big jumps. Gaps aren't illegal, but every gap is empty addresses somebody has to poll.
- Set Max Master a little above the highest master you have. Leave headroom for the devices you know are coming — if the trunk has 24 controllers and another six are planned, don't set it to 24.
- Make it the same on every master, router included. Mixed values are how you end up with a device that's found by one neighbour and ignored by another.
- Put it on the riser diagram. The next tech adding a box needs to know the ceiling before they pick an address.
Max Info Frames: how much you can say per turn
Max Info Frames is the number of data frames a master may send each time it holds the token, before it has to pass it on. A lot of controllers ship with it set to 1. For an ordinary VAV, 1 is often fine — it answers a read, maybe sends a COV notification, and passes the token.
The problem is the device that talks for everybody. The router, or the supervisory controller's MS/TP port, is the one carrying every read, write and subscription from the front end onto the trunk. If the front end has forty reads queued for devices on this trunk and the router can only send one per token pass, those requests wait in line while the token makes a full lap for each one.
The symptoms are distinctive:
- Values on graphics update slowly, in a rolling wave.
- Writes and overrides time out or take several attempts, even though the device answers reads.
- Point discovery or a database upload crawls.
- Nothing is offline, and the wiring checks are clean.
Can it be too high? Yes. A device allowed to send a large number of frames per token hold can keep the token long enough that everyone else's turn comes round late. On a busy trunk you trade one bottleneck for another. The field devices generally don't need more than a few; the router needs enough to clear its queue in a reasonable number of laps.
Seeing it in a capture
A multimeter will never show you either of these faults. The wire is fine. You need to watch the frames. An MS/TP capture — a USB-to-RS-485 adapter and a capture tool, with the result opened in Wireshark — or your router's MS/TP diagnostics, if it has them, will show you what the ring is doing.
| What you see | What it means |
|---|---|
| Token frames cycling through a fixed set of MACs, and the missing device's MAC never appears as a token destination | The device isn't in the ring. Check its MAC against Max Master on the device that should be polling that gap. |
| Poll For Master frames stop at an address below the missing device's MAC, then wrap to 0 | Max Master is lower than the missing device's address. That's your answer. |
| Poll For Master to the right address, no Reply To Poll For Master | The device isn't answering — now look at baud rate, polarity, power, or a duplicate address. Not a Max Master problem. |
| Long runs of Poll For Master sweeping many empty addresses after a disturbance | Ring rebuild across a big empty range. Consider sizing Max Master to the trunk. |
| The router sends one data frame per token hold, with a queue of requests building | Router Max Info Frames too low for its job. |
| Token loop time long and uneven, one device holding the token for many frames | A Max Info Frames value set too high on a chatty device, or genuine overload. |
Token loop time is the most useful single number here: the time between the token arriving at the same device twice. Record it on a healthy day. When someone says the trunk “feels slow,” you have something to compare against instead of an opinion.
Where these two sit in the fault order
I check them after the physical layer, not before. If the meter checks on the trunk don't pass, no configuration change will make it reliable. Once the wire is proven, I go through the configuration in this order: baud rate the same on every device, MAC unique on the trunk, Max Master covering the highest master, then Max Info Frames on the router. A duplicate MAC can look a lot like a Max Master problem — one device flickers in and out — so rule it out properly; the three BACnet addresses article covers why.
If you've got a device list, paste it into the BACnet Config Checker. It flags a MAC above Max Master, Max Master lower than the highest MAC, duplicate MACs and baud mismatches in one pass, and it runs in the browser with nothing leaving the page.
- Missing device, clean wiring: compare its MAC to Max Master first.
- Everything present, everything slow: look at the router's Max Info Frames before you blame the trunk.
- Record both values and the token loop time when the trunk is healthy. That baseline turns the next call into a comparison.
Neither setting is exotic. They're just invisible until they're wrong, and when they're wrong the trunk doesn't tell you. You have to go and look.
Go deeper
MS/TP, BACnet/IP and the capture method, chapter by chapter
How the token ring works, the meter sequence for RS-485, BBMDs, network numbers and reading a Wireshark capture without drowning in it. BAS Communication is the protocol layer underneath this article, written for the tech holding the laptop.
Get BAS Communication — A Field ReferenceFound a wrong number or a broken link? Tell me and I’ll fix it.