Modbus TCP vs Modbus Plus

Modbus Plus is no longer manufactured. This comparison 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.

When to Choose Modbus TCP

Modbus TCP is the standard choice for new work. Modbus Plus carries Modbus commands inside its own frames, so the register model and function codes carry over (890 USE 100 00 v6.0, pp. 167-168). Modbus TCP runs on standard Ethernet hardware that costs less than proprietary Plus infrastructure.

Project characteristics that favor Modbus TCP:

• Any greenfield project — this is non-negotiable. Modbus Plus hardware is end-of-life. Specifying SA85 adapter cards for a new installation creates an immediate spare parts liability and locks the project into a shrinking vendor ecosystem. Schneider’s own current-generation controllers (M340, M580) use Ethernet natively.
• Existing site where a PLC replacement or expansion is already planned — if the capital budget includes new Quantum or M580 controllers, adding Modbus TCP at replacement time adds little hardware cost; the program update and re-commissioning ride on work the replacement already requires. Most current Schneider PLCs include an Ethernet port on the CPU module or accept an NOE Ethernet module in a standard slot.
• Multi-vendor integration required — non-Schneider Modbus and serial devices reach a Modbus Plus network only through a BM85 bridge multiplexer or another gateway (890 USE 100 00 v6.0, pp. 13, 25), and PCs through a host adapter such as the SA85 (p. 24). Modbus TCP works with any device from any vendor that implements the Modbus register standard, as a wide range of industrial devices do.
• Remote diagnostics or network monitoring — Wireshark captures, mbpoll command-line tests, and any standard SCADA platform work natively with Modbus TCP. Diagnosing a Modbus Plus issue requires Schneider’s proprietary tools (Concept, ProWORX NXT, Unity) and a Modbus Plus host adapter (the SA85 or the later PCI-85) — neither of which may be available when you need them.
• Integration with IT infrastructure — Modbus TCP traffic travels on standard Ethernet and can be segmented, firewalled, and monitored with conventional IT network tools. Modbus Plus runs on a physically separate bus that IT teams cannot observe or manage with their existing tooling.

The strongest TCP case: A data center expanding from 2 to 4 PLCs, where the new controllers are Schneider M580 units with built-in Ethernet. Modbus TCP is available natively. Extending the Modbus Plus network to them would mean connecting controllers built for Ethernet to the Plus bus, installing dedicated Plus cabling, and finding an engineer who can configure a token-passing network — all for a protocol with no future.

When to Stay on Modbus Plus

Staying on Modbus Plus is not a design choice for new work — it is a risk management decision for existing infrastructure where the cost of migration exceeds the operational risk of keeping it in service. For the prime contractor, the call matters once project scope touches a Plus network: staying or migrating sets the outage windows and the re-commissioning scope inside the prime’s schedule.

Conditions where staying on Plus is defensible:

• Existing stable network with no expansion plans — if the Modbus Plus network has been running reliably for years, the PLC programs are complex and well-tested, and no new nodes or devices are being added, the risk of disrupting a working system outweighs the risk of continued operation on legacy hardware.
• SA85 adapter cards are operational and spares are in inventory — the primary operational risk of Modbus Plus is SA85 card failure with no replacement available. If spares are secured and inventoried, this risk is managed for the near term.
• PLC program is complex and undocumented — migrating the communication layer requires updating the PLC program to use Modbus TCP function blocks instead of Plus communication blocks. If the existing program is complex, undocumented, and has not been modified in years, the re-engineering and re-commissioning risk may exceed the infrastructure risk of staying on Plus.
• Owner’s capital program has no PLC refresh planned — if the hardware is not being replaced on any foreseeable timeline and the system is stable, the migration cost has no natural absorption point. Forcing a migration purely for protocol modernization is difficult to justify to a capital review board.

The strongest Plus case: A 15-year-old Modicon Quantum system controlling generator switchgear in a data center, running a PLC program with 40 function blocks and no current documentation. The system works, the Plus network is stable, SA85 spares are on the shelf, and the next capital refresh is not planned for 3+ years. Migrating this system requires full re-commissioning of the generator control and transfer sequences and their interlocks — a high-risk, high-cost exercise that no one is asking for. The right answer: keep it running, monitor SA85 card health, and trigger migration when the next maintenance outage or hardware replacement creates a natural window.

