Skip to main content
All Protocols
Tier 4 fieldbus

Modbus Plus

Modbus Plus Network Planning and Installation Guide (Schneider Electric)

Top 7 Key Ideas

  1. Token-passing, not master-slave — every node gets a turn to transmit, eliminating bus contention
  2. Peer-to-peer by design — any node can initiate a transaction with any other node, no polling master required
  3. Global database — each node maintains a shared memory table that all other nodes can read
  4. SA85 adapter card required — communicating from a PC requires proprietary Schneider hardware (end-of-life)
  5. 1 Mbps, 64 nodes per segment, 450m per segment — fixed parameters, no tuning
  6. Schneider/Modicon ecosystem only — not compatible with devices outside the Schneider product line
  7. Migration target is Modbus TCP — same register model and function codes, different transport and hardware

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 the Modbus TCP systems that replace it.

ELI5

Imagine a meeting where only one person can talk at a time. Instead of a boss deciding who speaks (that’s 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 from the late 1980s. 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 is the internal nervous system of the PLC network — transparent 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 almost certainly 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 is larger than most PMs expect because it includes hardware changes, not just configuration.

Red flag from a sub: If a subcontractor proposes Modbus Plus hardware (SA85 adapter cards, Plus network segments) for new work, this signals either a very old design template being applied without review or unfamiliarity with current Schneider hardware. Quantum CPUs have had built-in Ethernet ports or NOE module options since the mid-2000s. There is no technical reason to start a new Modbus Plus segment today.

Visual Explanation

Token-Passing Ring vs Polling Star

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

Peer-to-Peer vs Master-Slave Communication

MODBUS PLUS — Any-to-Any               MODBUS TCP — All Through Master
┌─────────────────────┐                 ┌─────────────────────┐
│                     │                 │                     │
│  ┌───┐    ┌───┐    │                 │  ┌───┐    ┌───┐    │
│  │ 1 │◄──▶│ 2 │    │                 │  │ 1 │    │ 2 │    │
│  └─┬─┘    └─┬─┘    │                 │  └─┬─┘    └─┬─┘    │
│    │  ╲  ╱  │      │                 │    │        │      │
│    │   ╲╱   │      │                 │    ▼        ▼      │
│    │   ╱╲   │      │                 │      ┌────┐        │
│    │  ╱  ╲  │      │                 │      │ M  │        │
│  ┌─┴─┐    ┌─┴─┐    │                 │      └────┘        │
│  │ 3 │◄──▶│ 4 │    │                 │    ▲        ▲      │
│  └───┘    └───┘    │                 │    │        │      │
│                     │                 │  ┌─┴─┐    ┌─┴─┐    │
│  Any node can talk  │                 │  │ 3 │    │ 4 │    │
│  to any other node  │                 │  └───┘    └───┘    │
│  (when holding      │                 │                     │
│   the token)        │                 │  All traffic routes  │
│                     │                 │  through the master  │
└─────────────────────┘                 └─────────────────────┘

Cheat Sheet

Key Parameters

ParameterValue
Physical layerRS-485 (Schneider custom implementation)
Speed1 Mbps (fixed)
Max nodes per segment64
Max segments64 (with repeaters)
Max cable length per segment450m (without repeaters)
TopologyToken-passing bus
TransportProprietary — no IP
AddressingNode number 1-64 per segment
Required adapter (PC access)SA85 ISA card or SA85 PCI card
Cable specificationBelden 9841 shielded twisted pair
Connector typeModicon tap connector (blue housing)
Termination330 ohm terminator at each end of bus

Data Model Compatibility

Modbus Plus shares the same register-based data model and function codes as Modbus RTU and Modbus TCP. The data layer is identical — FC01 through FC16 apply. The difference is entirely in the transport layer: Plus uses token-passing over RS-485, while TCP uses polling over Ethernet, and RTU uses master-slave over RS-232/RS-485.

Global Database

Each Modbus Plus node maintains a 32-word (64-byte) global data area that is broadcast to all other nodes automatically during the token pass. This means every node can read any other node’s status 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 token rotation baseline before adding nodes. Token ring performance degrades non-linearly as node count approaches the segment limit. Before adding any node to an existing Modbus Plus segment, capture a baseline token rotation time using Schneider’s diagnostic tools. A healthy 10-node network typically shows token rotation under 5ms. If the network is already above 10ms per rotation, adding nodes will push it further and may cause communication timeouts 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 current node count, SA85 card failure with no spare, or integration requirement with a non-Schneider device. Document these triggers in the site’s control system lifecycle plan.

Do not use Modbus Plus as justification for 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 eliminates 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 Schneider Quantum PLC systems installed in the 1990s and 2000s, Modbus Plus provided reliable, deterministic communication that ran for decades without intervention.

The determinism guarantee remains a genuine technical advantage over Modbus TCP. Token rotation gives every node a bounded worst-case response time — the maximum delay before any node can transmit is calculable from the node count and token rotation period. TCP/IP, by contrast, can spike latency 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 not protocol design flaws — they are consequences of Modbus Plus being a proprietary protocol in an industry that standardized on Ethernet.

The SA85 adapter card requirement is the most immediate operational risk. These cards are the only way to connect non-Modicon devices (including diagnostic PCs and SCADA gateways) to a Modbus Plus network. With Schneider no longer manufacturing them, every failure without a spare is a potential production stop. The secondary market exists but shrinks annually.

The staffing risk compounds over time. Engineers who configured Modbus Plus networks in the 1990s and 2000s are retiring. The protocol is not taught in current industrial networking curricula, and no certification programs exist. Each departure reduces the available talent pool for maintenance and troubleshooting.

Comparison: Modbus Plus vs Modbus TCP vs Modbus RTU

DimensionModbus PlusModbus TCPModbus RTU
TransportToken-passing (RS-485)TCP/IP (Ethernet)Master-slave (RS-232/RS-485)
TopologyBus/ringStar (through switches)Daisy-chain or star
Peer-to-peerYes (native)No (master-slave)No (master-slave)
DeterminismBounded (token rotation)Non-deterministic (TCP)Bounded (by poll cycle)
Speed1 Mbps100 Mbps+9600 bps - 115200 bps
Max devices64 per segmentLimited by switch ports247 per network
ToolingSchneider-proprietaryWireshark, mbpoll, open-sourceWireshark, ModRSsim2
Vendor lock-inSchneider onlyAny vendorAny vendor
Greenfield viability (2026)No — hardware EOLYesLimited — serial declining

When to Choose an Alternative

Choose Modbus TCP when: any new installation, multi-vendor integration, remote diagnostics, or when the project includes PLC hardware replacement. 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 is the 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 continued operation. This is a risk management decision, not a technology preference.

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

Biggest Pitfalls

Token ring stall from a failed node. If a node fails without cleanly releasing the token, the ring stalls. All communication stops until the failed node is physically disconnected or powered down. This is Modbus Plus’s most dangerous failure mode — a single card failure can take down the entire PLC communication network. Unlike Ethernet (where a failed node only affects itself), a token ring failure is a network-wide event.

SA85 card slot conflict in modern hardware. The original SA85 cards were ISA bus — a form factor that has not existed in standard computers for over 15 years. PCI variants exist but require older hardware with available PCI slots. 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 protocols use RS-485 physical wiring, so cable inspection alone does not distinguish them. The presence of an SA85 adapter card and the blue Modicon tap connectors 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 segment degrades token rotation time for every existing node. The degradation is not linear — it accelerates as the segment fills. 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 logical node number. The token circulates continuously around the configured node addresses. If a node does not respond to the token pass within the configured timeout, the passing node skips it and offers the token to the next address.

Token recovery after a node failure depends on the failure mode:

  • Clean shutdown: The node passes the token before going offline. No disruption.
  • Hard failure during idle: The token-passing node detects no response and skips to the next address. Brief pause (one timeout period), then normal operation resumes.
  • Hard failure while holding the token: The token is lost. All nodes detect the absence of traffic and enter a “claim token” procedure where the lowest-numbered active node regenerates the token. This causes a network-wide pause that can last several hundred milliseconds.

Global Database Concept

Each Modbus Plus node maintains a 32-word (64-byte) global data area in its local memory. During each token pass, the token-holding node broadcasts its global data to all other nodes on the segment. This means every node has a continuously updated copy of every other node’s global data — without any polling configuration.

This is architecturally different from Modbus TCP, where a master must explicitly poll each device 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 card is a protocol bridge between the Modbus Plus physical layer and the host system’s bus (ISA or PCI). It 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, or the PLC CPU’s built-in interface) 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. The SA85 card is only required for non-Quantum devices that need to participate in the Modbus Plus network (typically SCADA gateways, engineering workstations, and diagnostic PCs).

