HMI pings the PLC but reads fail: check the protocol driver

Why the ping passes and every read times out

Ping and a tag read ask the controller two different questions. Ping asks whether the IP stack answers. A tag read asks whether the application layer recognizes the request format, and that is where this fault lives.

EtherNet/IP is the industry standard managed by ODVA. It carries CIP, an application protocol built on objects and tag-based services, and Logix-family controllers such as ControlLogix and CompactLogix answer it natively. A panel driver selected as generic EtherNet/IP implements exactly that: CIP sessions aimed at a Logix-family target.

The SLC 5/05's Ethernet channel answers a different flavor. Its data service uses PCCC, and gateway compatibility notes draw the line plainly: CSP/PCCC is listed as incompatible with EIP/PCCC and EIP/CIP, and the one protocol the SLC 5/05 shares with an EtherNet/IP device is PCCC encapsulated in CIP. A driver that implements only bare CIP tag services asks questions the controller never answers. The panel waits out its poll timeout, marks the tag failed and tries again. No change to the IP address, the mask or the switch can alter that outcome.

Symptoms and what each points to

• Every tag times out while the ping succeeds. The driver and the controller speak different application protocols. Start at the driver name, not the network.
• The same driver connects to a ControlLogix on the same network. That confirms the driver implements CIP and that the SLC 5/05 wants PCCC. It also clears the switch, the cable and the addressing in one observation.
• Values display but freeze or read as nonsense. The protocol is working and the tag address or data type is wrong. That fault has its own path in HMI nonsense numbers from a PLC BCD analog register.
• Ping answers but reads crawl or drop in bursts. Suspect the link itself. The SLC 5/05's Ethernet channel runs at 10 or 100 Mbps, half or full duplex, and a port forced to full duplex against a half-duplex controller port corrupts large frames while short ping frames often survive. Match speed and duplex at both ends.
• The panel pings the plant network but cannot connect, against another controller family. Same shape, same layer. The pattern appears on other equipment too, as in an HMI panel that pings the plant network but cannot connect.

Checks in order

Work down the list and let each check clear one layer, the method behind troubleshooting that improves when each test proves one cause.

1. Record the exact failure text and note which device raises it, the panel's driver diagnostics or the controller's status screens. Whichever side reports first tells you which side gave up.
2. Ping the controller's address from a laptop on the same switch and note the reply time. Single-digit milliseconds is normal on a healthy local link. If the ping itself fails, work the physical and IP layers first; connecting a PC HMI to a PLC over a serial protocol or Ethernet covers that ground.
3. Open the driver selection in the panel project and read its exact name. A selection such as Generic EtherNet/IP (AB ENET IP) is a CIP driver. Check its documented list of supported controller families. If the list names ControlLogix and CompactLogix and nothing in the SLC 500 family, the fault is found.
4. Compare the panel's address and mask against the controller's with the subnet arithmetic in the example below. One pass through that arithmetic closes the addressing question.
5. Check speed and duplex on both ends if reads degrade rather than fail outright, and set both ports the same.

Example: clearing the network on 192.168.1.x

The case: an SLC 5/05 and a panel on one switch, every tag timing out, ping passing. The addresses are example project values, the channel figures are the SLC 5/05's documented Ethernet specifications, and the ping result is the measurement from check 2.

Inputs:

• Panel: 192.168.1.50 with mask 255.255.255.0.
• SLC 5/05: 192.168.1.10 with mask 255.255.255.0; its Ethernet channel runs at 10 or 100 Mbps, half or full duplex, so a 100 Mbps switch port matches it.
• Driver in the project: Generic EtherNet/IP (AB ENET IP).
• Ping from the panel's switch port: reply in 1 ms, four of four replies received.

Rule in words: two devices share a subnet when each address combined with the mask gives the same network address. A shared subnet means no router sits between the two, and no gateway entry is needed in either device.

Arithmetic:

• Panel: 192.168.1.50 AND 255.255.255.0 = 192.168.1.0
• Controller: 192.168.1.10 AND 255.255.255.0 = 192.168.1.0
• The results match, so both devices sit on 192.168.1.0/24 with no router between them.
• The ping replies came back in 1 ms over a 100 Mbps link, a healthy local answer.

Result: every network input passes. Shared subnet, no router, prompt replies.

Decision: with the IP layer cleared, one input still fails, and it is the driver. Generic EtherNet/IP (AB ENET IP) asks CIP questions of a controller that answers PCCC, so change the protocol path and leave 192.168.1.10 alone. The threshold for any similar job: a shared subnet and single-digit-millisecond pings clear the network, and after that a timeout on every tag is a protocol fault until a documented driver list says otherwise.

The fix, by case

• The panel's driver list documents a driver for SLC Ethernet. Select it, enter the controller's IP address and point one tag at a register the program demonstrably writes. Prove that one tag before loading the rest of the screen.
• No SLC Ethernet driver, short run. Move the link to DF1 full duplex on the serial channel. Configure the panel's serial driver for DF1 to the SLC 500, set matching baud, parity and station settings at both ends from the controller's serial documentation, and run RS-232 cable, which the serial standard rates at about 15 m (50 ft) at its rated load. The distances and the limits behind them are worked through in how far an HMI can be from the PLC on DF1 RS-232.
• No SLC Ethernet driver, longer run or no serial port. Fit a protocol gateway documented to convert both specific protocols: DF1 on the serial side, PCCC-based Ethernet on the controller side. The panel keeps its DF1 driver and never learns anything changed. An Ethernet switch or media converter joins ports and converts nothing, and that distinction is the whole job; what a bridge does and does not convert is laid out in protocol bridge limits with Modbus RTU and DF1.
• The panel is due for replacement anyway. Confirm the driver against the controller before ordering the new one, using the checklist in replacing a failed PLC operator panel without a protocol mismatch.

Recommendation: read the driver name first and leave the network settings alone once the ping passes. If the panel's driver list documents SLC Ethernet support, select that driver and prove it on one live register. If it does not, run DF1 full duplex over the serial channel when the run fits inside RS-232's 15 m reach, and fit a protocol gateway documented for both protocols when it does not.

Prove the fix on real data

Watch one known register. Change its value in the controller's programming software and compare the panel's display against it. Then walk every tag on the screen: address, data type and a live value for each. The job is done when every tag updates, and a panel power cycle is a fair final test as part of commissioning. If reads die again after that power cycle, the driver selection is still wrong.

Questions