An intermittent PLC 9999 fault on a C-more panel talking to a CompactLogix usually means the selected EtherNet/IP driver and the controller-side configuration disagree. Read the driver under Set Up > Panel Manager: Generic I/O Messaging needs the panel in the controller's I/O configuration and no controller address on the panel; Client Tag-Based needs the controller's address in the panel's connection settings. Fix the end the selected driver owns, then judge the result over a full shift.
A C-more touch panel that talks to a CompactLogix controller over EtherNet/IP and throws a PLC 9999 fault now and then is usually reporting a disagreement between the two ends about who starts the exchange. The panel project selects one of two EtherNet/IP drivers, and each driver puts the controller's IP address on a different side of the link, so an address can be the right number sitting in the wrong place. The fix is to read the selected driver first, change only the end that driver owns, and judge the result over a full shift. This article gives the check order, the documented error codes that separate the cases, and a worked scenario with the arithmetic shown.
Why does a C-more panel show an intermittent PLC 9999 fault?
The first cause to check is the driver role: the panel project uses one of the two EtherNet/IP drivers C-more supports, and the controller side is still set up for the other, so some exchanges complete and the ones that need the missing role raise 9999.
9999 is the panel's report of a PLC communication failure. Its definition lives in the error-code tables (Appendix A) of the panel manual, so read the table for your software version before treating 9999 and any listed code as the same fault. What the pattern itself tells you is enough to start work: the pairing runs for stretches, values update, and the fault returns. That is the signature of two valid setups built for two different drivers. Check in this order: the driver, the end that driver owns, the addresses, then the network path. Most intermittent cases end at the second step.
Which EtherNet/IP driver is the panel project using?
Open Set Up > Panel Manager in the C-more project and read the driver selected for the PLC connection before changing any address: the two valid choices for this pairing are Ethernet/IP Server Generic I/O Messaging and Ethernet/IP Client Tag-Based, and they decide every later step.
The C-more documentation splits EtherNet/IP into the two message types the ODVA standard defines: implicit I/O messaging and explicit messaging. On the panel those become the two drivers above. Ethernet/IP Server Generic I/O Messaging runs the panel as an I/O device: the controller owns the connection and polls the panel, so the panel needs only its own address. Ethernet/IP Client Tag-Based reverses the roles: the panel opens the connections and reads and writes tags, so the panel must hold the controller's address. Write the driver name on the panel's record before downloading anything; everything after this section branches on it. The same discipline opens every panel-to-PLC diagnosis, and for serial protocols it starts with the driver list check before tuning serial settings.
What does the fault pattern tell you before you touch anything?
Read the pattern first, because the documented codes separate the cases cleanly: a steady PLC-001 communication timeout means the path is down, a PLC-008 error means a packet arrived with corrupted data, and an intermittent 9999 with values updating between events points at the driver-role disagreement.
Sort your case against this list:
- Steady timeout from the first download, values never arrive: the path is down or the side that initiates holds a wrong address. The first-setup Ethernet timeout fix walks that case step by step.
- 9999 a few times per shift with values updating in between: the driver-role disagreement this article fixes.
- Codes that began with a project or controller download: the download moved a driver or an address. Compare before and after, then change one end.
- PLC-008 in the fault list: the data in a packet from the controller arrived corrupted, so check the cable, shield and switch port before any configuration change.
- Values frozen with no fault banner: the mapping, not the link. Start with the tag-address check for a numeric display that shows nothing.
Where does the controller's IP address belong?
Under Ethernet/IP Server Generic I/O Messaging the controller's address belongs nowhere on the panel, because the panel is the I/O device the controller polls; under Ethernet/IP Client Tag-Based the panel starts the exchange, so the address goes in the panel project's PLC connection settings and nowhere else.
The page that tempts everybody is Set Up > Panel Manager > Ethernet Port > DEV001. That page configures the panel's own Ethernet port: the panel's IP address, subnet mask and gateway. It is not a destination list. Under Generic I/O Messaging the panel carries no controller address anywhere in the project. Under Client Tag-Based the controller's address goes in the PLC connection settings, where the connection target is defined. And never copy the controller's address onto the DEV001 page: two devices answering one IP address on the same network is a fault waiting for a shift change.
| Driver selected | Who starts the exchange | Controller's IP on the panel? | The end that can carry the fault |
|---|---|---|---|
| Ethernet/IP Server Generic I/O Messaging | The controller, as the I/O connection owner | No | The controller's I/O configuration entry for the panel |
| Ethernet/IP Client Tag-Based | The panel, with tag-based reads and writes | Yes, in the PLC connection settings | The panel project's connection target and the path to it |
What does the controller side need for each driver?
For the Generic I/O Messaging driver the controller needs the panel in its I/O configuration as a Generic Ethernet Module set to the panel's own address, and for the Client Tag-Based driver the controller needs no I/O-tree entry because the panel's traffic arrives as connections the panel opens.
The documented Generic Ethernet Module setup adds the panel in the controller's I/O Configuration tree with the panel's own address, and its instance settings must match the map the panel driver documentation prints. An entry whose address or instance map disagrees with the panel project produces exactly this kind of fault, and mapping an HMI address to a generic Ethernet module tag shows the tag side of that entry. Under Client Tag-Based, expect no module entry for the panel: tag traffic arrives as connections the panel opened, and the controller serves them without one.
Scenario: what do you change when a panel at 192.168.1.50 faults 4 times per shift?
The panel project names Ethernet/IP Server Generic I/O Messaging, so the fix belongs on the controller: 4 faults spread across a 480-minute shift is one fault every 120 minutes with values updating in between, a pattern a dead cable never produces.
The setup: the DEV001 page shows 192.168.1.50 with mask 255.255.255.0, the controller is 192.168.1.10, and the shift log shows 4 events of 9999 in one 8-hour shift with working values between events.
Addressing check:
192.168.1.50 AND 255.255.255.0 = 192.168.1.0 panel
192.168.1.10 AND 255.255.255.0 = 192.168.1.0 controller
One network, so the addressing is sound, and under this driver the panel carries no controller address anywhere: DEV001 stays as it is.
Pattern check: 4 faults in 480 minutes is one event every 120 minutes. A dead cable, a duplicate address or a missing I/O entry fails every exchange from the first one; faults that come and go while values update point at the role setup.
Controller check: the Generic Ethernet Module entry for this panel must carry 192.168.1.50, the panel's own address, plus the instance settings the driver documentation prints. An entry built with the controller's own 192.168.1.10, or with instances that do not match the panel's map, is the fault.
Decision: correct that entry, download to the controller only, and count over the next full shift. 0 events of 9999 in 480 minutes clears the case. Another event inside the shift moves the check to the panel project's driver page. Had that page read Ethernet/IP Client Tag-Based, the same two addresses decide the opposite fix: 192.168.1.10 goes into the panel project's PLC connection settings, and the controller-side I/O entry for the panel comes out.
How do you apply the fix and prove it stayed fixed?
Download the correction to the one device the selected driver points at, leave the other end untouched, then run the line through the condition that used to trigger the fault for a full 8-hour shift: zero 9999 events with values updating is the pass mark.
If the driver is Generic I/O Messaging the download belongs to the controller; if it is Client Tag-Based it belongs to the panel project. Leave every unrelated network setting as it is, so any next fault has one cause. Never swap drivers as a quick fix: a Generic I/O panel switched to Client Tag-Based with no controller-side change trades one mismatch for two.
Recommendation: For an intermittent PLC 9999 on a C-more panel talking to a CompactLogix, record the driver under Set Up > Panel Manager before any download. If it reads Ethernet/IP Server Generic I/O Messaging, correct the panel's Generic Ethernet Module entry in the controller's I/O configuration: the panel's own address and the documented instance map, then download to the controller. If it reads Ethernet/IP Client Tag-Based, enter the controller's IP address in the panel project's PLC connection settings and download the panel project. Change the second end only if 9999 survives a full 8-hour shift.
Record before and after: the driver name, both IP addresses, the entry or target values, and the times of any events. If the fault returns, that record turns the second fix into a comparison instead of a guess.
What changes when several panels share one controller, or the link is serial?
Each panel spends connection capacity on the controller's Ethernet port, so the ceiling is capacity and not a panel count; on a serial link the EtherNet/IP checks drop away and the serial settings mismatch check takes over.
The count one Ethernet card supports gives the planning numbers for a second or third panel. Two panels writing the same registers is a separate contest, and who wins the write covers it. A serial mismatch refuses data outright from the first transfer, which is why the serial settings mismatch check is the one to run on an RS232 or RS485 line. And when the cell needs a notice or andon board beside the HMI, shop-floor signage is the category our displays are built for: they play their own content offline and never sit in the panel-to-controller path.
Questions
Why did the 9999 fault start right after a project download?
A download can carry a different driver or address than the file it replaced, while the other end keeps serving the relationship the old file set up. Compare three things before and after the change: the driver name under Set Up > Panel Manager, the panel's address on the Ethernet Port DEV001 page, and the panel's entry in the controller's I/O configuration. Align the end the selected driver owns and re-download that one device.
What does the PLC-008 code add to the picture?
PLC-008 is documented as an incorrect CRC in a communications packet from the PLC: the packet arrived but its data was corrupted. That is an electrical finding, so check the cable run, shield continuity, separation from motor cables and the switch port before touching configuration. Cleaning the physical link is what removes that code; no driver or address change will.
Does explicit messaging to the panel use the same setup?
No. Explicit messaging to the panel is its own documented case: a controller program that reads the panel's data directly uses specific service codes the panel help pages print, and that setup stands apart from the choice between the Generic I/O Messaging and Client Tag-Based drivers. You meet it only when controller logic reads panel data itself, not when the panel displays controller values.
Where is the 9999 code defined for my software version?
In the panel manual's error-code tables, printed as Appendix A, which list the panel and PLC communication codes with their meanings. Check the table that matches your software version, because a numeric code can carry a different definition between versions, and record the version number with the fault log when you call for support.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.