Migration Architecture Options

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

PathDescriptionDisruptionCostWhen to Use
NOE moduleAdd a Schneider NOE 771-xx Ethernet module to each Quantum PLC. Register maps stay identical — only the transport changes.Medium — requires PLC downtime for module installation and program updateLow-medium — NOE modules are standard Schneider partsCPU has an available slot and the PLC program can be updated
Protocol gatewayInstall a Modbus Plus-to-TCP gateway device. The Plus network continues operating; the gateway translates between Plus and TCP at the boundary.Low — gateway connects to existing Plus network without modifying PLCsMedium — gateway hardware plus configurationPLCs cannot be modified (locked program, no available slots, or regulatory freeze)
Full controller replacementReplace Quantum PLCs with Schneider M340/M580 or another vendor’s controller. New controllers use Ethernet natively.High — full re-commissioning of every control loopHigh — new hardware, new programming, new commissioningEnd-of-life CPUs, or migration to a different vendor

The NOE module path is the lowest-risk option when the Quantum CPU hardware is still supported. The gateway path preserves the existing PLC infrastructure at the cost of adding a translation layer (and its latency). Full replacement is the clean-sheet approach — typically triggered by CPU end-of-life or a strategic decision to move away from Schneider.

Need Help With Modbus+?

Our team has field-proven experience with this protocol.
Let's discuss your project requirements.

Book a Scoping Call