7 posts tagged with "cip"

If you've spent any time integrating Allen-Bradley PLCs, Rockwell automation cells, or Micro800-class controllers into a modern IIoT stack, you've encountered EtherNet/IP. It's the most widely deployed industrial Ethernet protocol in North America, yet the specifics of how it actually moves data — CIP objects, implicit vs explicit messaging, the scanner/adapter relationship — remain poorly understood by many engineers who use it daily.

This guide breaks down EtherNet/IP from the perspective of someone who has built edge gateways that communicate with these controllers in production. No marketing fluff, just the protocol mechanics that matter when you're writing code that reads tags from a PLC at sub-second intervals.

What EtherNet/IP Actually Is (And Isn't)​

EtherNet/IP stands for EtherNet/Industrial Protocol — not "Ethernet IP" as in TCP/IP. The "IP" is intentionally capitalized to distinguish it. At its core, EtherNet/IP is an application-layer protocol that runs CIP (Common Industrial Protocol) over standard TCP/IP and UDP/IP transport.

The key architectural insight: CIP is the protocol. EtherNet/IP is just one of its transport layers. CIP also runs over DeviceNet (CAN bus) and ControlNet (token-passing). This means the object model, service codes, and data semantics are identical whether you're talking to a device over Ethernet, a CAN network, or a deterministic control network.

For IIoT integration, this matters because your edge gateway's parsing logic for CIP objects translates directly across all three physical layers — even if 90% of modern deployments use EtherNet/IP exclusively.

The CIP Object Model​

CIP organizes everything as objects. Every device on the network is modeled as a collection of object instances, each with attributes, services, and behaviors. Understanding this hierarchy is essential for programmatic tag access.

Object Addressing​

Every piece of data in a CIP device is addressed by three coordinates:

When your gateway creates a tag path like protocol=ab-eip&gateway=192.168.1.10&cpu=micro800&name=temperature_setpoint, the underlying CIP request resolves that symbolic tag name into a class/instance/attribute triplet.

Essential CIP Objects for IIoT​

Here are the objects you'll interact with most frequently:

Identity Object (Class 0x01) — Every CIP device has one. Vendor ID, device type, serial number, product name. This is your first read when auto-discovering devices on a network. For fleet management, querying this object gives you hardware revision, firmware version, and a unique serial number that serves as a device fingerprint.

Message Router (Class 0x02) — Routes incoming requests to the correct object. You never address it directly, but understanding that it exists explains why a single TCP connection can multiplex requests to dozens of different objects without confusion.

Assembly Object (Class 0x04) — This is where I/O data lives. Assemblies aggregate multiple data points into a single, contiguous block. When you configure implicit messaging, you're essentially subscribing to an assembly object that the PLC updates at a fixed rate.

Connection Manager (Class 0x06) — Manages the lifecycle of connections. Forward Open, Forward Close, and Large Forward Open requests all go through this object. When your edge gateway opens a connection to read 50 tags, the Connection Manager allocates resources and returns a connection ID.

Implicit vs Explicit Messaging: The Critical Distinction​

This is where most IIoT integration mistakes happen. EtherNet/IP supports two fundamentally different messaging paradigms, and choosing the wrong one leads to either wasted bandwidth or missed data.

Explicit Messaging (Request/Response)​

Explicit messaging works like HTTP: your gateway sends a request, the PLC processes it, and sends a response. It uses TCP for reliability.

When to use explicit messaging:

• Reading configuration parameters
• Writing setpoints or recipe values
• Querying device identity and diagnostics
• Any operation where you need a guaranteed response
• Tag reads at intervals > 100ms

The tag read flow:

Gateway                           PLC (Micro800)
   |                                |
   |--- TCP Connect (port 44818) -->|
   |<-- TCP Accept ------------------|
   |                                |
   |--- Register Session ---------->|
   |<-- Session Handle: 0x1A2B ----|
   |                                |
   |--- Read Tag Service ---------->|
   |    (class 0x6B, service 0x4C)  |
   |    tag: "blender_speed"        |
   |<-- Response: FLOAT 1250.5 -----|
   |                                |
   |--- Read Tag Service ---------->|
   |    tag: "motor_current"        |
   |<-- Response: FLOAT 12.3 ------|

Each tag read is a separate CIP request encapsulated in a TCP packet. For reading dozens of tags, this adds up — each round trip includes TCP overhead, CIP encapsulation, and PLC processing time.

Performance characteristics:

• Typical round-trip: 5–15ms per tag on a local network
• 50 tags × 10ms = 500ms minimum cycle time
• Connection timeout: typically 2000ms (configurable)
• Maximum concurrent sessions: depends on PLC model (Micro800: ~8–16)

Implicit Messaging (I/O Data)​

Implicit messaging is a scheduled, connectionless data exchange using UDP. The PLC pushes data at a fixed rate without being asked — think of it as a PLC-initiated publish.

When to use implicit messaging:

• Continuous process monitoring (temperature, pressure, flow)
• Motion control feedback
• Any data that changes frequently (< 100ms intervals)
• High tag counts where polling overhead is unacceptable

The connection flow:

Gateway                           PLC
   |                                |
   |--- Forward Open (TCP) ------->|
   |    RPI: 50ms                   |
   |    Connection type: Point-to-Point |
   |    O→T Assembly: Instance 100  |
   |    T→O Assembly: Instance 101  |
   |<-- Forward Open Response ------|
   |    Connection ID: 0x4F2E       |
   |                                |
   |<== I/O Data (UDP, every 50ms) =|
   |<== I/O Data (UDP, every 50ms) =|
   |<== I/O Data (UDP, every 50ms) =|
   |    ...continuous...             |

The Requested Packet Interval (RPI) is specified in microseconds during the Forward Open. Common values:

• 10ms (10,000 μs) — motion control
• 50ms — process monitoring
• 100ms — general I/O
• 500ms–1000ms — slow-changing values (temperature, level)

Critical detail: The data format of implicit messages is defined by the assembly object, not by the message itself. Your gateway must know the assembly layout in advance — which bytes correspond to which tags, their data types, and byte ordering. There's no self-describing metadata in the UDP packets.

Scanner/Adapter Architecture​

In EtherNet/IP terminology:

• Scanner = the device that initiates connections and consumes data (your edge gateway, HMI, or supervisory PLC)
• Adapter = the device that produces data (field I/O modules, drives, instruments)

A PLC can act as both: it's an adapter to the SCADA system above it, and a scanner to the I/O modules below it.

What This Means for IIoT Gateways​

Your edge gateway is a scanner. When designing its communication stack, you need to handle:

1. Session registration — Before any CIP communication, register a session with the target device. This returns a session handle that must be included in every subsequent request. Session handles are 32-bit integers; manage them carefully across reconnects.

2. Connection management — For explicit messaging, a single TCP connection can carry multiple CIP requests. For implicit messaging, each connection requires a Forward Open with specific parameters. Plan your connection budget — Micro800 controllers support 8–16 simultaneous connections depending on firmware.

3. Tag path resolution — Symbolic tag names (like B3_0_0_blender_st_INT) must be resolved to CIP paths. For Micro800 controllers, the tag path format is:

   protocol=ab-eip&gateway=<ip>&cpu=micro800&elem_count=<n>&elem_size=<s>&name=<tagname>
   

   Where elem_size is 1 (bool/int8), 2 (int16), or 4 (int32/float).

4. Array handling — CIP supports reading arrays with a start index and element count. A single request can read up to 255 elements. For arrays, the tag path includes the index: tagname[start_index].

Data Types and Byte Ordering​

CIP uses little-endian byte ordering for all integer types, which is native to x86-based controllers. However, when tag values arrive at your gateway, the handling depends on the data type:

A common gotcha: When reading 32-bit values, the element offset in the response buffer is index × 4 bytes from the start. For 16-bit values, it's index × 2. Getting this wrong silently produces garbage values that look plausible — a classic source of phantom sensor readings.

Practical Integration Pattern: Interval-Based Tag Reading​

In production IIoT deployments, not every tag needs to be read at the same rate. A blender's running status might change once per shift, while a motor current needs 1-second resolution. A well-designed gateway implements per-tag interval scheduling:

Tag Configuration:
  - blender_status:  type=bool,   interval=60s,  compare=true
  - motor_speed:     type=float,  interval=5s,   compare=false
  - temperature_sp:  type=float,  interval=10s,  compare=true
  - alarm_word:      type=uint16, interval=1s,   compare=true

The compare flag is crucial for bandwidth optimization. When enabled, the gateway only forwards a value to the cloud if it has changed since the last read. For boolean status tags that might stay constant for hours, this eliminates 99%+ of redundant transmissions.

Dependent Tag Chains​

Some tags are only meaningful when a parent tag changes. For example, when a machine_state tag transitions from IDLE to RUNNING, you want to immediately read a cascade of operational tags (speed, temperature, pressure) regardless of their normal intervals.

This pattern — triggered reads on value change — dramatically reduces average bandwidth while ensuring you never miss the data that matters. The gateway maintains a dependency graph where certain tags trigger force-reads of their children.

Handling Connection Failures​

EtherNet/IP connections fail. PLCs reboot. Network switches drop packets. A production-grade gateway implements:

1. Retry with backoff — On read failure (typically error code -32 for connection timeout), retry up to 3 times before declaring the link down.
2. Link state tracking — Maintain a boolean link state per device. Transition to DOWN on persistent failures; transition to UP on the first successful read. Deliver link state changes immediately (not batched) as they're high-priority events.
3. Automatic reconnection — On link DOWN, destroy the existing connection context and attempt to re-establish. Don't just retry on the dead socket.
4. Hourly forced reads — Even when using compare-based transmission, periodically force-read and deliver all tags. This prevents state drift where the gateway and cloud have different views of a value that changed during a brief disconnection.

Batching for MQTT Delivery​

The gateway doesn't forward each tag value individually to the cloud. Instead, it implements a batch-and-forward pattern:

1. Start a batch group with a timestamp
2. Accumulate tag values (with ID, status, type, and value data)
3. Close the group when either:
   • The batch size exceeds the configured maximum (typically 4KB)
   • The collection timeout expires (typically 60 seconds)
4. Serialize the batch (JSON or binary) and push to an output buffer
5. The output buffer handles MQTT QoS 1 delivery with page-based flow control

Binary serialization is preferred for bandwidth-constrained cellular connections. A typical binary batch frame:

Header:  0xF7 (command byte)
         4 bytes: number of groups
Per group:
         4 bytes: timestamp
         2 bytes: device type
         4 bytes: serial number
         4 bytes: number of values
Per value:
         2 bytes: tag ID
         1 byte:  status (0x00 = OK)
         1 byte:  array size
         1 byte:  element size (1, 2, or 4)
         N bytes: packed data (MSB → LSB)

This binary format achieves roughly 3–5x compression over equivalent JSON, which matters when you're paying per-megabyte on cellular or satellite links.

Performance Benchmarks​

Based on production deployments with Micro800 controllers:

The "mixed interval + compare" row shows the power of intelligent scheduling — by reading fast-changing tags frequently and slow-changing tags infrequently, and only forwarding values that actually changed, you can monitor 100+ tags with less bandwidth than 20 tags on implicit I/O.

Common Pitfalls​

1. Exhausting connection slots. Each Forward Open consumes a connection slot on the PLC. Open too many and you'll get "Connection Refused" errors. Pool your connections and reuse sessions.

2. Mismatched element sizes. If you request elem_size=4 but the tag is actually INT16, you'll read adjacent memory and get corrupted values. Always match element size to the tag's actual data type.

3. Ignoring the simulator trap. When testing with a PLC simulator, random values mask real issues like byte-ordering bugs and timeout handling. Test against real hardware before deploying.

4. Not handling -32 errors. Error code -32 from libplctag means "connection failed." Three consecutive -32s should trigger a full disconnect/reconnect cycle, not just a retry on the same broken connection.

5. Blocking on tag creation. Creating a tag handle (plc_tag_create) can block for the full timeout duration if the PLC is unreachable. Use appropriate timeouts (2000ms is a reasonable default) and handle negative return values.

How machineCDN Handles EtherNet/IP​

machineCDN's edge gateway natively supports EtherNet/IP with the patterns described above: per-tag intervals, compare-based change detection, dependent tag chains, binary batch serialization, and store-and-forward buffering. When you connect a Micro800 or CompactLogix controller, the gateway auto-detects the protocol, reads device identity, and begins scheduled tag acquisition — no manual configuration of CIP class/instance/attribute paths required.

The platform handles the complexity of connection management, retry logic, and bandwidth optimization so your engineering team can focus on the data rather than the protocol plumbing.

Conclusion​

EtherNet/IP is more than "Modbus over Ethernet." Its CIP object model provides a rich, typed, hierarchical data architecture. Understanding the difference between implicit and explicit messaging — and knowing when to use each — is the difference between a gateway that polls itself to death and one that efficiently scales to hundreds of tags across dozens of controllers.

The key takeaways:

• Use explicit messaging for configuration reads and tags with intervals > 100ms
• Use implicit messaging for high-frequency process data
• Implement per-tag intervals with compare flags to minimize bandwidth
• Design for failure with retry logic, link state tracking, and periodic forced reads
• Batch before sending — never forward individual tag values to the cloud

Master these patterns and you'll build IIoT integrations that run reliably for years, not demos that break in production.

DeviceNet isn't dead — it's still running in thousands of manufacturing plants worldwide. But if you're maintaining a DeviceNet installation in 2026, you're living on borrowed time. Parts are getting harder to find. New devices are EtherNet/IP-only. Your IIoT platform can't natively speak CAN bus. And the engineers who understand DeviceNet's quirks are retiring.

The good news: DeviceNet and EtherNet/IP share the same application layer — the Common Industrial Protocol (CIP). That means migration isn't a complete rearchitecture. It's more like upgrading the transport while keeping the logic intact.

The bad news: the differences between a CAN-based serial bus and modern TCP/IP Ethernet are substantial, and the migration is full of subtle gotchas that can turn a weekend project into a month-long nightmare.

This guide covers what actually changes, what stays the same, and how to execute the migration without shutting down your production line.

Why Migrate Now​

The Parts Clock Is Ticking​

DeviceNet uses CAN (Controller Area Network) at the physical layer — the same bus technology from automotive. DeviceNet taps, trunk cables, terminators, and CAN-specific interface cards are all becoming specialty items. Allen-Bradley 1756-DNB DeviceNet scanners cost 2-3x what they did five years ago on the secondary market.

EtherNet/IP uses standard Ethernet infrastructure. Cat 5e/6 cable, commodity switches, and off-the-shelf NICs. You can buy replacement parts at any IT supplier.

IIoT Demands Ethernet​

Modern IIoT platforms connect to PLCs via EtherNet/IP (CIP explicit messaging), Modbus TCP, or OPC-UA — all Ethernet-based protocols. Connecting to DeviceNet requires a protocol converter or a dedicated scanner module, adding cost and complexity.

When an edge gateway reads tags from an EtherNet/IP-connected PLC, it speaks CIP directly over TCP/IP. The tag path, element count, and data types map cleanly to standard read operations. With DeviceNet, there's an additional translation layer — the gateway must talk to the DeviceNet scanner module, which then mediates communication to the DeviceNet devices.

Eliminating that layer means faster polling, simpler configuration, and fewer failure points.

Bandwidth Limitations​

DeviceNet runs at 125, 250, or 500 kbps — kilobits, not megabits. For simple discrete I/O (24 photoelectric sensors and a few solenoid valves), this is fine. But modern manufacturing cells generate far more data:

• Servo drive diagnostics
• Process variable trends
• Vision system results
• Safety system status words
• Energy monitoring data

A single EtherNet/IP connection runs at 100 Mbps minimum (1 Gbps typical) — that's 200-8,000x more bandwidth. The difference isn't just theoretical: it means you can read every tag at full speed without bus contention errors.

What Stays the Same: CIP​

The Common Industrial Protocol is protocol-agnostic. CIP defines objects (Identity, Connection Manager, Assembly), services (Get Attribute Single, Set Attribute, Forward Open), and data types independently of the transport layer.

This is DeviceNet's salvation — and yours. A CIP Assembly object that maps 32 bytes of I/O data works identically whether the transport is:

• DeviceNet (CAN frames, MAC IDs, fragmented messaging)
• EtherNet/IP (TCP/IP encapsulation, IP addresses, implicit I/O connections)
• ControlNet (scheduled tokens, node addresses)

Your PLC program doesn't care how the Assembly data arrives. The I/O mapping is the same. The tag names are the same. The data types are the same.

Practical Implication​

If you're running a Micro850 or CompactLogix PLC with DeviceNet I/O modules, migrating to EtherNet/IP I/O modules means:

1. PLC logic stays unchanged (mostly — more on this later)
2. Assembly instances map directly (same input/output sizes)
3. CIP services work identically (Get Attribute, Set Attribute, explicit messaging)
4. Data types are preserved (BOOL, INT, DINT, REAL — same encoding)

What changes is the configuration: MAC IDs become IP addresses, DeviceNet scanner modules become EtherNet/IP adapter ports, and CAN trunk cables become Ethernet switches.

What Changes: The Deep Differences​

Addressing: MAC IDs vs. IP Addresses​

DeviceNet uses 6-bit MAC IDs (0-63) set via physical rotary switches or software. Each device on the bus has a unique MAC ID, and the scanner references devices by this number.

EtherNet/IP uses standard IP addressing. Devices get addresses via DHCP, BOOTP, or static configuration. The scanner references devices by IP address and optionally by hostname.

Migration tip: Create an address mapping spreadsheet before you start:

DeviceNet MAC ID → EtherNet/IP IP Address
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
MAC 01 (Motor Starter #1) → 192.168.1.101
MAC 02 (Photoelectric Bank) → 192.168.1.102  
MAC 03 (Valve Manifold)     → 192.168.1.103
MAC 10 (VFD Panel A)        → 192.168.1.110
MAC 11 (VFD Panel B)        → 192.168.1.111

Use the last two octets of the IP address to mirror the old MAC ID where possible. Maintenance technicians who know "MAC 10 is the VFD panel" will intuitively map to 192.168.1.110.

Communication Model: Polled I/O vs. Implicit Messaging​

DeviceNet primarily uses polled I/O or change-of-state messaging. The scanner sends a poll request to each device, and the device responds with its current data. This is sequential — device 1, then device 2, then device 3, and so on.

EtherNet/IP uses implicit (I/O) messaging with Requested Packet Interval (RPI). The scanner opens a CIP connection to each adapter, and data flows at a configured rate (typically 5-100ms) using UDP multicast. All connections run simultaneously — no sequential polling.

DeviceNet (Sequential):
Scanner → Poll MAC01 → Response → Poll MAC02 → Response → ...
Total cycle = Sum of all individual transactions

EtherNet/IP (Parallel):
Scanner ──┬── Connection to 192.168.1.101 (RPI 10ms)
          ├── Connection to 192.168.1.102 (RPI 10ms) 
          ├── Connection to 192.168.1.103 (RPI 10ms)
          └── Connection to 192.168.1.110 (RPI 20ms)
Total cycle = Max(individual RPIs) = 20ms

Performance impact: A DeviceNet bus with 20 devices at 500kbps might have a scan cycle of 15-30ms. The same 20 devices on EtherNet/IP can all run at 10ms RPI simultaneously, with room to spare. Your control loop gets faster, not just your bandwidth.

Error Handling: Bus Errors vs. Connection Timeouts​

DeviceNet has explicit error modes tied to the CAN bus: bus-off, error passive, CAN frame errors. When a device misses too many polls, it goes into a "timed out" state. The scanner reports which MAC ID failed.

EtherNet/IP uses TCP connection timeouts and UDP heartbeats. If an implicit I/O connection misses 4x its RPI without receiving data, the connection times out. The error reporting is more granular — you can distinguish between "device unreachable" (ARP failure), "connection refused" (CIP rejection), and "data timeout" (UDP loss).

Important: DeviceNet's error behavior is synchronous with the bus scan. When a device fails, you know immediately on the next scan cycle. EtherNet/IP's timeout behavior is asynchronous — a connection can be timing out while others continue normally. Your fault-handling logic may need adjustment to handle this differently.

Wiring and Topology​

DeviceNet is a bus topology with a single trunk line. All devices tap into the same cable. Maximum trunk length depends on baud rate:

• 500 kbps: 100m trunk
• 250 kbps: 250m trunk
• 125 kbps: 500m trunk

Drop cables from trunk to device are limited to 6m. Total combined drop length has a bus-wide limit (156m at 125 kbps).

EtherNet/IP is a star topology. Each device connects to a switch port via its own cable (up to 100m per run for copper, kilometers for fiber). No trunk length limits, no drop length limits, no shared-bus contention.

Migration implication: You can't just swap cables. DeviceNet trunk cables are typically 18 AWG with integrated power (24V bus power). Ethernet uses Cat 5e/6 without power. If your DeviceNet devices were bus-powered, you'll need separate 24V power runs to each device location, or use PoE (Power over Ethernet) switches.

Migration Strategy: The Three Approaches​

1. Big Bang (Not Recommended)​

Replace everything at once during a planned shutdown. Remove all DeviceNet hardware, install EtherNet/IP modules, reconfigure the PLC, test, and restart.

Pros: Clean cutover, no mixed-network complexity. Cons: If anything goes wrong, your entire line is down. Testing time is limited to the shutdown window. Very high risk.

2. Parallel Run with Protocol Bridge​

Install a DeviceNet-to-EtherNet/IP protocol bridge (like ProSoft MVI69-DFNT or HMS Anybus). Keep the DeviceNet bus running while you add EtherNet/IP connectivity.

PLC ──── EtherNet/IP ──── Protocol Bridge ──── DeviceNet Bus
                              │
                     IIoT Edge Gateway
                     (native EtherNet/IP access)

Pros: Zero downtime, gradual migration, IIoT connectivity immediately. Cons: Protocol bridge adds latency (~5-10ms), cost ($500-2000 per bridge), another device to maintain. Assembly mapping through the bridge can be tricky.

3. Rolling Migration (Recommended)​

Replace DeviceNet devices one at a time (or one machine cell at a time) with EtherNet/IP equivalents. The PLC runs both a DeviceNet scanner and an EtherNet/IP adapter simultaneously during the transition.

Most modern PLCs (CompactLogix, ControlLogix) support both. The DeviceNet scanner module (1756-DNB or 1769-SDN) stays in the rack alongside the Ethernet port. As devices are migrated, their I/O is remapped from the DeviceNet scanner tree to the EtherNet/IP I/O tree.

Migration sequence per device:

1. Order the EtherNet/IP equivalent of the DeviceNet device
2. Pre-configure IP address, Assembly instances, RPI
3. During a micro-stop (shift change, lunch break):
   • Disconnect DeviceNet device
   • Install EtherNet/IP device + Ethernet cable
   • Remap I/O tags in PLC from DeviceNet scanner to EtherNet/IP adapter
   • Test
4. Remove old DeviceNet device

Typical timeline: 15-30 minutes per device. A 20-device network can be migrated over 2-3 weeks of micro-stops.

PLC Program Changes​

Tag Remapping​

The biggest PLC-side change is tag paths. DeviceNet I/O tags reference the scanner module and MAC ID:

DeviceNet:
Local:1:I.Data[0]  (Scanner in slot 1, input word 0)

EtherNet/IP I/O tags reference the connection by IP:

EtherNet/IP:
Valve_Manifold:I.Data[0]  (Named connection, input word 0)

Best practice: Use aliased tags in your PLC program. If your rungs reference Motor_1_Running (alias of Local:1:I.Data[0].2), you only need to change the alias target — not every rung that uses it. If your rungs directly reference the I/O path... you have more work to do.

RPI Tuning​

DeviceNet scan rates are managed at the bus level. EtherNet/IP lets you set RPI per connection. Start with:

• Discrete I/O (photoelectrics, solenoids): 10-20ms RPI
• Analog I/O (temperatures, pressures): 50-100ms RPI
• VFDs (speed/torque data): 20-50ms RPI
• Safety I/O (CIP Safety): 10-20ms RPI (match safety PFD requirements)

Don't over-poll. Setting everything to 2ms RPI because you can will create unnecessary network load and CPU consumption. Match the RPI to the actual process dynamics.

Connection Limits​

DeviceNet scanners support 63 devices (MAC ID limit). EtherNet/IP has no inherent device limit, but each PLC has a connection limit — typically 128-256 CIP connections depending on the controller model.

Each EtherNet/IP I/O device uses at least one connection. Devices with multiple I/O assemblies (e.g., separate safety and standard I/O) use multiple connections. Monitor your controller's connection count during migration.

IIoT Benefits After Migration​

Once your devices are on EtherNet/IP, your IIoT edge gateway can access them directly via CIP explicit messaging — no protocol converters needed.

The gateway opens CIP connections to each device, reads tags at configurable intervals, and publishes the data to MQTT or another cloud transport. This is how platforms like machineCDN operate: they speak native EtherNet/IP (and Modbus TCP) to the devices, handling type conversion, batch aggregation, and store-and-forward for cloud delivery.

What this enables:

• Direct device diagnostics: Read CIP identity objects (vendor ID, product name, firmware version) from every device on the network. No more walking the floor with a DeviceNet configurator.
• Process data at full speed: Read servo drive status, VFD parameters, and temperature controllers at 1-2 second intervals without bus contention.
• Predictive maintenance signals: Vibration data, motor current, bearing temperature — all available over EtherNet/IP from modern drives.
• Remote troubleshooting: An engineer can read device parameters from anywhere on the plant network (or through VPN) without physically connecting to a DeviceNet bus.

Tag Reads After Migration​

With EtherNet/IP, the edge gateway connects using CIP's ab-eip protocol to read tags by name:

Protocol: EtherNet/IP (CIP)
Gateway:  192.168.1.100 (PLC IP)
CPU:      Micro850
Tag:      barrel_temp_zone_1
Type:     REAL (float32)

The gateway reads the tag value, applies type conversion (the PLC stores IEEE 754 floats natively, so no Modbus byte-swapping gymnastics), and delivers it to the cloud. Compared to reading the same value through a DeviceNet scanner's polled I/O words — where you'd need to know which word offset maps to which variable — named tags are dramatically simpler.

Network Design for EtherNet/IP​

Switch Selection​

Use managed industrial Ethernet switches, not consumer/office switches. Key features:

• IGMP snooping: EtherNet/IP uses UDP multicast for implicit I/O. Without IGMP snooping, multicast traffic floods every port.
• QoS/DiffServ: Prioritize CIP I/O traffic (DSCP 47/55) over best-effort traffic.
• Port mirroring: Essential for troubleshooting with Wireshark.
• DIN-rail mounting: Because this is going in an industrial panel, not a server room.
• Extended temperature range: -10°C to 60°C minimum for factory environments.

VLAN Segmentation​

Separate your EtherNet/IP I/O traffic from IT/IIoT traffic using VLANs:

VLAN 10: Control I/O (PLC ↔ I/O modules, drives)
VLAN 20: HMI/SCADA (operator stations)
VLAN 30: IIoT/Cloud (edge gateways, MQTT)
VLAN 99: Management (switch configuration)

The edge gateway lives on VLAN 30 with a routed path to VLAN 10 for CIP reads. This ensures IIoT traffic can never interfere with control I/O at the switch level.

Ring Topology for Redundancy​

DeviceNet is a bus — one cable break takes down everything downstream. EtherNet/IP with DLR (Device Level Ring) or RSTP (Rapid Spanning Tree) provides sub-second failover. A single cable cut triggers a topology change, and traffic reroutes automatically.

Most Allen-Bradley EtherNet/IP modules support DLR natively. Third-party devices may require an external DLR-capable switch.

Common Migration Mistakes​

1. Forgetting Bus Power​

DeviceNet provides 24V bus power on the trunk cable. Many DeviceNet devices (especially compact I/O blocks) draw power from the bus and have no separate power terminals. When you remove the DeviceNet trunk, those devices need a dedicated 24V supply.

Check every device's power requirements before migration. This is the most commonly overlooked issue.

2. IP Address Conflicts​

DeviceNet MAC IDs are set physically — you can see them. IP addresses are invisible. Two devices with the same IP will cause intermittent communication failures that are incredibly difficult to diagnose.

Reserve a dedicated subnet for EtherNet/IP I/O (e.g., 192.168.1.0/24) and maintain a strict IP allocation spreadsheet. Use DHCP reservations or BOOTP if your devices support it.

3. Not Testing Failover Behavior​

DeviceNet and EtherNet/IP handle device failures differently. Your PLC program may assume DeviceNet-style fault behavior (synchronous, bus-wide notification). EtherNet/IP faults are per-connection and asynchronous.

Test every failure mode: device power loss, cable disconnection, switch failure. Verify that your fault-handling rungs respond correctly.

4. Ignoring Firmware Compatibility​

EtherNet/IP devices from the same vendor may have different Assembly instance mappings across firmware versions. The device you tested in the lab may behave differently from the one installed on the floor if the firmware versions don't match.

Document firmware versions and maintain spare devices with matching firmware.

Timeline and Budget​

For a typical migration of a 20-device DeviceNet network:

Timeline: 2-4 weeks with rolling migration approach, including engineering prep, device installation, and testing. The line can continue running throughout.

Compare this to the alternative: maintaining a DeviceNet network with $800 replacement scanner modules, 4-week lead times on DeviceNet I/O blocks, and no IIoT connectivity. The migration pays for itself in reduced maintenance costs and operational visibility within 12-18 months.

Conclusion​

DeviceNet to EtherNet/IP migration is not a question of if — it's a question of when. The CIP application layer makes it far less painful than migrating between incompatible protocols. Your PLC logic stays intact, your I/O mappings transfer directly, and you gain immediate benefits in bandwidth, diagnostic capability, and IIoT readiness.

Start with a network audit. Map every device, its MAC ID, its I/O configuration, and its power requirements. Then execute a rolling migration — one device at a time, one micro-stop at a time — until the last DeviceNet tap is removed.

Your reward: a modern Ethernet infrastructure that speaks the same CIP language, runs 1,000x faster, and connects directly to every IIoT platform on the market.

Walk onto any modern plant floor and you'll find a patchwork of controllers — Allen-Bradley Micro800 series running EtherNet/IP, Modbus TCP devices from half a dozen vendors, maybe a legacy RTU on a serial port somewhere. The edge gateway sitting in that control cabinet needs to figure out what it's talking to, what protocol to use, and how to pull the right data — ideally without a technician manually configuring every register.

This is the device auto-discovery problem, and solving it well is the difference between a two-hour commissioning versus a two-day one.

The Discovery Sequence: Try EtherNet/IP First, Fall Back to Modbus​

The most reliable approach follows a dual-protocol detection pattern. When an edge gateway powers up and finds a PLC at a known IP address, it shouldn't assume which protocol that device speaks. Instead, it runs a detection sequence:

Step 1: Attempt EtherNet/IP (CIP) Connection

EtherNet/IP uses the Common Industrial Protocol (CIP) over TCP port 44818. The gateway attempts to create a connection to a known tag — typically a device_type identifier that the PLC firmware exposes as a readable tag.

Protocol: ab-eip
Gateway: 192.168.1.100
CPU: micro800
Tag: device_type
Element Size: 2 bytes (uint16)
Element Count: 1
Timeout: 2000ms

If this connection succeeds and returns a non-zero value, the gateway knows it's talking to an EtherNet/IP device and can proceed to read the serial number components.

Step 2: If EtherNet/IP fails, try Modbus TCP

If the CIP connection returns an error (typically error code -32, indicating no route to host at the CIP layer), the gateway falls back to Modbus TCP on port 502.

For Modbus detection, the gateway reads input register 800 (address 0x300320 in the full Modbus address space — function code 4). This register holds the device type identifier by convention in many industrial equipment families.

Protocol: Modbus TCP
Port: 502
Function Code: 4 (Read Input Registers)
Start Address: 800
Register Count: 1

Step 3: Extract Serial Number

Once the device type is known, the gateway reads serial number components. Here's where things get vendor-specific. Different PLC families store their serial numbers in completely different register locations:

Notice the inconsistency — even within the same protocol, each device family stores its serial number in different registers, uses different function codes (input registers vs. holding registers), and sometimes the year/month/unit ordering isn't sequential in memory. This is real-world industrial automation, not a textbook.

Serial Number Encoding: Packing Identity into 32 Bits​

Once you have the three components (year, month, unit number), they're packed into a single 32-bit serial number for efficient transport:

Byte 3 (bits 31-24): Year  (0x00-0xFF)
Byte 2 (bits 23-16): Month (0x00-0xFF)  
Bytes 1-0 (bits 15-0): Unit Number (0x0000-0xFFFF)

This encoding allows up to 65,535 units per month per year — more than sufficient for any production line. A serial number of 0x18031A2B decodes to: year 0x18 (24), month 0x03 (March), unit 0x1A2B (6699).

Validation Matters​

A serial number where the year byte is zero is invalid — it almost certainly means the PLC hasn't been properly commissioned or the register read returned garbage data. Your gateway should reject these and report a "bad serial number" status rather than silently accepting a device with identity 0x00000000.

The Configuration Lookup Pattern​

Once the gateway knows the device type (e.g., type 1018 = HE Central Chiller), it needs to load the right tag configuration. The proven pattern is a directory scan:

1. Maintain a directory of JSON configuration files (one per device type)
2. On detection, scan the directory and match the device_type field in each JSON
3. Load the matched configuration, which defines all tags, their data types, read intervals, and batching behavior

{
  "device_type": 1018,
  "version": "2.4.1",
  "name": "HE Central Chiller",
  "protocol": "modbus-tcp",
  "plctags": [
    {
      "name": "supply_temp",
      "id": 1,
      "type": "float",
      "addr": 400100,
      "ecount": 2,
      "interval": 5,
      "compare": true
    },
    {
      "name": "compressor_status",
      "id": 2, 
      "type": "uint16",
      "addr": 400200,
      "interval": 1,
      "compare": true,
      "do_not_batch": true
    }
  ]
}

Key design decisions in this configuration:

• compare: true means only transmit when the value changes — critical for reducing bandwidth on cellular connections
• do_not_batch: true means send immediately rather than accumulating in a batch — used for status changes and alarms that need real-time delivery
• interval defines the polling frequency in seconds — fast-changing temperatures might be 5 seconds, while a compressor on/off status needs sub-second reads
• ecount: 2 for floats means reading two consecutive 16-bit Modbus registers and combining them into an IEEE 754 float

Handling Modbus Address Conventions​

One of the trickiest aspects of Modbus auto-discovery is the address-to-function-code mapping. Different vendors use different conventions, but the most common maps addresses to function codes like this:

When you see a configured address of 400100, the gateway strips the prefix: the actual Modbus register address sent on the wire is 100, using function code 3.

Register Grouping Optimization​

Smart gateways don't read one register at a time. They scan the sorted tag list and identify contiguous address ranges that share the same function code and polling interval. These get combined into a single Modbus read request:

Tags at addresses: 400100, 400101, 400102, 400103, 400104
→ Single request: FC3, start=100, count=5

But grouping has limits. Exceeding ~50 registers per request risks timeouts, especially on Modbus RTU over slow serial links. And you can't group across function code boundaries — a tag at address 300050 (FC4) and 400050 (FC3) must be separate requests, even though they're "near" each other numerically.

Multi-Protocol Detection: The Real-World Sequence​

In practice, a gateway on a plant floor often needs to detect multiple devices simultaneously — a PLC on EtherNet/IP and a temperature control unit on Modbus RTU via RS-485. The detection sequence runs in parallel:

1. EtherNet/IP detection happens over the plant's Ethernet network — standard TCP/IP, fast, usually succeeds or fails within 2 seconds
2. Modbus TCP detection uses the same Ethernet interface but different port (502) — also fast
3. Modbus RTU detection happens over a serial port (/dev/ttyUSB0 or similar) — much slower, constrained by baud rate (typically 9600–115200), with byte timeouts around 50ms and response timeouts of 400ms

The serial link parameters are critical and often misconfigured:

Port: /dev/ttyUSB0
Baud Rate: 9600
Parity: None ('N')
Data Bits: 8
Stop Bits: 1
Slave Address: 1
Byte Timeout: 50ms
Response Timeout: 400ms

Getting the parity wrong is the #1 commissioning mistake with Modbus RTU. If the slave expects Even parity and the master sends None, every frame will be rejected silently — no error message, just timeouts.

Connection Resilience: The Watchdog Pattern​

Discovery isn't a one-time event. Industrial connections drop — cables get unplugged during maintenance, PLCs get rebooted, network switches lose power. A robust gateway implements a multi-layer resilience strategy:

Link State Tracking: Every successful read sets the link state to "up." Any read error (timeout, connection reset, broken pipe, bad file descriptor) sets it to "down" and triggers a reconnection sequence.

Connection Error Counting: For EtherNet/IP, if you get three consecutive error-32 responses (no CIP route), stop hammering the network and wait for the next polling cycle. For Modbus, error codes like ETIMEDOUT, ECONNRESET, ECONNREFUSED, or EPIPE trigger a modbus_close() followed by reconnection on the next cycle.

Modbus Flush on Error: After a failed Modbus read, always flush the serial/TCP buffer before the next attempt. Stale response bytes from a partial read can corrupt subsequent responses.

Configuration Hot-Reload: The gateway watches its configuration files with stat(). If a file's modification time changes, it triggers a full re-initialization — destroy existing PLC tag handles, reload the JSON configuration, and re-establish all connections. This allows field engineers to update tag configurations without restarting the gateway service.

What machineCDN Brings to the Table​

machineCDN's edge infrastructure handles this entire discovery and connection management lifecycle automatically. When you deploy a machineCDN gateway on the plant floor:

• It auto-detects PLCs across EtherNet/IP and Modbus TCP/RTU simultaneously
• It loads the correct device configuration from its library of supported equipment types
• It manages connection resilience with automatic reconnection and buffer management
• It optimizes Modbus reads by grouping contiguous registers and minimizing request count
• Tag data flows through a batched delivery pipeline to the cloud, with store-and-forward buffering during connectivity gaps

For plant engineers, this means going from "cable plugged in" to "live data flowing" in minutes rather than days of manual register mapping.

Key Takeaways​

1. Always try EtherNet/IP first — it's faster and provides richer device identity information than Modbus
2. Don't hardcode serial number locations — they vary wildly across equipment families, even from the same vendor
3. Validate serial numbers before accepting a device — zero year values indicate bad reads
4. Group Modbus reads by contiguous address and function code, but cap at 50 registers per request
5. Implement connection watchdogs — industrial networks are unreliable; your gateway must recover automatically
6. Flush after errors — stale buffer bytes from partial Modbus reads are the silent killer of data integrity

The device discovery problem isn't glamorous, but getting it right is what separates an IIoT platform that works in the lab from one that survives on a real plant floor.

If you've ever connected to an Allen-Bradley Micro800 or CompactLogix PLC, you've used EtherNet/IP — whether you knew it or not. It's one of the most widely deployed industrial Ethernet protocols in North America, and for good reason: it runs on standard Ethernet hardware, supports TCP/IP natively, and handles everything from high-speed I/O updates to configuration and diagnostics over a single cable.

But EtherNet/IP is more than just "Modbus over Ethernet." Its underlying protocol — the Common Industrial Protocol (CIP) — is a sophisticated object-oriented messaging framework that fundamentally changes how edge devices, gateways, and cloud platforms interact with PLCs.

This guide covers what plant engineers and IIoT architects actually need to know.

If you've ever tried to pull real-time data from an Allen-Bradley PLC over EtherNet/IP and found yourself staring at timeouts, missed packets, or inexplicable latency spikes — you've probably run into the implicit vs. explicit messaging divide without realizing it.

EtherNet/IP is one of the most widely deployed industrial Ethernet protocols, yet the nuances of its messaging model trip up even experienced automation engineers. This guide breaks down what actually matters when you're connecting PLCs to edge gateways, SCADA systems, or IIoT platforms like machineCDN.

CIP: The Protocol Inside the Protocol​

EtherNet/IP is really just a transport wrapper around the Common Industrial Protocol (CIP). CIP is the application layer that defines how devices discover each other, exchange data, and manage connections. Understanding CIP is understanding EtherNet/IP — everything else is TCP/UDP plumbing.

CIP organizes everything into objects. Every device has a set of objects, each with attributes you can read or write. The key objects you'll encounter:

When your edge gateway reads a tag like capacity_utilization from a Micro800 or CompactLogix PLC, it's ultimately reading an attribute from a CIP object — the protocol just hides this behind a friendlier tag-name interface.

Explicit Messaging: The Request-Response Model​

Explicit messaging is CIP's "ask and receive" mode. Your client sends a request over TCP port 44818, the device processes it, and sends a response. It's conceptually identical to an HTTP GET — connected, reliable, and sequential.

How It Actually Works​

1. TCP handshake with the PLC on port 44818
2. RegisterSession — establishes a CIP session, returns a session handle
3. SendRRData (Send Request/Reply Data) — wraps your CIP service request
4. Device processes the request and returns a response in the same TCP connection

For tag reads on Logix-family controllers, the path typically encodes:

• Protocol type (e.g., ab-eip for Allen-Bradley EtherNet/IP)
• Gateway IP — the PLC's network address
• CPU type — Micro800, CompactLogix, ControlLogix, etc.
• Tag name — the symbolic name of the data point
• Element size and count — how many bytes per element, how many elements to read

A typical read might look like:

protocol=ab-eip
gateway=192.168.1.50
cpu=compactlogix
name=Temperature_Zone1
elem_size=4
elem_count=1

This tells the stack: "Connect to the CompactLogix at 192.168.1.50, find the tag named Temperature_Zone1, read one 4-byte (32-bit float) element."

Explicit Messaging Characteristics​

• Latency: 2-10ms per request on a quiet network, 20-50ms under load
• Throughput: Sequential — you can't pipeline requests on a single connection
• Best for: Configuration reads, diagnostics, infrequent data access
• Max payload: 504 bytes per CIP service response (can be extended with Large Forward Open)
• Reliability: TCP-based, guaranteed delivery

The Hidden Cost: Tag Creation Overhead​

Here's something that catches people off guard. On Logix controllers, the first time you read a symbolic tag, the controller has to resolve the tag name to an internal address. This resolution can take 5-15ms. Subsequent reads on the same connection are faster because the tag handle is cached.

If your gateway creates and destroys connections frequently (say, on each poll cycle), you're paying this resolution cost every single time. A well-designed gateway keeps connections persistent and caches tag handles across read cycles. This alone can cut your effective read latency by 40-60%.

Implicit Messaging: The Real-Time Streaming Model​

Implicit messaging is where EtherNet/IP earns its keep in real-time control. Instead of request-response, data flows continuously via UDP multicast or unicast without the overhead of individual requests.

The Connection Setup​

Implicit connections are established through an explicit messaging sequence:

1. Forward Open request (via TCP) — negotiates the connection parameters
2. Both sides agree on:
   • RPI (Requested Packet Interval) — how often data is produced, in microseconds
   • Connection path — which assembly objects to bind
   • Transport type — Class 1 (with sequence counting) or Class 3
   • Connection size — max bytes per packet
3. Once established, data flows via UDP port 2222 at the agreed RPI

RPI: The Most Misunderstood Parameter​

The Requested Packet Interval is essentially your sampling rate. Set it too fast and you'll flood the network with redundant data. Set it too slow and you'll miss transient events.

The golden rule: Your RPI should match your actual process dynamics, not your "just in case" anxiety. A temperature sensor that changes over minutes doesn't need a 10ms RPI — 500ms is plenty.

For IIoT monitoring scenarios, RPIs of 100ms to 1000ms are typically appropriate. You're tracking trends and detecting anomalies, not closing servo loops. Platforms like machineCDN are designed to ingest data at these intervals and apply server-side intelligence — the edge gateway doesn't need millisecond resolution to detect that a motor bearing temperature is trending upward.

Implicit Messaging Characteristics​

• Latency: Deterministic — data arrives every RPI interval (±jitter)
• Throughput: Concurrent — hundreds of connections can stream simultaneously
• Best for: Cyclic I/O data, real-time monitoring, control loops
• Transport: UDP — no retransmission, but sequence numbers detect missed packets
• Multicast: Multiple consumers can subscribe to the same producer

Scanner/Adapter Architecture​

In EtherNet/IP, the device that initiates the implicit connection is the scanner (typically the PLC or an HMI), and the device that responds is the adapter (typically an I/O module, drive, or remote rack).

Why This Matters for Edge Gateways​

When you connect an IIoT edge gateway to a PLC, the gateway typically acts as an explicit messaging client — it reaches out and reads tags on demand. It is not acting as a scanner or adapter in the implicit sense.

This is an important architectural distinction:

• Scanner mode would require the gateway to manage Forward Open connections and consume I/O assemblies — complex, but gives you real-time streaming data
• Explicit client mode is simpler — poll tags at your desired interval, get responses, publish to the cloud

Most IIoT gateways (including those powering machineCDN deployments) use explicit messaging with intelligent polling. Why? Because:

1. Simplicity — No need to configure assembly objects on the PLC
2. Flexibility — You can read any tag by name, not just pre-configured assemblies
3. Non-intrusion — No modifications to the PLC program required
4. Sufficient performance — For monitoring (not control), 1-60 second poll intervals are fine

When to Use Implicit Messaging for IIoT​

There are cases where implicit messaging makes sense even for monitoring:

• High tag counts — If you're reading 500+ tags from a single PLC, implicit is more efficient
• Sub-second requirements — Process alarms that need under 100ms detection
• Multicast scenarios — Multiple systems need the same data simultaneously
• Deterministic timing — You need guaranteed delivery intervals for SPC/SQC

Data Types and Byte Ordering​

EtherNet/IP inherits CIP's data type system. When reading tags, you need to know the data width:

Byte order is little-endian for CIP. This trips up engineers coming from Modbus (which is big-endian). If you're bridging between the two protocols, you'll need byte-swap logic at the translation layer.

For array reads, the element size matters for offset calculation. Reading element N of a 32-bit array means the data starts at byte offset N * 4. Getting this wrong produces garbage values that look plausible (they're the right data type, just from the wrong array position), which makes debugging painful.

Connection Timeouts and Keepalive​

One of the most common production issues with EtherNet/IP is connection timeout cascades. Here's how they happen:

1. Network blip causes one packet to be delayed
2. PLC times out the connection (default: 4x the RPI)
3. Gateway has to re-register the session and re-read tags
4. During re-establishment, tag handles are lost — all tag names need re-resolution
5. While reconnecting, data gaps appear in your historian

Mitigation Strategies​

• Set realistic timeout multipliers. The CIP standard allows up to 255x the RPI as a timeout. For monitoring, use generous timeouts (e.g., 10-30 seconds) rather than tight ones.
• Implement exponential backoff on reconnection. Hammering a PLC with connection requests during a network event makes things worse.
• Cache tag handles and attempt to reuse them after reconnection. Some PLCs allow this; others invalidate all handles on session reset.
• Use a connection watchdog — if no data arrives for N intervals, proactively reconnect rather than waiting for the timeout to expire.
• Monitor connection statistics at the Ethernet Link object (Class 0xF6) — rising error counters often predict connection failures before they happen.

Practical Performance Benchmarks​

Based on real-world deployments across plastics manufacturing, HVAC, and process control:

Key insight: PLC CPU impact scales with request frequency, not tag count. Reading 200 tags in one optimized request every 5 seconds has less impact than reading 10 tags every 100ms.

Tag Grouping Optimization​

When reading multiple tags, group them by:

1. Data type and element count — Same-type tags can sometimes be read more efficiently
2. Program scope — Tags in the same program/task on the PLC share routing paths
3. Read interval — Don't poll slow-changing configuration values at the same rate as process variables

A well-optimized gateway might use three polling groups:

• Fast (1-5 sec): Machine state booleans, alarm bits, running status — values that trigger immediate action
• Medium (30-60 sec): Process variables — temperatures, pressures, flow rates, RPMs
• Slow (5-60 min): Configuration and identity — firmware version, serial number, device type

This tiered approach reduces network traffic by 60-80% compared to polling everything at the fastest interval.

Common Pitfalls​

1. Forgetting About CPU Type​

The CIP service path differs by controller family. A request formatted for CompactLogix won't work on a Micro800, even though both speak EtherNet/IP. Always verify the CPU type during gateway configuration.

2. Array Index Confusion​

Some PLCs use zero-based array indexing, others use one-based. If you request MyArray[0] and get an error, try [1]. Better yet, test with known values during commissioning.

3. String Tags​

CIP string tags have a length prefix followed by character data. The total allocation might be 82 bytes (2-byte length + 80 characters), but only the first length characters are valid. Reading the raw bytes without parsing the length field gives you garbage padding at the end.

4. Assuming All Controllers Support Symbolic Access​

Older SLC 500 and PLC-5 controllers use file-based addressing (e.g., N7:0, F8:3), not symbolic tag names. Your gateway needs to handle both addressing modes.

5. Ignoring Forward Open Limits​

Every PLC has a maximum number of concurrent CIP connections (typically 32-128 for CompactLogix, more for ControlLogix). If your gateway, HMI, SCADA, historian, and three other systems all connect simultaneously, you can hit this limit — and the symptom is intermittent connection refusals.

Choosing Your Messaging Strategy​

For the vast majority of IIoT monitoring and predictive maintenance scenarios — the use cases machineCDN was built for — explicit messaging with smart polling is the right choice. It's simpler to deploy, doesn't require PLC program changes, and delivers the data fidelity you need for trend analysis and anomaly detection.

What's Next​

EtherNet/IP continues to evolve. The Time-Sensitive Networking (TSN) extensions coming in the next revision will blur the line between implicit and explicit messaging by providing deterministic delivery guarantees at the Ethernet layer itself. This will make EtherNet/IP competitive with PROFINET IRT for hard real-time applications — but for monitoring and IIoT, the fundamentals covered here will remain relevant for years to come.

machineCDN connects to EtherNet/IP controllers natively, handling tag resolution, connection management, and data batching so your team can focus on process insights rather than protocol plumbing. Learn more →

If you've spent time on a plant floor wiring up Allen-Bradley PLCs, you've used EtherNet/IP — whether you realized you were speaking CIP or not. But most engineers treat the protocol like a black box: plug in the cable, configure the scanner, pray the I/O updates arrive on time.

This guide breaks open how EtherNet/IP actually works at the protocol level — the CIP object model, the difference between implicit and explicit messaging, how tag-based addressing resolves data paths, and the real-world timing constraints that catch teams off guard during commissioning.

EtherNet/IP is everywhere in North American manufacturing — from plastics auxiliary equipment to automotive assembly lines. But the protocol's layered architecture confuses even experienced controls engineers. What's the actual difference between implicit and explicit messaging? When should you use connected vs unconnected messaging? And how does CIP fit into all of it?

This guide breaks down EtherNet/IP from the wire up, with practical configuration considerations drawn from years of connecting real industrial equipment to cloud analytics platforms.