Modbus Plus

Modbus Plus is no longer manufactured. This page documents the protocol’s design and migration path — not Ziggurat project experience with Modbus Plus. Our direct expertise is in Modbus TCP, the protocol that replaces it.

ELI5

Imagine a meeting where only one person can talk at a time. Instead of one person calling on each of the others in turn (the way a typical SCADA system polls devices over Modbus TCP), everyone sits in a circle and passes a “talking stick.” Whoever holds the stick can speak, then passes it to the next person. No one can interrupt, no two people talk at once, and everyone gets a turn. That’s Modbus Plus — a token-passing network where the token is the right to transmit.

Outsider’s Guide

Modbus Plus is a proprietary Schneider Electric/Modicon communication protocol. It predates Ethernet becoming standard in industrial environments and was designed for PLC-to-PLC communication in factory and process automation.

Where it sits: Inside Schneider Quantum and older Modicon PLC systems, connecting controllers to each other and to HMI/SCADA gateways. It stays invisible to the integrator until something needs to change or expand.

What a prime contractor should care about: If a brownfield data center or industrial site runs Modicon Quantum PLCs, the internal PLC-to-PLC network is often Modbus Plus. This is not a problem until the project scope includes expanding the PLC count, replacing controllers, or integrating non-Schneider devices. At that point, the migration question surfaces: keep Plus or move to Modbus TCP. The answer is almost always “migrate at the next hardware replacement cycle” — but the migration scope includes hardware changes, not just configuration.

Red flag from a sub: If a subcontractor proposes Modbus Plus hardware (SA85 adapter cards, new Modbus Plus cable sections) for new work, this signals either an outdated design template applied without review or unfamiliarity with current Schneider hardware. There is no technical reason to start a new Modbus Plus network or cable section today.

Visual Explanation

Token-Passing Bus vs Polling Star

MODBUS PLUS — Token Bus                 MODBUS TCP — Polling Star
┌─────────────────────┐                 ┌─────────────────────┐
│                     │                 │    SCADA / Client    │
│  ┌───┐    ┌───┐    │                 │      ┌───┐          │
│  │ 1 │───▶│ 2 │    │                 │    ┌─│ M │─┐        │
│  └───┘    └─┬─┘    │                 │    │ └───┘ │        │
│    ▲        │      │                 │    ▼       ▼        │
│    │        ▼      │                 │  ┌───┐  ┌───┐      │
│  ┌───┐    ┌───┐    │                 │  │ 1 │  │ 2 │      │
│  │ 4 │◀───│ 3 │    │                 │  └───┘  └───┘      │
│  └───┘    └───┘    │                 │    ▲       ▲        │
│                     │                 │    │ ┌───┐ │        │
│  Token holder = 2   │                 │    └─│ M │─┘        │
│  Only node 2 talks  │                 │      └───┘          │
│  Others wait turn   │                 │  Client polls each  │
└─────────────────────┘                 └─────────────────────┘

Peer-to-Peer vs Client/Server Communication

MODBUS PLUS — Any-to-Any               MODBUS TCP — Typical SCADA polling
┌─────────────────────┐                 ┌─────────────────────┐
│                     │                 │                     │
│  ┌───┐    ┌───┐    │                 │  ┌───┐    ┌───┐    │
│  │ 1 │◄──▶│ 2 │    │                 │  │ 1 │    │ 2 │    │
│  └─┬─┘    └─┬─┘    │                 │  └─┬─┘    └─┬─┘    │
│    │  ╲  ╱  │      │                 │    │        │      │
│    │   ╲╱   │      │                 │    ▼        ▼      │
│    │   ╱╲   │      │                 │      ┌────┐        │
│    │  ╱  ╲  │      │                 │      │ M  │        │
│  ┌─┴─┐    ┌─┴─┐    │                 │      └────┘        │
│  │ 3 │◄──▶│ 4 │    │                 │    ▲        ▲      │
│  └───┘    └───┘    │                 │    │        │      │
│                     │                 │  ┌─┴─┐    ┌─┴─┐    │
│  Any node can talk  │                 │  │ 3 │    │ 4 │    │
│  to any other node  │                 │  └───┘    └───┘    │
│  (when holding      │                 │                     │
│   the token)        │                 │  SCADA client polls │
│                     │                 │  each device        │
└─────────────────────┘                 └─────────────────────┘

