Capturing EtherNet/IP Traffic from an Allen-Bradley 842E

A laptop connected to the same managed switch as an Allen-Bradley 842E encoder will not automatically see the encoder’s cyclic traffic. A switch normally forwards unicast frames only toward the destination port. The analyzer can therefore show almost nothing while the controller reports an I/O timeout.

A useful capture starts with a testable fault hypothesis and a capture point that can observe the relevant frames.

Define the question before collecting packets

Write the symptom in measurable terms. Examples include a connection timeout during a particular machine transition, an encoder value that stops changing, repeated reconnection, or position data that arrives later than the controller expects. Record the controller fault code, time, encoder indicators, and switch-port state.

Decide what evidence would support or reject each hypothesis. If the question is whether frames leave the encoder, mirror the encoder-facing port. If it is whether they reach the controller uplink, observe that link. Capturing only one side of an intermediate switch cannot always localize the loss.

Encoder hardware can be reviewed in the Sensors collection, while managed switches and network adapters are grouped under Communication & Networking.

Understand the 842E network path

Rockwell Automation documents the 842E as an EtherNet/IP absolute encoder family with dual Ethernet ports for supported linear and Device Level Ring topologies. The exact catalog and project configuration determine the data connection, assembly, requested packet interval, and diagnostic behavior.

Document both physical ports, IP settings, controller connection, topology, firmware, and whether Device Level Ring is active. In a linear topology, a downstream cable or device can affect traffic through the encoder. In a ring, a topology event adds evidence that must be correlated with the connection fault.

Do not assume that the port nearest the controller is always the only useful capture point. Draw the actual path, including switch ports, uplinks, ring supervisor, media converters, and any redundant routes.

Select a nonintrusive capture method

A managed-switch mirror session is usually the least disruptive method. Configure the source as the encoder port, controller port, or uplink needed by the hypothesis. Set the analyzer-facing port as the destination and confirm whether the switch mirrors ingress, egress, or both.

A purpose-built passive network tap is another option when the architecture and outage procedure permit it. Do not insert an unmanaged switch or ordinary office hub into a running control path. That change can alter topology, quality of service, multicast handling, link negotiation, and fault timing.

Use a dedicated analyzer interface. Disable unnecessary protocols and services where the operating procedure allows. The analyzer should observe, not advertise devices, request addresses, or become another control-network participant.

Verify that the mirror is telling the truth

Generate or identify one known frame and confirm it appears on the analyzer. Check that both directions are visible when required. A mirror session may omit physical-layer errors, drop packets when the destination port is oversubscribed, or copy only one direction.

Compare source-port speed with the mirror destination’s capacity. Mirroring both directions of a busy gigabit uplink into one gigabit port can exceed the destination bandwidth. Narrow the source or capture window rather than assuming every gap occurred on the control network.

Record the switch model, firmware, mirror configuration, source port, destination port, VLAN behavior, and capture-interface settings. Without that record, another engineer cannot reproduce the measurement.

Separate EtherNet/IP traffic classes

EtherNet/IP uses explicit messaging for connection management, configuration, and diagnostics, while cyclic I/O commonly uses UDP transport. Discovery exchanges are not proof that an established I/O connection is healthy. Preserve the connection setup and teardown around the fault, not only the cyclic packets.

Start with the known encoder and controller IP addresses. Then identify the relevant connection rather than labeling every UDP frame as encoder data. Common EtherNet/IP ports can help narrow the trace, but endpoints, timing, and connection context provide stronger evidence.

Keep ARP, topology, and switch-management evidence around the event. An address conflict or link transition may appear outside the filtered I/O stream. Save the unfiltered capture and use display filters for analysis so context is not discarded permanently.

Analyze RPI timing and gaps

The requested packet interval defines the expected update cadence for the configured I/O connection. Measure inter-arrival time over a healthy period and around the fault. Look for missing intervals, bursts after a pause, duplicated sequence behavior, and a connection close or reopen.

Do not treat every packet later than the nominal RPI as a controller fault. Compare the observed gap with the connection timeout behavior configured in the controller. A few microseconds of variation and a multi-interval outage have different meanings.

Graph packet arrival time beside the controller’s fault bit, task state, machine event, and switch logs. If the packet stream stops before a link-down event appears, the source device or upstream path deserves attention. If the mirror continues to see encoder frames while the controller times out, investigate the remaining path and controller processing.

Use switch evidence with the trace

Read port counters before and after the test. CRC or frame-check errors, link transitions, dropped packets, speed changes, and ring events can explain a packet gap. A packet analyzer attached above the faulty link may never receive corrupted frames because the switch discards them.

Check cable and connector condition, shield and grounding practices, bend radius, contamination, and strain. Swap one controlled component only after preserving the baseline. Replacing several cables and switch settings together destroys the ability to identify the cause.

Confirm negotiated speed and duplex according to the supported device configuration. Avoid forcing settings without consulting the encoder and switch manuals. A mismatch may create errors that appear load-dependent.

Protect the capture and the network

Limit capture duration or use a ring buffer so the analyzer disk does not fill. Mark the exact local and plant time. Packet traces can reveal addresses, device names, configuration, and process behavior, so store them under appropriate access control.

Remove the mirror configuration after testing and verify that the destination port returns to its intended state. An abandoned mirror can expose control traffic to an unauthorized device or consume switch resources.

Never make configuration changes from a packet trace alone. Correlate the evidence with controller diagnostics, encoder indicators, switch counters, and a repeatable machine event. The capture records traffic; it does not certify the mechanical position or prove the encoder itself is accurate.

Turn observations into a fault conclusion

Frames stop at both capture points

Investigate encoder power, internal state, upstream program connection, or the common link before the first capture. Check whether the device restarts or the connection is deliberately inhibited.

Frames appear at the encoder but not the uplink

Focus on the intermediate switch path, VLAN, ring event, port errors, congestion, or cabling. Repeat with synchronized counters before changing the encoder.

Frames reach the controller path but the PLC times out

Review the configured connection, RPI, timeout, controller task loading, duplicate addressing, and whether the captured packets belong to the expected connection.

Packet capture becomes valuable when capture placement, timing, and network context are controlled. The goal is not a large Wireshark file. It is a small body of evidence that shows where the cyclic exchange changed and what physical or configuration event changed with it.