A working token-passing network has one active token, one permitted transmitter, and a predictable route from the transmitting node through the RS-485 trunk to every listening node. Follow the packet from the serial driver outward: a failure at the transceiver, cable, termination, biasing, or turnaround boundary prevents higher-level MS/TP behavior from mattering.
Which path does an MS/TP frame follow?
The requesting application passes a message to the BACnet MS/TP data-link implementation. That implementation waits until its node owns the token, constructs the frame, and hands it to the serial interface. The RS-485 transceiver drives the multidrop trunk; receiving transceivers recover the signal, serial interfaces deliver bytes, and each data-link implementation decides whether to accept, forward, or ignore the frame.
| Hop | Function | Failure indication |
|---|---|---|
| Application to data link | Queues event, unsolicited, directed, or broadcast traffic | Message never appears in the transmit queue |
| Token-control logic | Grants one node permission to transmit | Queued traffic remains blocked or multiple nodes transmit |
| Serial interface and transceiver | Converts frames into RS-485 signaling | No differential activity or corrupted bytes |
| Multidrop cable | Carries the electrical signal to all attached nodes | Errors vary by node location or cable state |
| Receiving data link | Validates and routes the frame | Electrical traffic is present but frames are rejected |
MS/TP avoids making a permanent central poller the only traffic initiator. A node can transmit when it holds the token, making event-oriented and broadcast traffic practical while preserving deterministic access under stable membership. The token controls permission to transmit; it does not correct physical-layer defects or guarantee that an application consumes a received message.
Should the bus use BACnet MS/TP or a custom token protocol?
Both approaches can use a low-cost multidrop RS-485 trunk. The deciding criterion is interoperability versus implementation scope.
| Criterion | BACnet MS/TP | Custom RS-485 token passing |
|---|---|---|
| Interoperability | Designed for BACnet devices and broad integration | Limited to devices implementing the private protocol |
| Implementation scope | Includes behavior needed by a general-purpose interoperable protocol | Can implement only the functions required by one device family |
| Complexity | Higher when the application needs only a small message set | Lower if addressing, token recovery, framing, and diagnostics remain deliberately narrow |
| Payload range | Extended large-frame support covers payloads from 1 through 1032 bytes | Defined by the private design |
| Nominal speed evidence | The referenced specification material mentions 115 kbaud | Application-specific; 1 Mbaud was achieved in testing |
| Main risk | Unnecessary protocol scope for a closed system | Lifecycle ownership, compatibility testing, and recovery behavior remain with the designer |
Select BACnet MS/TP when BACnet interoperability, existing BACnet tooling, or connection to BACnet devices drives the project. Select a custom protocol only for a closed device set whose owner can define and test token creation, loss recovery, duplicate-token handling, node discovery, addressing, framing, and version compatibility. A test at 1 Mbaud demonstrates feasibility for one arrangement; it is not a compatibility claim for other devices or cable plants.
Where does token-passing communication usually stop?
Layer one first. RS-485 receivers need a usable differential signal and a stable idle state. Check transceiver power, reference conductors, polarity, cable continuity, topology, termination, biasing, and transmitter-enable control before decoding token state. Reflections or a floating idle bus can turn valid frames into framing or integrity errors.
| Field | What must agree | How to check it |
|---|---|---|
| Address | Each participating node must use an unambiguous data-link address | Read the configured node address and look for duplicates in captured traffic |
| Port | The selected physical serial interface must be wired to the intended trunk; no TCP or UDP port exists at this layer | Trace the connector to the configured serial channel and observe activity at its transceiver |
| Baud setting | All nodes must use the same serial rate | Compare configurations and decode a capture at that rate |
| Frame format | Serial framing and data-link framing must match | Check serial settings, then inspect frame boundaries and validation results |
| Timing | Token, response, turnaround, and recovery behavior must be mutually compatible | Measure intervals in a timestamped capture and compare them with the implementation configuration |
| Payload capability | Sender and receiver must accept the selected frame size | Test small frames first, then increase size while monitoring rejection counters |
If clean bytes reach every serial receiver but the token stalls, move up to the data link. Look for a node that never passes the token, repeated token-recovery attempts, two simultaneous token owners, duplicate addresses, or a participant using incompatible timing. Membership changes deserve specific testing because a device joining or leaving the logical ring can disturb real-time performance while the ring is rebuilt.
Which design is recommended for this application?
For a non-building, closed system seeking event, unsolicited, publish-subscribe-style, or broadcast messaging, use MS/TP when future BACnet integration has real value. Its interoperability offsets the additional implementation scope. For permanently closed controllers with a small, stable command set, a custom token protocol can reduce code and message overhead, but only if the project owns every node and treats recovery logic as a primary requirement.
Do not choose solely from nominal baud rate. At higher rates, propagation delay, transceiver characteristics, cable length, stubs, termination, clock error, driver turnaround, and capture equipment become more influential. Keep 115 kbaud when compatibility with other MS/TP devices is required. Treat 1 Mbaud as a custom-system engineering target that must pass electrical, timing, error-rate, membership-change, and mixed-traffic tests on the actual hardware.
How should the selected token bus be commissioned?
- Draw the complete data path from each application queue through its serial channel, transceiver, trunk, and receiving stack. Record which node originates each required directed or broadcast message.
- Inventory every node address, serial rate, frame setting, payload capability, and token-related timing setting. Remove duplicate addresses and configuration mismatches.
- Power down the network and inspect cable continuity, polarity, trunk-and-stub layout, termination placement, biasing, reference connection, and shield treatment against the hardware documentation.
- Power the bus and measure the idle and active differential signals at both ends and at suspect nodes. Correct electrical faults before interpreting protocol traces.
- Start with the smallest stable node set. Capture traffic and identify token transfer, permitted transmissions, and the return of the token through the active membership.
- Send a small directed message, a broadcast message, and the required event-driven traffic. Confirm that only the token holder transmits and that intended receivers accept each frame.
- Add nodes one at a time. Observe token-ring membership changes, recovery activity, latency, and error counters after each addition.
- If large frames are required, increase payload size in controlled steps up to the needed value within the supported 1-to-1032-byte range. Record failures by size and node.
- For a custom 1 Mbaud target, repeat the complete test on the actual cable plant and all production transceiver variants. Do not mix the result with a claim of BACnet device compatibility.
How is correct operation verified?
Verify electrical quality and protocol behavior separately. An oscilloscope or suitable physical-layer instrument checks differential amplitude, edges, reflections, idle stability, and driver release. A timestamped serial or protocol capture checks token ownership, frame validity, response behavior, recovery, and application delivery.
| Test | Pass condition |
|---|---|
| Stable membership | The token circulates continuously, each active node receives transmission opportunities, and no duplicate token appears |
| Application delivery | Directed, event-driven, and broadcast messages reach the intended consumers |
| Join test | A joining node becomes active without sustained loss of token circulation |
| Leave test | Removing a node causes only bounded recovery, followed by stable circulation among remaining nodes |
| Payload test | Every required size is accepted by every intended receiver |
| Load test | Measured latency and error counts remain acceptable at the required traffic rate |
FAQ
What happens if two RS-485 nodes use the same MS/TP address?
The logical ring can route token or data-link decisions to the wrong participant, causing intermittent traffic, collisions, or stalled circulation. Read every configured address and confirm uniqueness in a capture.
What happens if one node uses a different baud rate?
That node interprets valid traffic as corrupted serial data and its transmissions appear corrupt to the rest of the bus. Compare every serial configuration, then decode captured traffic at the common rate.
What happens if an MS/TP device leaves the token ring?
The remaining nodes must rebuild or recover token circulation, which can increase latency and disturb real-time performance. Test removal under load and measure the interval until stable token transfer resumes.
What happens if MS/TP is operated at 1 Mbaud?
A closed custom system may operate at that rate, but the cited compatibility point is 115 kbaud and one successful 1 Mbaud test does not qualify other devices. Verify the final system by capturing sustained token circulation, valid application delivery, acceptable error counts, and recovery after a node joins and leaves.