Cheat Sheet

Key Parameters

Limits per the Schneider/Modicon Modbus Plus Network Planning and Installation Guide (890 USE 100 00, v6.0), the reference listed at the top of this page.

Data Model Compatibility

Modbus Plus uses the same register-based data model and function codes as Modbus RTU and Modbus TCP: the Modbus command travels inside the Modbus Plus frame (890 USE 100 00 v6.0, pp. 167-168). The difference lies in the layers beneath the Modbus messages: Modbus Plus carries them by token passing over its own shielded twisted-pair trunk, Modbus TCP over TCP/IP on Ethernet, and Modbus RTU by master-slave polling over RS-232/RS-485.

Global Database

Each Modbus Plus node can broadcast up to 32 words (64 bytes) of global data with each token pass, under the control of its own application program (890 USE 100 00 v6.0, p. 29). Every node then holds a copy of the global data the others send, without explicit polling — a capability that Modbus TCP does not have natively.

Best Practices

Document SA85 card inventory and source spares before they disappear. SA85 adapter cards are discontinued. Every installed card is a non-replaceable asset once the secondary market runs out. Catalog firmware versions, card serial numbers, and slot types (ISA vs PCI) across every system that uses Modbus Plus. Source spare cards while they are still available; pricing increases as supply shrinks.

Measure the token rotation baseline before adding nodes. Every node added lengthens token rotation, and so does the data each node sends. The planning guide’s formula adds about 0.5 ms per node for the token pass alone, plus time for global data and for busy data master paths (890 USE 100 00 v6.0, p. 75). On a 10-node network, the rotation is about 5 ms with the token alone, about 12 ms with 32 words of global data per node, and roughly 50 to 160 ms with one to four busy data master paths per node (pp. 74-75); queued transactions and remote programming stretch it further (p. 74). Before adding any node to an existing Modbus Plus network, capture a baseline token rotation time using Schneider’s diagnostic tools, estimate the rotation time after the addition, and check it against the communication timeouts configured in time-sensitive control loops.

Define migration triggers in advance, not reactively. Waiting for a failure to decide on migration is expensive: emergency decisions skip engineering review and add schedule risk. Instead, define the conditions that trigger a Modbus TCP migration before they occur: PLC replacement, network expansion beyond the current node count, SA85 card failure with no spare, or a requirement to integrate a non-Schneider device. Document these triggers in the site’s control system lifecycle plan.

Do not use Modbus Plus to justify single-vendor lock-in. If the reason a system must use Schneider hardware is “because the Modbus Plus network requires it,” that is a constraint the project inherited — not a design choice to carry forward. Make the constraint visible in project documentation so that future decisions about controller selection are informed, not defaulted.

Strengths, Weaknesses & When to Choose an Alternative

Strengths in Context

Modbus Plus was a sound engineering choice when it was introduced. Token-passing eliminated the bus contention problems that plagued early Ethernet (before switching became universal), and the peer-to-peer global database simplified PLC-to-PLC coordination without requiring a dedicated polling master. For the Schneider Quantum PLC systems it was built for, Modbus Plus provided reliable communication with a bounded response time.

