Modbus TCP vs EtherNet/IP: Differences & Selection

Modbus TCP is usually the simpler choice for explicit register exchange across mixed equipment. EtherNet/IP is usually the stronger choice when the controller and devices need a native CIP object model, cyclic I/O connections, device profiles and richer connection diagnostics. Neither protocol is universally faster or cheaper. Select from the exact endpoints, data contract, timing deadline, failure response, engineering support and evidence from a representative test.

That is the direct answer. The practical decision is not “which protocol wins?” but “which protocol exposes the required data and behavior with the least lifecycle risk on this machine?”

Review boundary — 25 July 2026: this guide was checked against the Modbus Organization’s application and TCP messaging specifications, ODVA’s EtherNet/IP technology and specification material, IANA’s service registry, and NIST industrial-control security guidance. Product firmware, connection limits, EDS behavior, secure-profile support and vendor instructions vary. Confirm every implementation detail against the exact devices and revisions in your bill of materials.

Modbus TCP vs EtherNet/IP at a glance

Choose Modbus TCP first when

• The required variables already have a clear, versioned register map.
• The exchange is supervisory or sequence-level rather than tightly coupled I/O.
• The controller needs to read meters, instruments or third-party devices with simple function-code support.
• Mixed-vendor access and transparent packet inspection matter more than a rich device profile.
• The team can own polling, data quality, scaling, timeout and retry behavior explicitly.

Choose EtherNet/IP first when

• The target devices expose native CIP I/O assemblies or supported device profiles.
• Cyclic I/O connections fit the control role and are supported by both endpoints.
• The engineering tool can import the correct EDS or vendor integration profile and expose useful connection diagnostics.
• The installed base, maintenance skills, spares and commissioning tools are already built around CIP.
• The application needs a CIP distinctive service, such as CIP Safety, CIP Sync or CIP Motion, and every required product and design element supports that service.

Keep both when

A brownfield plant often has a sound reason to keep Modbus TCP instruments and EtherNet/IP machine I/O. A gateway or dual-protocol controller can join them, but the translation boundary must be engineered and tested. It does not make one device native to the other protocol.

The architecture difference that matters

Both protocols can run on Ethernet and IP networks. That shared infrastructure does not make their application behavior equivalent.

How Modbus TCP sends a request

Modbus TCP places a Modbus Protocol Data Unit behind a seven-byte MBAP header:

The Modbus TCP messaging implementation guide defines the client/server model and MBAP structure. The separate Modbus application protocol specification defines public function codes, data access and exception responses.

Common function codes include:

• 01 read coils
• 02 read discrete inputs
• 03 read holding registers
• 04 read input registers
• 05 write one coil
• 06 write one holding register
• 15 write multiple coils
• 16 write multiple holding registers
• 23 read/write multiple registers
• 43/14 read device identification, when implemented

The IANA service registry assigns TCP port 502 to the Modbus Application Protocol. A registered port is not a reason to open broad firewall access; allow only the required peers and direction.

The Modbus addressing trap

The PDU addresses data from zero. Human-facing documentation often uses references such as 40001, while a driver may ask for address 0, 1 or 40001 depending on its notation. Before commissioning, record all three:

Do not infer data type from a 4xxxx label alone. A holding register is 16 bits. A 32-bit integer, IEEE 754 value or string spans multiple registers, and multi-register word order is a device convention that must be documented and tested. Units, scale, validity and write permissions are also device- or project-specific.

How EtherNet/IP sends data

EtherNet/IP adapts the Common Industrial Protocol (CIP) to standard Ethernet, IP, TCP and UDP. CIP models data and behavior as objects:

• Class: the object type
• Instance: one occurrence of that class
• Attribute: data associated with the instance
• Service: an operation requested of the object

ODVA’s EtherNet/IP technology overview describes two important communication paths:

1. Explicit messaging uses request/response transactions for configuration, diagnostics and general data access. EtherNet/IP uses TCP resources for these messages.
2. Implicit I/O messaging moves application-specific I/O at regular intervals over UDP after a connection has been established. Connections may be unicast or multicast depending on the devices and configuration.

IANA registers 44818 for EtherNet/IP messaging and 2222 for EtherNet/IP I/O. Actual firewall rules must follow the implemented connection and vendor documentation rather than a copied “open these ports everywhere” list.

Explicit is not implicit

This distinction causes many bad comparisons:

