A 5094-AENTR that runs clean for days or weeks, then drops and reconnects in bursts, has a physical-layer problem on the path back to the controller. A rising FCS error count on the EN2TR it talks to confirms that frames are arriving corrupted. The adapter and base are already swapped, so stop replacing hardware. Check speed/duplex settings on every link in the path first, then cabling and noise.
Read the EN2TR counters before you touch hardware
A high connection-timeout count on the EN2TR is the result. A high FCS count on the same port is the cause you can act on. Pull the port diagnostics from the EN2TR web page or the module properties in Studio 5000. Record every media counter, not just FCS.
- FCS errors: frames whose CRC failed. The frame was damaged between transmitter and receiver.
- Alignment errors: frames that were not a whole number of octets. These usually come from the same corruption.
- Late collisions: collisions detected after the first 64 bytes. On a switched network, these point straight at a duplex mismatch.
- Single/multiple collisions: any nonzero count on a modern switched link means one end is running half duplex.
- Connection timeouts: I/O connections the scanner gave up on because packets stopped arriving within the timeout window.
| What the counters show | Most likely cause | First action |
|---|---|---|
| FCS/alignment errors on one side, late collisions on the other | Speed/duplex mismatch: one end forced, one end auto-negotiating | Match port configuration on both ends |
| FCS errors, no collisions, bursts track motor or drive activity | Induced noise on the cable | Reroute the cable away from VFD output and motor leads; check shield termination |
| FCS errors steady or rising slowly, worse with vibration or temperature | Damaged cable, bad termination, or failing patch cord/jack | Certify or replace the cable run |
| Timeouts with zero FCS and zero collisions | Not physical: IP conflict, network loop, or traffic storm | Check for duplicate IPs and switch broadcast counters |
| Timeouts on the AENTR only, Stratix 5400 on the same supply stays up | Power is unlikely but not ruled out | Log the supply only after the network checks come back clean |
Confirm one thing before you trust the EN2TR counters: which device is physically plugged into that EN2TR port. The EN2TR only counts errors on its own link. If the AENTR connects through the Stratix 5400, the EN2TR FCS count describes the EN2TR-to-switch cable, not the switch-to-AENTR cable. Pull the port counters on the Stratix (Device Manager, or show interfaces on the CLI) and find the port where errors are climbing.
Why corrupted frames turn into dropped I/O connections
EtherNet/IP I/O connections use UDP at a fixed RPI. There is no retransmit. A frame that fails CRC is discarded silently at the receiver. One lost packet does nothing. A burst of lost packets that runs longer than the connection timeout (RPI multiplied by the timeout multiplier, both visible in the module's connection properties) closes the connection. The controller flags the module faulted, reopens the connection, and the cycle repeats while the bad condition lasts. That produces the symptom: long quiet stretches, then a spree of drop/reconnect.
A duplex mismatch fits this pattern well. With one end forced to 100 Mb/full and the other left on auto, the auto side cannot negotiate. It falls back to the parallel-detected speed at half duplex. At low traffic, both ends rarely transmit at the same moment and the link looks healthy. When traffic rises, from a burst of messaging, a laptop going online, or HMI polling, the half-duplex side sees late collisions and aborts frames. The full-duplex side receives the truncated frames as FCS errors. Traffic-driven bursts look random from the panel.
Noise works the same way but tracks electrical events instead. Drive starts, contactor operation, and welding put transients on unshielded or poorly routed cable. The resulting errors cluster with those events.
Match speed and duplex on every link first
This check takes minutes and settles the most common cause. Do it before you pull any cable.
- Map the path: EN2TR port → any switch ports → AENTR port. Write down each link.
- For each end of each link, read the configured setting (auto-negotiate or forced) and the negotiated result (speed and duplex actually in use). On the EN2TR and AENTR, read this from the port configuration and diagnostics pages. On the Stratix 5400, read it from the port status.
- Flag any link where one end is forced and the other is on auto. Flag any link that reports half duplex.
- Set both ends of each link the same way. Use auto-negotiate on both ends unless a site standard requires fixed settings. In that case, force both ends to identical speed and duplex. Never force only one side.
- Record the error counters immediately after the change so you have a clean baseline.
Chase the cable and noise path next
If duplex matches everywhere and FCS keeps climbing on one specific link, the problem is in that cable run.
- Walk the run. Look for Ethernet cable bundled with or crossing parallel to VFD output, motor leads, or high-current AC. Cross power at 90 degrees and separate parallel runs.
- Inspect every termination: field-made RJ45 plugs, bulkhead couplers, patch panels. Crimped plugs with untwisted pairs pulled back too far are a frequent source of marginal links.
- Check shield handling. A shielded cable with the shield bonded at points of different ground potential can carry noise current. An unshielded cable in a drive-heavy panel has no protection. Follow the installation guidance in Rockwell's EtherNet/IP media planning documentation for your cable type.
- Swap the patch cords at both ends with known-good, factory-made cords. This is cheap and fast.
- If the run is permanent cabling, test it with a cable certifier rather than a continuity tester. A continuity tester passes cables that fail under load.
- Correlate error bursts with production. If FCS jumps when a particular drive starts, you have found your noise source.
Prove the link stays clean before you close it out
An intermittent fault that took weeks to appear needs weeks of evidence to call fixed.
- Record the FCS, alignment, and collision counts on every port in the path right after the fix. Check them daily and track the change, not the absolute value, because counters accumulate from power-up.
- Expect zero growth on FCS and collisions on a healthy switched link. Any steady increase means the fault is still there.
- Confirm the negotiated result shows the same speed and full duplex on both ends of every link.
- Watch the connection-timeout count on the EN2TR. It should stop increasing entirely.
- Run through at least one full production cycle that includes the heaviest drive activity and the busiest network traffic.
Skip the fixes that burn time on 5094 adapters
- More hardware swaps. The adapter and base are already replaced with no change. A third adapter will not fix a cable or a port setting.
- The power supply before the network. A Stratix 5400 on the same supply that never drops makes a supply fault unlikely. FCS errors are a data-integrity symptom, not a brownout symptom. Log the supply only if the network checks come back clean.
- Raising the RPI or timeout multiplier. This hides the corruption and slows your I/O. The errors remain and will return as the fault gets worse.
- Reading the wrong port. Errors on the EN2TR only describe the cable plugged into the EN2TR. Chase the counters hop by hop.
- Both AENTR ports cabled with no ring configured. The 5094-AENTR has two ports and an embedded switch. Without an active DLR supervisor, cabling both ports back into the network creates a loop and a broadcast storm. That causes timeouts with clean FCS counts. With no ring in use, use one port as the uplink, or configure DLR properly.
- Adding a ring to fix the drops. DLR recovers from a broken link. It does not correct a link that stays up while corrupting frames.
FAQ
Why does a 5094-AENTR drop connection only occasionally instead of all the time?
A marginal link corrupts frames only under certain conditions, such as high traffic on a duplex-mismatched port or electrical noise when drives start. The I/O connection times out only when the lost packets span longer than RPI multiplied by the timeout multiplier, so short error bursts pass unnoticed and long ones cause a drop.
Why does the EN2TR show FCS errors when the module has already been replaced?
FCS errors describe frames damaged on the wire, not a faulty endpoint. Replacing the adapter or base does not change the cable, terminations, noise exposure, or port speed/duplex settings. Those are the elements to check.
Why does forcing speed and duplex on one end cause FCS errors?
The auto-negotiating end cannot negotiate with a forced port, so it falls back to half duplex while the forced end runs full duplex. Under load, the half-duplex side logs late collisions and aborts frames, and the full-duplex side counts those truncated frames as FCS errors. Set both ends to auto, or force both to identical values.
When should I escalate a 5094-AENTR dropout to Rockwell Automation support?
Escalate when every link in the path shows matched full duplex, the FCS and collision counts have stopped growing, and connection timeouts still occur. Also escalate if errors follow the adapter port across known-good cables and switch ports. Before you open the case with Rockwell Automation Technical Support, collect the port counters from every device, the firmware revisions, and the timestamps of the drops.