Resolving RJ71EIP91 EtherNet/IP Connection Drops on Zebra ZT610

A Mitsubishi MELSEC iQ-R PLC equipped with an RJ71EIP91 EtherNet/IP scanner module occasionally loses its Class 1 connection to a Zebra ZT610 industrial label printer after the printer is power-cycled. Ping and ARP remain functional on the closed network, but the scanner's slave scan no longer advertises the printer, and cyclic I/O is suspended. The condition clears only after the printer is reset, after its network parameters are reinitialised, or after factory defaults are restored. PLC power-cycling and cable reseating do not reproduce the fault; the issue is triggered specifically by cycling the printer.

This reference documents the observed fault, the EtherNet/IP mechanics that produce it, an EDS-file modification that improves recovery, and the verification steps an integrator should perform before commissioning.

1. System Topology

The reference configuration consists of three nodes on an isolated Layer 2 network:

The link is a closed switch fabric — no router, no managed spanning tree, no wireless bridge. All three ports are on the same subnet. Under these conditions, the basic TCP/IP path stays intact after the printer is power-cycled, isolating the fault to the CIP (Common Industrial Protocol) connection layer.

2. Observed Fault Behaviour

Sequence of events as reproduced on the bench:

1. The ZT610 is connected, a Forward_Open is issued from the RJ71EIP91, and Class 1 cyclic I/O is established. Tag data flows from the PLC into the printer and labels print.
2. The ZT610 is powered off. UDP port 2222 traffic from the printer ceases; the scanner marks the connection as timed out after the configured number of missed packets.
3. The ZT610 is powered back on. The printer comes up on the network — it answers ICMP echo (ping), answers ARP, and the RJ71EIP91 Tool can still ping it.
4. The RJ71EIP91 Tool slave scan no longer lists the printer as an available EtherNet/IP target, even though the IP address is reachable.
5. No new Forward_Open is issued by the scanner. The previous CIP connection remains in a stale established state from the scanner's point of view.
6. Printing does not resume. The only ways to recover are: a) physical reset of the printer, b) reinitialising its network parameters, or c) restoring the printer to factory defaults.

What does not reproduce the fault: power-cycling the PLC, unplugging and re-plugging the RJ45, or leaving the printer on and rebooting only the controller. The asymmetry points to the printer, not the scanner, as the entity that fails to re-enter a state in which the scanner is willing to re-issue Forward_Open.

3. Root Cause Analysis

EtherNet/IP Class 1 connections are managed by a CIP connection state machine that lives on both endpoints. The CIP specification (Volume 5, Chapter 4) requires that an adapter, on detecting that the scanner has stopped sending I/O packets, transmit a Forward_Close after the configured Inactivity Watchdog multiplied by the Requested Packet Interval (RPI) elapses. The scanner mirrors this requirement in the opposite direction: if it sees no I/O from the adapter for the same window, it must tear the connection down locally and be ready to re-open it.

On a normally behaving target, the printer would either close the connection from its end (which the scanner sees on TCP and re-arms) or fail to reply to I/O long enough for the scanner to time out and re-open. The Zebra ZT610 with the Network Connect driver exhibits neither behaviour reliably. The practical result is that:

• The scanner still believes the connection is open, so it does not re-issue Forward_Open automatically after the target returns.
• The target, having rebooted, has lost its own connection state and is listening for a new Forward_Open, but none arrives.
• The two endpoints are in incompatible CIP states until the printer is reset from the front panel or via the Web Admin page.

This is consistent with the field observation that resetting the network parameters or performing a factory reset on the printer re-arms its CIP connection state machine and lets the scanner re-establish a session on the next scan cycle. The PLC's connection database still contains the original connection_serial_number and is willing to re-use it; the printer's database has been wiped, which forces both ends to start over.

4. EDS File Modification: Multicast to Point-to-Point

The default EDS shipped with the Zebra Network Connect driver declares a multicast Class 1 connection. Multicast on EtherNet/IP uses UDP and is intended for many-to-one distribution from a single producer to multiple consumers, so it has different timeout and membership semantics than unicast. The RJ71EIP91's connection engine has been observed to handle a power-cycled target less gracefully over multicast than over point-to-point (unicast) Class 1.

The fix is to edit the EDS so that the TransportClass_Trigger and the connection path parameters select Point-to-Point (Class 1, unicast UDP) instead of Multicast. Concretely, in the EDS [Connection] section:

; Original (multicast) section in the Zebra ZT610 EDS
[Connection 1]
Trigger = Cyclic
TransportClass = 1
RequestedPacketInterval = 50
O->T_Format = Heartbeat
T->O_Format = 32-bit Run/Idle header + data

; Modified section — point-to-point
[Connection 1]
Trigger = Cyclic
TransportClass = 0   ; 0 = point-to-point (unicast)
RequestedPacketInterval = 50
O->T_Format = Heartbeat
T->O_Format = 32-bit Run/Idle header + data