Bounded response time remains a technical advantage over Modbus TCP. Token rotation gives every node a predictable wait for the token: the guide’s formula estimates the average rotation time from the number of nodes and the traffic each one sends, and it puts the worst-case response to a data request between two controllers on a single network at two rotations plus two scans of the requesting unit and one scan of the responding unit, queuing and error conditions excluded (890 USE 100 00 v6.0, pp. 74-76) — a figure for normal operation, not a communication timeout. Over TCP/IP, by contrast, latency can spike unpredictably due to retransmission, congestion, or TCP window management. In control loops where bounded response time matters more than average response time, token-passing has a structural advantage.

Weaknesses in Context

The weaknesses are consequences of Modbus Plus being a proprietary protocol in an industry that standardized on Ethernet — not protocol design flaws.

The SA85 adapter card requirement is the most immediate operational risk. For diagnostic PCs and SCADA gateways, a host network adapter such as the SA85 is the usual direct connection to a Modbus Plus network (890 USE 100 00 v6.0, p. 24); serial devices connect through a BM85 bridge multiplexer (p. 25). With Schneider no longer manufacturing the cards, every failure without a spare is a potential production stop. The secondary market exists but is shrinking.

The staffing risk compounds over time. Engineers who configured Modbus Plus networks are retiring, and the protocol is rarely taught today. Each departure reduces the available talent pool for maintenance and troubleshooting.

Comparison: Modbus Plus vs Modbus TCP vs Modbus RTU

When to Choose an Alternative

Choose Modbus TCP when: the project is a new installation, needs multi-vendor integration or remote diagnostics, or includes PLC hardware replacement. Modbus TCP provides the same register data model with commodity Ethernet hardware.

Choose DNP3 when: the site requires unsolicited event reporting, time-stamped data, or secure authentication over WAN links. DNP3 (IEEE 1815) is a widely used standard for SCADA telecontrol in utility and remote monitoring applications.

Stay on Modbus Plus when: the existing network is stable, the PLC program is complex and undocumented, and the cost of migration exceeds the operational risk of keeping the network in service. This is a risk management decision, not a technology preference.

Planning a Modbus TCP migration? See our head-to-head comparison.

Biggest Pitfalls

Network pause when a node drops out. When a node fails or leaves, the remaining nodes rebuild the token sequence without it and resume automatically; communication pauses for the node dropout latency, typically within 100 ms and calculable per node from the guide’s formula (890 USE 100 00 v6.0, pp. 28, 82-83). On Ethernet, a failed node affects only itself. On Modbus Plus, the pause is a network-wide event: size PLC communication timeouts and retries to ride through it.

SA85 card slot mismatch in modern hardware. The original SA85 cards used the ISA bus (p. 24) — a bus that disappeared from standard computers long ago. The PCI-85 adapter exists (Schneider PCI-85 User Guide 31002849, v3.0, 2009) but needs a machine with a free PCI slot. Connecting a modern laptop to a Modbus Plus network for diagnostics requires dedicated legacy hardware that may itself be difficult to source and maintain.

Confusing Modbus Plus with Modbus RTU over RS-485. Both run on twisted-pair cable, so the wire alone does not tell them apart. An SA85 or PCI-85 adapter card and the Modicon taps (990NAD23000) with their 9-pin D drop cables are the distinguishing hardware markers. The protocols are architecturally different: Plus is token-passing peer-to-peer; RTU is master-slave polling. Applying RTU troubleshooting procedures to a Plus network will produce misleading results.

Ignoring the node count limit during expansion. Adding a node to a near-full 64-node network lengthens token rotation for every existing node: by the guide’s formula, about 0.5 ms for the token pass plus the time for the new node’s own traffic (890 USE 100 00 v6.0, p. 75). Measure token rotation time before and after each node addition. If rotation time exceeds the communication timeout configured in any connected PLC, that PLC will report communication faults even though the physical network is intact.

Assuming firmware or software updates are available. Schneider has not released Modbus Plus firmware updates in years. Bugs, performance limitations, and compatibility quirks are permanent. There is no patch cycle, no security update path, and no feature roadmap. Workarounds documented in Schneider’s knowledge base are the final state.

Deep Dive

