Find the fault at the right communication layer

Hello friends, troubleshooting an EtherNet/IP network takes more than replacing a cable or restarting a device. In a system using EtherNet/IP, the physical link, IP reachability, CIP connection and device application state need separate checks. Understanding how the protocol works helps explain why a reachable device can still report an I/O fault.

Establish the scope and timing first

Is one device affected, several devices on the same switch, or the entire line? Did the problem begin during commissioning, after a replacement, or when a motor started? Record the fault code, timestamp and latest change. In industrial automation applications, a shared power supply or uplink fault can trigger several apparently unrelated alarms at once.

Check power, cabling and port counters together

Check device power, Link/Activity indicators, connectors and EtherNet/IP cabling. Read the product manual for MS/NS LED meanings. On a managed switch, inspect link transitions, FCS/CRC errors, dropped packets, speed and duplex. Look for counter increases over a known interval before judging a cumulative total. Rising FCS errors suggest cabling, termination or interference problems; discards can also reflect queue or resource limitations. A single counter is not a conclusive diagnosis.

A correct IP address does not guarantee the correct path

Compare the IP address, subnet mask, gateway where needed, and VLAN membership in the network configuration. Investigate duplicate IP addresses using MAC addresses and switch records. Confirm that DHCP/BOOTP or static addressing produces the intended result after a restart. In terms of the OSI layers, a Link LED indicates a physical link; it does not validate the VLAN or application access.

What can CIP objects tell you?

Explicit messaging uses CIP services to access object attributes. The Identity Object, class 0x01, provides device identity and general status; the TCP/IP Interface Object, 0xF5, exposes IP configuration; and the Ethernet Link Object, 0xF6, provides port information and supported counters. The Connection Manager, 0x06, handles connections and supported connection statistics. The Assembly Object, 0x04, groups I/O data. A class number alone is insufficient: select the instance, attribute, access permissions and supported services from the manual.

Diagnostic detail varies between communicating devices. Additional vendor-specific objects may be available. For example, Schneider Electric's TeSys Tera manual defines timeout and refused-connection counters in its adapter diagnostics. Do not assume that every EtherNet/IP device implements these vendor-specific details.

Separate a rejected connection from a connection that drops

If a Forward Open request is rejected, record the CIP General Status and Additional Status. Compare the configured device identity, firmware compatibility, Electronic Keying, Assembly instance numbers, I/O data lengths and available connection resources. Standards compliance does not guarantee that every application data size or device profile will match. Check the EDS and selected device profile as well.

Disabling keying removes a compatibility check; it does not resolve the mismatch. Investigate identity differences after a replacement, and remember that changing keying online can interrupt connections. If a connection establishes successfully and later times out, investigate data delivery and load. This distinction helps you interpret the fault screens in diagnostic software.

Understand RPI, timeout and actual data updates

RPI, Requested Packet Interval, is the requested I/O production interval; it is not the PLC program scan time. A smaller RPI increases packet frequency and processing load. For a cyclic stream in one direction, a 20 ms interval represents approximately 50 updates per second; 2 ms represents 500. Assess bandwidth and latency alongside the number of devices and connections.

The connection timeout is not the same as the RPI. Read the actual limit from the relevant connection parameters. Consider performance and resource limits before reducing the RPI. An unnecessarily large RPI can contribute to brief state changes being missed by the application. Increasing a timeout does not remove the cause of lost packets.

Check multicast delivery and switch load

Where multicast I/O is used, inspect IGMP snooping, group memberships and the querier serving the relevant VLAN. Traffic should reach the ports that need it; unnecessary flooding can increase load. Do not assume multicast settings are responsible for a connection using unicast. Assess uplink utilization, queue discards and supported SNMP records against the application's communication requirements. SNMP support is not universal among end devices.

A DLR ring can remain operational while faulted

For a Device Level Ring network, read the active ring supervisor, ring status and available fault-location information. Continued communication does not prove that the ring is healthy. An alternative path can sustain communication after one path failure; a second break can partition the network. DLR does not restore the failed device's own function. Two Ethernet ports do not automatically imply DLR support; verify the topology and supervisor configuration before closing a ring.

Capture the right traffic with Wireshark

Use port mirroring/SPAN on the relevant switch port or a suitable network TAP. A computer connected to an ordinary switched port generally cannot see unicast traffic between two other devices. Distinguish the EtherNet/IP port numbers: conventional explicit communication uses TCP 44818, while cyclic I/O uses UDP 2222. Discovery services also use UDP 44818.

Example display filters are enip || cip, tcp.port == 44818, udp.port == 2222 and ip.addr == 192.168.1.20. Replace the example IP address with your device's address. Inspect CIP error responses, repeated connection-opening requests and I/O packet intervals. Do not look for TCP retransmissions in UDP I/O traffic. Also distinguish capture loss at the computer or mirror port from loss in the production network.

Turn each symptom into the next measurement

Ping works, but I/O does not: inspect CIP status, Assembly size, connection ownership and the UDP path. Modbus TCP and EtherNet/IP are different protocols; a response from one service does not validate the other.

Communication drops when a drive starts: record supply dips, cable routing and port-error increases over the same interval. This correlation is an investigative lead, not proof of interference.

A replacement device will not connect: compare identity, firmware, keying and the I/O profile. The connection is healthy, but the motor will not run: check local/remote selection, permissives and device faults before attributing the problem to the network.

CIP Safety and CIP Security serve different purposes

CIP Safety provides functional safety mechanisms for detecting communication errors between supporting safety devices. CIP Security addresses cybersecurity capabilities such as authentication, integrity and confidentiality, depending on the supported profile. Neither is automatically available in every EtherNet/IP device. Treat functional safety and cybersecurity separately when assessing network-specific security measures.

Verify the repair under the original operating conditions

Save existing records before restarting devices or clearing counters. Compare timestamps in the supported web interface, event logs and PLC diagnostics. Make one change at a time, then monitor fresh counter increases, connection status and data freshness under the load and conditions that caused the fault. One successful connection does not prove that an intermittent fault has been eliminated.