An EtherNet/IP Requested Packet Interval (RPI) is a configuration parameter for a connection. It is not proof that the process sees a guaranteed end-to-end response at that number. Controller task scheduling, device production, switch behavior, application logic and actuator response all contribute. Conversely, one slow Modbus implementation does not prove that Modbus TCP always has that latency. Measure the complete application path.

Data model and engineering workflow

Modbus TCP: small model, larger project contract

The Modbus model is compact, but the project must supply the semantics. A usable register schedule includes:

If a vendor manual only lists “register 27 = speed,” the integration is not finished. You still need units, scale, signedness, byte/word order, writable states, update behavior and timeout handling.

EtherNet/IP: richer model, exact implementation still matters

CIP device profiles can standardize objects and behavior for a device type. An EDS can describe device identity, parameters and connection information. That is valuable evidence, not a guarantee that any scanner, engineering tool and firmware combination will behave identically.

For each endpoint, capture:

• Vendor, catalog number, firmware and device revision
• ODVA declaration or conformance evidence when available
• EDS revision and checksum
• Supported device profile and optional objects
• Input, output and configuration assembly instances
• Exact byte length, member order, padding and data types
• Supported connection type and RPI limits
• Multicast or unicast behavior
• Connection count and packet-size limits
• General and extended status handling
• Replacement and recovery procedure

ODVA publishes EtherNet/IP interoperability test procedures, including EDS verification, network interoperability, I/O adapter, explicit-message and scanner tests. Product-specific acceptance testing remains necessary because your topology and application are not the conformance laboratory.

A worked PLC command and response contract

The cleanest way to compare protocols is to make them carry the same application contract. This example sends a command and scaled setpoint from a line controller to a skid controller, then returns an explicit result.

Common data contract

Modbus mapping

Map the fields to one contiguous block, for example holding-register offsets 0…7 corresponding to display references 40001…40008. The line PLC can read the whole block with function 03. If the skid accepts writes, use a supported multi-register operation rather than many unrelated single writes.

A robust command sequence is:

1. Confirm that the previous CommandSeq has been echoed in ResponseSeq.
2. Write CommandCode and SetpointRaw.
3. Write Control and a new CommandSeq as the final publication step, using a device-supported method.
4. Poll the response block on the documented schedule.
5. Accept a response only when ResponseSeq equals the issued CommandSeq.
6. Time out to a defined fault state if the heartbeat or matching response stops.

Do not assume a remote application takes an atomic snapshot of several registers. If atomicity is required, confirm the server behavior or add an application mechanism such as a publish sequence that is written last and checked before and after copying the payload.

EtherNet/IP assembly mapping

For implicit I/O, place the same members in the produced and consumed assemblies. Confirm assembly instance numbers, member offsets, padding and byte order from the EDS and device manual. The connection transports the latest assembly; the sequence fields preserve application-level command identity across repeated packets.

For explicit messaging, map the fields to supported attributes or symbolic items and preserve the same ownership, sequence and timeout rules. Do not replace a cyclic assembly with many explicit writes merely because the engineering software makes the message instruction easy to insert.

Vendor-neutral Structured Text consumer

HeartbeatChanged := RxHeartbeat <> LastHeartbeat;

IF HeartbeatChanged THEN
    LastHeartbeat := RxHeartbeat;
END_IF;