This section covers the protocol mechanics as documented in Schneider’s public technical literature. It is intended for engineers reviewing a migration plan or evaluating an existing installation.

Token-Passing Mechanics

Modbus Plus uses a delegated token protocol. When a node finishes transmitting (or has nothing to send), it passes the token to the next active node in ascending address order; the highest-addressed active node passes it back to the lowest to start a new rotation (890 USE 100 00 v6.0, p. 28). If the next node does not take the token, the passing node retries once and then falls silent; the remaining nodes detect the timeout and build a new token sequence that bypasses the missing node (pp. 30, 82).

Token recovery depends on how a node drops out:

• Planned removal: The node stops taking the token; the network rebuilds its token sequence without it, typically within 100 ms (p. 28).
• Hard failure while idle: The token pass to it fails; after one retry the remaining nodes rebuild the token sequence without it and resume, typically within 100 ms (pp. 28, 30).
• Hard failure while holding the token: The token is lost. The remaining nodes detect the silence and all try to reclaim the token; the lowest-addressed node wins and rotation restarts from the lowest address (p. 82). The pause is the node dropout latency, calculable per node from the guide’s formula (p. 83) and typically within 100 ms (p. 28).

Global Database Concept

Each Modbus Plus node can broadcast up to 32 words (64 bytes) of global data in the token frame when it passes the token; each node’s application program controls whether and when it does (p. 29). Every node keeps a table of the global data sent by every other node, so it holds a continuously updated copy — without any polling configuration.

This is architecturally different from Modbus TCP, where a client must explicitly poll each server to read its data. The global database enables PLC-to-PLC coordination without a central coordinator: each PLC reads the relevant words from other PLCs’ global data areas in its scan cycle.

The limitation is size: 32 words per node. For applications requiring more data exchange, explicit peer-to-peer messaging (read/write transactions between specific node pairs) supplements the global database.

SA85 Card Architecture

The SA85 (ISA) and its PCI counterpart, the PCI-85, bridge the Modbus Plus network to the host computer’s bus. The card contains its own processor and firmware that handles token management, global database maintenance, and message buffering independently of the host CPU. The card appears to the host operating system as a network interface that speaks Modbus Plus; Schneider’s driver software (Modbus Plus for Windows) handles the translation.

For Quantum PLC CPUs, the Modbus Plus interface is built into the CPU module itself — no separate adapter card is needed on the PLC side. An SA85 or PCI-85 card is needed only for host computers that join the network: SCADA gateways, engineering workstations, and diagnostic PCs (p. 24); serial devices join through a BM85 bridge (p. 25).

Migration Architecture Options

Three paths exist for migrating from Modbus Plus to Modbus TCP:

When the Quantum CPU hardware is still supported, the NOE module path trades a planned PLC outage for a direct Ethernet connection with no translation layer. The gateway path is the least disruptive, but it keeps the Plus network and adds a translation layer (and its latency); treat the gateway as a single point of failure until a redundant arrangement is designed. Full replacement is the clean-sheet approach — typically triggered by CPU end-of-life or a strategic decision to move away from Schneider. Whichever path you take, moving PLC traffic from a non-IP bus onto Ethernet makes segmenting the new Modbus TCP network part of the migration scope: IEC 62443 zones and conduits, the same model used elsewhere on this site.

Hot-standby pairs are a migration-scope item. On Modbus Plus a redundant controller pair holds two node addresses, offset by 32, and a primary-to-standby transfer makes the two controllers swap addresses, leave the network and rejoin it; the guide puts the worst case for the ring to re-form at up to 15 s and expects the node applications to ride it out with retries (890 USE 100 00 v6.0, pp. 20, 90). Any migration path has to reproduce that pair’s behaviour on the Ethernet side, and the Modbus Plus guide says nothing about how an NOE module or a gateway behaves during a transfer: that is a question for the controller’s own hot-standby documentation.