Modbus TCP vs Modbus Plus

When to Choose Modbus TCP

Modbus TCP is the standard choice whenever the question is about new work. The register model is identical to Modbus Plus — same function codes, same data types, same addressing concepts — on standard Ethernet hardware that costs a fraction of 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 already includes new Quantum or M580 controllers, adding Modbus TCP at replacement time costs almost nothing extra. 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 — Modbus Plus cannot communicate with non-Schneider devices without an SA85 adapter card on the foreign device’s side (or a protocol gateway). Modbus TCP works with any device from any vendor that implements the Modbus register standard — which is nearly every industrial device manufactured today.
• 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 an SA85 card — 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 exists 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. Adding a Modbus Plus segment would require sourcing discontinued SA85 cards, installing dedicated Plus cabling, and finding an engineer who can configure a token ring 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 continued operation.

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, poorly documented, 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 protection scheme — a high-risk, high-cost exercise that no one is asking for. The right answer is: keep it running, monitor SA85 card health, and trigger migration when the next maintenance outage or hardware replacement creates a natural window.

Key framing for PMs: If a sub proposes Modbus Plus for any new scope, it is not a defensible design decision. “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 migration is greenfield, triggered by hardware replacement, or forced on a stable system.

Cost conclusion: Staying on Modbus Plus has the lowest immediate cost. Modbus TCP migration at PLC-replacement time has near-zero incremental cost — the Ethernet port is already on the new CPU. 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, on any time horizon beyond 3-5 years, the compounding risks of SA85 hardware scarcity, shrinking talent pool, and vendor abandonment make Modbus Plus the higher-risk position. The tipping point accelerates 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 and TCP are master-slave polling protocols — 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 every device broadcasts a global data area to all others automatically. The only shared element is the register data model and function codes. The network topology, access method, hardware requirements, and failure modes are completely 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: TCP provides guaranteed delivery with retransmission and acknowledgment. If a TCP packet is lost, the protocol detects the loss and retransmits automatically. Modbus Plus token-passing has no retransmission mechanism — if a message is corrupted during transmission, it is simply lost. The receiving node may detect the corruption via the error check, but the sending node has no way to know the message failed unless the application layer implements its own acknowledgment scheme. TCP’s reliability mechanisms are structurally stronger than token-passing’s fire-and-forget approach. The tradeoff is determinism (Plus has bounded latency; TCP does not), not reliability.

Red Flags in Proposals

When a sub proposes Modbus Plus for new work

“The Quantum PLC requires Modbus Plus.” Schneider Quantum CPUs have had built-in Ethernet ports or NOE Ethernet module options since the mid-2000s. A Quantum PLC can communicate via Modbus TCP with an NOE module — it does not require Modbus Plus. This claim signals an outdated design template being applied without review, or unfamiliarity with current Schneider hardware capabilities.

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. A design that deploys or maintains Plus infrastructure with no exit strategy creates a future 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, the pricing should be transparent and the supply risk should be acknowledged. A sub that omits this information may not be aware of the current market reality.

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 — and the PLC program may 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. If the sub presents a gateway as a zero-disruption solution with no operational impact, they are 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 master sends a request (e.g., “read registers 40001-40010”), and the slave responds with the data. If the slave is slow, the master waits. If there are 20 slaves, the master polls them sequentially (or in a configured scan order), and the total scan cycle time is the sum of all individual poll times plus network overhead. A slow device delays the entire scan.

Modbus Plus token-passing works on a time-division 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 maximum time any node waits for the token is bounded by the number of active nodes times the maximum hold time per node. This gives a worst-case guarantee that polling cannot provide — but it also means the average throughput is lower than TCP’s burst capability, and the total bandwidth is fixed at 1 Mbps regardless of 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, firmware version must be verified 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 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.

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 eliminates the Plus dependency entirely. 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.