What this means for PMs: If a sub proposes Modbus Plus for any new scope, it is not a defensible design decision unless it sits inside a documented migration path to Modbus TCP. “Stay on Plus” applies only to existing infrastructure where migration risk is actively managed.

Cost Analysis

The cost comparison between Modbus TCP and staying on Modbus Plus depends on whether the work is greenfield, a migration triggered by hardware replacement, or a migration forced on a stable system.

Cost conclusion: Staying on Modbus Plus has the lowest immediate cost. Modbus TCP migration at PLC-replacement time adds little hardware cost (the Ethernet port comes with the new CPU), and its program update and re-commissioning ride on work the replacement already requires. Forced migration of a stable system is the most expensive path because it includes re-commissioning cost that would otherwise be deferred to the natural hardware lifecycle. The economic argument for proactive migration is long-term risk reduction, not immediate savings.

Risk Comparison

Modbus TCP Risks (After Migration)

Modbus Plus Risks (Continued Operation)

Net Risk Assessment

For existing stable Modbus Plus networks with spares available, the short-term risk profile slightly favors staying on Plus: the system is proven, the failure modes are known, and migration itself introduces transition risk. However, over a longer horizon, the compounding risks of SA85 hardware scarcity, a shrinking talent pool, and vendor abandonment make Modbus Plus the higher-risk position. The tipping point comes sooner if any SA85 card fails without replacement or if a non-Schneider integration requirement surfaces.

Common Misconceptions

“Modbus Plus is just Modbus with a faster serial bus”

Reality: The name “Modbus Plus” implies an upgraded Modbus, but the architecture is fundamentally different. Modbus RTU is a master-slave polling protocol and Modbus TCP a client/server one — one device asks, another answers. Modbus Plus is a token-passing peer-to-peer network where any device can initiate communication with any other device, and each node can broadcast up to 32 words of global data to all the others with each token pass, under its application’s control (890 USE 100 00 v6.0, p. 29). The only shared elements are the register data model and function codes. The access method, hardware requirements, and failure modes are different.

“Migrating from Plus to TCP is just a software change”

Reality: The migration requires hardware changes. Each Quantum PLC that currently communicates via its built-in Modbus Plus port needs either an NOE Ethernet module installed in an available slot or a complete CPU replacement with an Ethernet-equipped model. The PLC program must be updated to replace Modbus Plus communication function blocks with Modbus TCP equivalents. Gateway devices are an alternative for systems where PLC modification is not feasible, but they add a translation layer with its own latency and failure mode. “Firmware update” or “software reconfiguration” alone cannot convert a Plus network to TCP.

“Modbus TCP is less reliable because it’s over IP”

Reality: Both deliver reliably, by different means. TCP detects a lost segment and retransmits it automatically. Modbus Plus acknowledges each data message at once and, with no acknowledgment, retries up to twice before raising an error the application program can read (890 USE 100 00 v6.0, pp. 29-30). The tradeoff is determinism (Plus bounds each node’s token holding time on one network; TCP does not), not reliability.

Red Flags in Proposals

When a sub proposes Modbus Plus for new work

“The Quantum PLC requires Modbus Plus.” A Quantum PLC can communicate via Modbus TCP with an NOE module — it does not require Modbus Plus. This claim usually traces to an older design template; check it against the controller’s current options.

No migration path in the design documentation. Any Modbus Plus scope, even for maintaining an existing network, should include a documented migration path to Modbus TCP as part of the lifecycle plan. For each outage, that means a method of procedure with a back-out plan, a register cross-reference from each Plus address to its TCP equivalent, and test procedures with expected results. A design that deploys or maintains Plus infrastructure with no migration path creates a liability that the owner will eventually pay for.

SA85 card pricing not disclosed. SA85 cards on the secondary market can command significant premiums due to scarcity. If the proposal includes SA85 cards, it should price them transparently and acknowledge the supply risk. A proposal that omits this leaves the supply risk unpriced.

When a sub proposes a Modbus Plus-to-TCP migration

“We’ll migrate all nodes in a single outage.” A full Modbus Plus-to-TCP migration on a complex Quantum system is a multi-outage project. Each PLC needs an NOE module installed, its program updated, and its communication verified against every connected device. Attempting a full cutover in a single outage increases the risk of discovering issues under time pressure — exactly the scenario that causes commissioning schedule overruns.