Re-import the modified EDS into the RJ71EIP91 configuration and re-assign it to the printer's connection. After re-import, the configuration tool will display the assembly as unicast; verify that the connection's Connection_Path is still 20 04 24 xx 2C xx 2D xx (configuration assembly, instance 0x96, input assembly, output assembly per the ZT610's AOI) and that the Input Only checkbox is unchecked if you need full Run/Idle + data.

5. Requested Packet Interval and Watchdog Tuning

With the EDS set to point-to-point, tune the RPI and the watchdog so that the scanner detects the printer going away within a bounded time and is willing to re-open a fresh connection once the printer returns. The relevant fields in the RJ71EIP91 EtherNet/IP configuration are:

Formula for the worst-case detection time:

t_detect_max = RPI × TimeoutMultiplier × 2
              = 100 ms × 4 × 2 = 800 ms

The factor of 2 accounts for the scanner's send and the adapter's expected response. With these values, the scanner will declare the connection down within roughly one second of the printer going offline, and — with auto-reopen enabled — will issue a new Forward_Open as soon as the printer's UDP port 2222 is reachable again.

6. Network Capture Diagnostics

Wireshark captures were taken on the engineering PC's mirror port to compare three scenarios:

1. Printer on, connection good.
2. Printer power cycled without reconnection.
3. Printer reset, reconnection succeeds.

Key filters and what to look for:

In the failed-reconnection capture, the absence of cip.cm.service == 0x4F from the printer is the smoking gun: the printer is back on the network, answering ARP and ICMP, but never sends a Forward_Close and never answers the scanner's implicit I/O. Meanwhile, the scanner's enipio packets stop after the watchdog elapses and there is no further 0x4E request. The state machines on both ends are stuck.

In the reset scenario, the same trace shows the scanner issuing 0x4E immediately after the printer completes its boot and registers on UDP/2222. The reply is a successful 0xD4 Forward_Open response with a new connection_serial_number.

7. RJ71EIP91 Configuration in GX Works3

Steps to apply the changes through the standard engineering toolchain:

1. Open the project in GX Works3 and navigate to Parameter > Module Information > RJ71EIP91 > EtherNet/IP Configuration Tool.
2. Delete the existing entry for the ZT610.
3. Re-add the device from EDS Library. Import the modified EDS first via EDS File > Register EDS; the tool will display the connection as point-to-point in the connection summary.
4. Set RPI to 50 ms (or 100 ms if label volume is low), watchdog multiplier to ×4, and enable Auto Reopen.
5. Map the input assembly (typically instance 100, length 32) to a buffer memory area such as W100–W11F and the output assembly (instance 150, length 32) to W200–W21F.
6. Write the parameters to the PLC and verify with Online > Monitor > Buffer Memory.

For the full parameter reference, the official MELSEC iQ-R EtherNet/IP Network Interface Module User's Manual (SH-081913ENG) documents the buffer memory map, the connection-parameter layout, and the supported CIP services on the RJ71EIP91.

8. Workaround Procedure When the Fault Recurs

Until Zebra ships a firmware update that closes the connection cleanly on power-down, the following operator procedure keeps the line running:

1. Power down the ZT610.
2. Wait 5 seconds after the link LED drops.
3. From the ZT610 front panel: Menu > Networks > Reset Network. This clears the cached connection state without touching the label format stored on the device.
4. Power on the ZT610. Allow 30 seconds for boot and link-up.
5. The RJ71EIP91 detects the target on UDP/2222 and re-issues Forward_Open within one RPI cycle.

If Reset Network does not clear the fault, escalate to Menu > Settings > Restore Defaults > Network Only. This is the only step that has been observed to recover the printer when the modified EDS is in use and the connection is multicast-stuck.

9. Verification Checklist

Run this checklist after every configuration change, and again after any printer or scanner firmware update:

1. Baseline capture: With the printer online, capture 30 s of traffic and confirm continuous enipio packets in both directions.
2. Power-down test: Cut power to the printer. Confirm that the scanner logs a connection timeout within 1 s (event in the RJ71EIP91 diagnostic buffer).
3. Power-up test: Restore power. Confirm that the scanner logs a Forward_Open request and that the printer responds with a successful 0xD4 reply.
4. Slave scan: Run the RJ71EIP91 Tool slave scan during the recovered state and confirm the ZT610 appears with the modified EDS identification string.
5. End-to-end print: Toggle a tag in the PLC that triggers a label. Verify the printed label reflects the new tag value.
6. Repeat 5×: Cycle the printer power five times in a row. All five cycles must reconnect automatically without operator intervention.

10. Preventive Measures and Long-Term Recommendations

• Keep the scanner on the same subnet as the printer. Routing the CIP path through a Layer 3 boundary introduces additional failure modes (TCP session timers, NAT timeouts) on top of the CIP state issue.
• Disable energy-saving Ethernet on the printer's switch port. Some managed switches power down the PHY on idle links; this looks identical to a target drop to the scanner.
• Pin the printer's IP in DHCP reservations and avoid relying on DHCP for the EtherNet/IP target — the RJ71EIP91's connection table is keyed on IP, and a DHCP lease change after a printer reboot will orphan the connection.
• Watch the RJ71EIP91 firmware revisions. The connection engine has been refined across firmware versions. Always note the firmware of the module in the project documentation and review the release notes before upgrading in production.
• Engage Zebra support with a request for a Network Connect driver update that implements CIP Forward_Close on power-down. Until that ships, the EDS modification and the recovery procedure above are the only fully repeatable mitigations.