Symptom
A PLC, drive, or remote I/O device on Ethernet loses communication for seconds or minutes, then recovers without intervention.
The short answer
Ethernet Device Drops Offline
An industrial Ethernet device that intermittently drops offline is most often caused by a duplex mismatch, a marginal cable or connector, a spanning tree topology change, a duplicate IP address, or a power problem at the device. Managed switch port statistics identify the cause quickly: errors and late collisions indicate duplex mismatch, CRC errors indicate cabling, and repeated link transitions indicate a physical or power problem.
Key points
- Managed switch port counters answer this faster than any other single step.
- Late collisions on a full-duplex link mean a duplex mismatch, every time.
- CRC and alignment errors point at the cable, the connector, or noise.
- Repeated link up and down events point at physical connection or device power.
- A duplicate IP address produces intermittent, confusing symptoms on both devices.
Possible causes and what to check
| Possible cause | What to check |
|---|---|
| Duplex mismatch | One end auto-negotiating, the other hard-set. Look for late collisions and FCS errors on the port. |
| Marginal cable or connector | Check CRC and alignment error counters. Inspect the connector, verify the cable is not run beyond 100 metres, and confirm it is not damaged. |
| Spanning tree topology change | Review switch logs for topology change notifications. A redundant path reconverging drops traffic briefly. |
| Duplicate IP address | Look for ARP conflict messages. Disconnect the suspect device and ping its address; a response means something else is using it. |
| Power problem at the device | Repeated link up and down with no error counters usually means the device is losing power or resetting. |
| Broadcast or multicast storm | Check port utilization and broadcast counters. EtherNet/IP implicit messaging without IGMP snooping can flood a network. |
| Switch port failure | Move the device to a different port. Fast, conclusive, and often overlooked. |
| Fiber loss or dirty connector | On a fiber uplink, measure optical power against the receiver sensitivity and clean the connectors. |
| Overloaded device connection limit | Some controllers support limited concurrent connections. Excess polling clients exhaust them. |
| Noise coupling into copper | Cable in a tray with drive output conductors. Correlate drops with drive operation. |
Read the switch counters first
If the device is on a managed switch, the port statistics will usually tell you what is wrong before you touch anything. This is the single strongest argument for managed switches in an industrial network, and it is why an unmanaged switch on a critical path is a false economy.
| Counter increasing | Means | Do this |
|---|---|---|
| Late collisions | Duplex mismatch. This is essentially diagnostic. | Set both ends the same: auto on both, or hard-set on both |
| FCS / CRC errors | Corrupted frames from cabling or noise | Inspect and test the cable; check routing away from drive cables |
| Alignment errors | Physical layer problem | Same as CRC errors |
| Runts or giants | Malformed frames, often from a failing NIC | Substitute the device or its port |
| Link flaps | Physical connection or device power | Check the connector, then the device power supply |
| Broadcast rate high | Storm, loop, or missing IGMP snooping | Check spanning tree state and multicast configuration |
| Discards on a full port | Congestion | Check whether the port is genuinely saturated |
The duplex mismatch trap
It arises when one end is set to auto-negotiate and the other is hard-configured. The auto end cannot detect duplex without a negotiating partner, so it defaults to half duplex while the fixed end runs full. The link comes up, small amounts of traffic pass fine, and under load it degrades badly.
The symptom set is distinctive: the device works when idle, fails under load, and the failures do not correlate with anything obvious. Set both ends to auto-negotiate, or hard-set both ends identically. Never mix the two, which is exactly what a well-intentioned "let me lock this down to 100 full" change produces.
Diagnostic procedure
- 1
Establish the pattern
How long is it offline, how often, and does it correlate with anything? A drop every time a large motor starts is a different problem from a drop every forty minutes.
- 2
Check the switch port counters
Look at errors, collisions, and link flap history. This is where the answer usually is.
- 3
Verify speed and duplex on both ends
Confirm the negotiated result, not just the configuration, and confirm both ends agree.
- 4
Check for duplicate IP
Look for ARP conflict entries in switch or device logs. Disconnect the device and ping its address; a reply identifies the conflict immediately.
- 5
Move to a different port
Isolates a failing switch port in about a minute.
- 6
Substitute the cable
A known-good patch cable eliminates the most common physical cause. Do not skip this because the cable "was fine yesterday".
- 7
Check device power
Link flaps with no error counters usually mean the device is resetting. Check the power supply loading and any shared circuit.
- 8
Review spanning tree
A ring or redundant path reconverging causes brief loss across the network. Check for topology change events and confirm the design is what you think it is.
- 9
Capture packets if needed
A mirror port and a capture during a drop shows exactly what stopped and in which direction, which ends most disputes about where the fault lies.
Industrial-specific causes
- EtherNet/IP multicast
- Implicit I/O messaging uses multicast. Without IGMP snooping and a querier, multicast floods every port and can saturate a network. The symptom is widespread intermittent trouble that worsens as devices are added.
- Connection limits
- Controllers support a finite number of concurrent connections. A SCADA system, an engineering workstation, and several HMIs polling one controller can exhaust them, and new connections are refused.
- Ring redundancy protocols
- Device-level ring and similar protocols recover quickly but a misconfigured ring, or a ring with a device that does not participate correctly, produces recurring topology events.
- Fiber degradation
- A fiber link that worked at installation can degrade from a dirty or damaged connector. Measure received optical power and compare against the receiver sensitivity, with margin.
- Environmental
- Panel temperature, vibration loosening an RJ45, and moisture in an outdoor enclosure all produce genuinely intermittent physical faults that no configuration change will fix.
What to fix permanently
- Standardize on auto-negotiation everywhere, and document any exception with a reason.
- Use managed switches on any path that matters, and actually collect their statistics into SCADA.
- Enable IGMP snooping with a querier where EtherNet/IP implicit messaging is used.
- Keep Ethernet out of trays and conduits carrying drive output conductors.
- Use industrial-rated connectors and cable in panels subject to vibration.
- Document the network with a real drawing, including VLANs, spanning tree roles, and uplinks.
- Alarm on switch port link state for critical devices, so a flap is visible rather than inferred.
Frequently asked questions
- What causes late collisions on a full-duplex link?
- A duplex mismatch. One end is running half duplex, almost always because it is auto-negotiating against a hard-set partner. Set both ends the same way.
- How do I find a duplicate IP address?
- Look for ARP conflict messages in device or switch logs. The simplest field test is to disconnect the suspect device and ping its address. If something answers, another device is using it.
- Should I hard-set speed and duplex on industrial devices?
- Only if both ends are hard-set identically and it is documented. Auto-negotiation on both ends is reliable on modern equipment and avoids the mismatch that causes most of these problems.
- Why does my network fail when I add more devices?
- On an EtherNet/IP network, usually multicast flooding without IGMP snooping. It can also be controller connection limits, or a genuinely saturated uplink. Check switch port utilization and multicast rates.
Related topics
- Switch Port Errors IncrementingSwitch Port Errors Incrementing — practical reference notes for controls engineers, integrators, and technicians working with network troubleshooting.
- Duplicate IP AddressDuplicate IP Address — practical reference notes for controls engineers, integrators, and technicians working with network troubleshooting.
- Troubleshoot EthernetTroubleshoot Ethernet — practical reference notes for controls engineers, integrators, and technicians working with network how-to.
- EtherNet/IPCIP over Ethernet: implicit I/O, explicit messaging, and RPI.
- Intermittent Packet LossIntermittent Packet Loss — practical reference notes for controls engineers, integrators, and technicians working with network troubleshooting.
- Cannot Ping Across VLANsCannot Ping Across VLANs — practical reference notes for controls engineers, integrators, and technicians working with network troubleshooting.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.