No re-commissioning scope for affected control loops. Changing the communication layer between PLCs and their connected devices requires re-verifying every control loop, interlock, and alarm that depends on the migrated communication path. A migration scope that does not include loop-by-loop re-commissioning is incomplete. The register data is the same, but the timing, error handling, and failure modes are different. The PLC program may also have been written with Plus-specific assumptions about communication behavior.

“We’ll use a gateway — no PLC changes needed.” Gateways are a valid migration tool, but they are not invisible. A gateway adds a protocol translation hop (with latency), introduces a new single point of failure, requires its own configuration and maintenance, and must be monitored for health. A sub that presents a gateway as a zero-disruption solution with no operational impact is underestimating the integration effort.

Technical Deep Dive

This section is for engineers reviewing the PM’s decision or validating a sub’s migration approach.

Token-Passing vs Polling: The Architectural Difference

Modbus TCP polling works on a request-response cycle: the client sends a request (e.g., “read registers 40001-40010”), and the server responds with the data. A client that scans its servers in sequence waits on each reply, so its scan cycle is the sum of the poll times plus network overhead, and a slow device delays the whole scan. Over TCP a client can instead hold a connection to each device and keep several requests outstanding (Modbus Messaging on TCP/IP Implementation Guide V1.0b, §4.2.1.1), but each device still answers only when asked.

Modbus Plus works on a token-passing (turn-taking) model: each node gets a turn to transmit, regardless of what other nodes are doing. When a node holds the token, it can send its global database broadcast and any pending peer-to-peer messages. The planning guide estimates the average token rotation time from the number of nodes and the traffic each one sends, and from it the response time of a data request from one controller to another on a single network (its MSTR transaction): on average one rotation, one scan of the requesting unit and half a scan of the responding unit; at worst two rotations, two scans of the requesting unit and one scan of the responding unit. That estimate excludes queuing and error conditions, and the rotation itself lengthens when a node holds the token for queued transactions or remote programming (890 USE 100 00 v6.0, pp. 74-76) — so it sizes normal operation, not a communication timeout. A predictable worst case in normal operation is what polling over TCP cannot offer; but the whole network shares a fixed 1 Mbps, whatever the traffic pattern.

SA85 Card Architecture

The SA85 card is not a simple serial adapter. It contains its own dedicated processor and firmware that manages token acquisition, global database maintenance, peer-to-peer message buffering, and network health monitoring independently of the host CPU. When the host application writes data to the SA85’s buffer, the card handles all timing-sensitive operations — the host does not participate in token management.

This architecture means the SA85 card’s firmware version matters for compatibility. Different firmware versions support different global database sizes, peer-to-peer message lengths, and diagnostic capabilities. When sourcing SA85 cards from the secondary market, verify the firmware version against the existing cards in the network to avoid compatibility issues.

NOE Module Migration Path

The Schneider NOE 771-xx Ethernet modules (10/100 Mbps) plug into available slots in the Quantum PLC backplane. Once a module is installed, the PLC can communicate via Modbus TCP without any changes to the existing Modbus Plus network — the two protocols can coexist on the same PLC, with the PLC program reading from Plus and writing to TCP (or vice versa) during a staged migration.

Migration sequence for a staged NOE approach:

1. Install the NOE module in an available Quantum backplane slot (requires brief PLC power-down)
2. Configure the NOE module’s IP address, subnet, and gateway
3. Update the PLC program to add Modbus TCP communication function blocks alongside existing Plus blocks
4. Verify Modbus TCP communication with the SCADA gateway using both protocols in parallel
5. Migrate connected devices one at a time from Plus to TCP, verifying each device’s register map
6. After all devices are on TCP, remove the Plus communication blocks from the PLC program
7. The Plus network can remain physically connected as a fallback during the transition period

This staged approach allows verification at each step and provides a rollback path (re-enable Plus blocks) if issues arise. Where a redundant (hot-standby) controller pair is in scope, note that on Modbus Plus a primary-to-standby transfer makes the two controllers swap node addresses and rejoin the network, with a worst case of up to 15 s for the ring to re-form (890 USE 100 00 v6.0, pp. 20, 90); the migration plan must reproduce the pair’s behaviour on the Ethernet side and re-test the switchover.

When to Use a Gateway vs Hardware Replacement

Decision rule: If the PLC can accept an NOE module and the program can be updated, use the NOE approach; it removes the Plus dependency once every node on the network, I/O drops and bridged devices included, has moved to TCP. Use a gateway only when PLC modification is not possible, and plan to replace the gateway with a direct TCP connection at the next PLC hardware refresh.