HeartbeatWatchdog(IN := NOT HeartbeatChanged, PT := T#2s);
CommHealthy := NOT HeartbeatWatchdog.Q;

IF CommHealthy AND (RxCommandSeq <> LastCommandSeq) THEN
    IF (RxCommandCode = 1) AND
       (RxSetpointRaw >= 0) AND
       (RxSetpointRaw <= MaxSetpointRaw) AND
       AllPermissives THEN
        LatchedSetpointRaw := RxSetpointRaw;
        StartBatchRequest := TRUE;
        TxResponseStatus := 1; // accepted
    ELSIF NOT AllPermissives THEN
        TxResponseStatus := 16#8002; // interlock
    ELSE
        TxResponseStatus := 16#8001; // invalid command/range
    END_IF;

    TxResponseSeq := RxCommandSeq;
    LastCommandSeq := RxCommandSeq;
END_IF;

IF NOT CommHealthy THEN
    StartBatchRequest := FALSE;
    CommunicationFault := TRUE;
END_IF;

This is an application pattern, not drop-in production code. Choose watchdog times from the process hazard and measured network behavior. Safety functions require their own validated architecture; a standard Modbus TCP or base EtherNet/IP connection is not a safety function.

Practice boundary and ownership disclosure

PLC Simulation Software can help you practise the sequence-ID, watchdog, state-machine and fault-recovery logic used in this example. It does not emulate every Modbus TCP server, CIP object, EtherNet/IP scanner/adapter, EDS import or target-controller firmware behavior. PLC Programming IO and PLC Simulation Software have the same publisher, so the training placement below is both editorial and commercial.

Which protocol is faster?

There is no defensible universal number. Published “2 ms versus 20 ms” tables collapse different tests into one false answer.

Performance depends on:

• Controller communication task and scan scheduling
• Endpoint CPU, firmware and connection limits
• Payload size and grouping
• Number of peers and simultaneous requests/connections
• Poll schedule or RPI
• Switch topology, queueing, multicast configuration and background traffic
• TCP retry and timeout behavior
• Application copy and processing time
• Fault, reconnection and replacement behavior

The Modbus Organization’s FAQ explicitly notes that Modbus TCP performance depends on the network and hardware. ODVA publishes a performance test methodology for EtherNet/IP devices that includes cyclic/API jitter and loaded conditions. Apply the same evidence discipline to the complete application.

A reproducible benchmark method

1. Write the requirement first. Example: “status change must be visible to the receiving PLC task within 50 ms at the 99.9th percentile, and communication loss must be declared within 500 ms.”
2. Match the application payload. Use the same fields, types, direction and producer/consumer work for both tests.
3. Hold the hardware constant where possible. Same controllers or equivalent performance class, firmware, switch path, link speed, cable and power conditions.
4. Hold controller load constant. Record task periods, maximum scan, communication utilization and CPU state.
5. Warm up the connections. Exclude startup unless startup is the result under test.
6. Timestamp at the application boundary. Use sequence IDs and a common time base or measure round-trip echo without pretending it is one-way latency.
7. Run enough samples. Record every sequence over a declared duration and sample count; do not publish only an average.
8. Repeat under documented load. Add a controlled amount of background traffic and the expected number of devices/connections.
9. Test faults. Cable removal, switch restart, target restart, controller mode change and gateway restart often matter more than steady-state speed.
10. Publish raw data and configuration. Include packet size, poll interval/RPI, timeouts, firmware, topology, switch settings and exclusions.

Report:

• Median, p95, p99 and worst observed application latency
• Jitter distribution
• Missed, duplicated or out-of-order application sequences
• Timeout and reconnect distribution
• Controller task/CPU impact
• Switch discards, errors and multicast counters
• Time to a safe or defined process state after loss

This method can legitimately conclude that either protocol fits, that only one fits, or that both fit and lifecycle factors decide.

Network design and diagnostics

Modbus TCP design checklist

• Group contiguous data to avoid a large number of small transactions.
• Document maximum simultaneous clients and outstanding transactions per server.
• Use unique transaction identifiers and validate response function, length and address.
• Treat Modbus exceptions as diagnostics, not values.
• Expose communication health separately from process data.
• Record retries and timeouts; do not retry indefinitely while holding a stale command active.
• Validate the entire map after firmware or parameter changes.
• Keep a packet capture from a known-good commissioning state.

EtherNet/IP design checklist

• Verify scanner/originator and adapter/target roles.
• Validate EDS revision, assemblies, sizes, connection type and supported RPI.
• Decide whether the connection is unicast or multicast.
• For multicast, design and verify IGMP snooping and a querier rather than allowing traffic to flood by accident.
• Record connection general and extended status, not only a generic “module fault.”
• Check switch port errors, discards, QoS configuration, multicast groups and topology status.
• Validate connection recovery after power, cable and switch faults.
• Confirm controller connection and packet-rate capacity with the final project loaded.

ODVA’s EtherNet/IP document library publishes network-infrastructure, media, interoperability and performance guidance. Use the device vendor’s scoped instructions alongside those technology documents.

Security: neither base protocol is a security boundary

The base forms of Modbus TCP and EtherNet/IP should not be treated as authenticated or confidential simply because they run on an industrial network.

Modbus Security

The Modbus Organization publishes a separate Modbus Security specification that combines Modbus with TLS and X.509 certificates. The organization’s current specification page identifies port 802 for the secure protocol. Support is not implied by ordinary Modbus TCP support; verify both endpoints, certificate lifecycle, failure behavior and operational tooling.

CIP Security

CIP Security is also optional. ODVA’s CIP Security overview describes security profiles for properties such as endpoint authentication, integrity, confidentiality, user authentication and device-based filtering. A product may support only some profiles or none. Confirm the exact declaration, firmware, commissioning process and compatibility across every communicating endpoint.

Controls required either way

• Maintain an asset and communication-flow inventory.
• Put controllers and devices in defined zones.
• Route inter-zone traffic through an industrial firewall.
• Allow only required source, destination, service and direction.
• Keep programming and remote access behind authenticated, logged paths.
• Disable unused services and accounts.
• Back up controller, device, switch, firewall and gateway configurations.
• Monitor switch, firewall and endpoint diagnostics.
• Test restoration and certificate/device replacement where secure profiles are used.
• Never expose a control device directly to the public Internet.

NIST SP 800-82 Rev. 3 provides current official guidance for operational-technology security architectures and controls. Apply it with the site’s risk assessment and safety requirements.

Making Modbus TCP and EtherNet/IP coexist

They can share Ethernet infrastructure when the network is engineered for all traffic, but “same switch” is not the same as “integrated application.” A gateway, controller or software service must map the data and behavior.

Gateway mapping example

For every item, define:

• Source and destination addresses
• Data type, signedness, scaling and units
• Byte and word order
• Read/write direction and single owner
• Update schedule
• Stale and bad-quality behavior
• Command and response sequence
• Default value at startup
• Response to gateway restart or mapping failure
• Configuration revision and backup

ODVA’s current CIP Networks specification list includes a volume for integration of Modbus devices into CIP. Whether an endpoint or gateway implements those translation services is a product fact to verify, not a reason to assume transparent behavior.

When not to use a gateway

Avoid a translation boundary when:

• The required update deadline has no validated margin.
• A native diagnostic, safety, time-sync or motion service would be lost.
• The gateway cannot expose data quality or connection state.
• Two systems could issue conflicting commands.
• Replacement requires undocumented manual configuration.
• The device map or assembly is not version controlled.
• The process cannot tolerate the gateway as another failure point.

In those cases, a native interface, local control redesign or information-layer integration may be safer.

Factory acceptance test

Use the same acceptance cases for both candidate designs:

Attach packet captures, controller trends, switch counters, test timestamps, configuration exports and sign-off to the FAT record.

Cost and lifecycle comparison

Do not use a universal price table. Protocol licensing, controller modules, engineering tools, managed switches, secure-profile support, gateways, vendor support and labor vary by region, agreement and product.

Build two like-for-like bills of material:

Modbus TCP may have the lowest software friction for a small map but higher engineering ownership for semantics and polling. EtherNet/IP may reduce integration effort in a native CIP ecosystem but require more specialized device, network and connection knowledge. The quote and proof-of-fit decide—not the protocol label.

Final decision workflow

1. List the exact controllers, devices, firmware and supported protocol roles.
2. Define every exchanged value, owner, type, units, scale, freshness and failure action.
3. State the timing, recovery and process-safety requirements.
4. Verify register maps or CIP objects/assemblies against primary documentation.
5. Draw the network, zones, multicast scope and firewall flows.
6. Build a representative proof-of-fit for both viable options.
7. Run the matched benchmark and FAT cases.
8. Compare the complete lifecycle bill of material and support model.
9. Select the lowest-risk design that passes—not the protocol with the strongest marketing claim.
10. Preserve the evidence, captures, mappings and recovery procedure with the project.

Bottom line

Choose Modbus TCP when a simple, well-owned register contract meets the update and diagnostic requirements. Choose EtherNet/IP when native CIP objects, assemblies, profiles and connected I/O materially reduce engineering and lifecycle risk. Use both when installed assets justify a deliberate translation boundary.

The protocol is only one layer. A reliable system comes from an explicit data contract, measured timing, local failure behavior, secure network design, documented diagnostics and repeatable acceptance tests.

Primary technical sources

• Modbus specifications and implementation guides — Modbus Organization
• Modbus Application Protocol Specification V1.1b3 — Modbus Organization
• Modbus Messaging on TCP/IP Implementation Guide V1.0b — Modbus Organization
• Modbus Security Protocol — Modbus Organization
• EtherNet/IP Technology Overview, PUB00138R8 — ODVA
• CIP and EtherNet/IP specification versions — ODVA
• EtherNet/IP technical document library — ODVA
• CIP Security at a Glance — ODVA
• Service Name and Port Number Registry — IANA
• Guide to Operational Technology Security, SP 800-82 Rev. 3 — NIST

Related guides: PLC communication protocols · Modbus RTU protocol · EtherNet/IP vs PROFINET · PROFINET tutorial