[Bug]: Integration Issues with Rockwell ControlLogix PLC

[korni128]

What happened?

Description

We are currently working on integrating a Rockwell PLC using the PLC4J library with the Ethernet/IP Protocol. While our implementation successfully communicates with a Rockwell CompactLogix PLC, we are encountering issues when attempting to connect to a Rockwell ControlLogix PLC.

Observations

During our analysis with Wireshark, we observed the following:

• The initial GetAttributesAll call to the ControlLogix PLC fails, returning the error: 'General Status: Service not supported (0x08).'
• In contrast, the same call works without issues on the CompactLogix PLC, where we receive responses with attributes for: 'Class: Message Router (0x0002)' and 'Class: Connection Manager (0x0006)'

Current Understanding

If the GetAttributesAll call fails, then the useConnectionManager and useMessageRouter boolean values are set to false in the EipProtocolLogic class. As a result, PLC4X is attempting to perform single requests.

Issues Identified

• Sending single requests sequentially is causing issues related to the PLC4X library.
• Sending single requests when useMessageRouter and useConnectionManager are not active has also been problematic in the past in the PLC4X library, based on my understanding of the code. Therfore I would prefer the way via Message Router / Connection Manager.

Idea

• The GetAttributeSingle method may serve as a potential workaround instead of using GetAttributesAll, in order to get the attributes 'Class: Message Router (0x0002)' and 'Class: Connection Manager (0x0006)' one after the other. However, if the Message Router and Connection Manager are not functioning correctly, implementing this workaround may not solve the issue and we have also not tried to use GetAttributeSingle (just seen it in some documentation).

Questions

1. Does anyone know why the GetAttributesAll call may be failing with the ControlLogix PLC?
2. Any ideas on potential workarounds or solutions would be greatly appreciated.

Thank you

Version

v0.12.0

Programming Languages

• plc4c
• plc4go
• plc4j
• plc4net
• plc4py

Protocols

• AB-Ethernet
• ADS /AMS
• BACnet/IP
• C-Bus
• CANopen
• EtherNet/IP
• Firmata
• IEC-69870
• KNXnet/IP
• Modbus
• OPC-UA
• Profinet
• S7
• S7-light

[chrisdutz]

I took the liberty to ask ChatGPT :-) ... here's the response ;-) ... I particularly liked how it positively mentioned PLC4X ;-)

---

Yes — this is a known quirk of how different Rockwell Automation PLCs implement the EtherNet/IP (CIP) protocol stack, especially when it comes to CIP object attributes and the Get_Attributes_All service (Service Code 0x01).

📌 Background on Get_Attributes_All
The Get_Attributes_All service is meant to return a predefined list of attributes for a given CIP object (like Identity Object, Assembly Object, Connection Manager, etc.). However:

It only works if the object explicitly supports that service.

The attributes returned are not dynamically assembled, but hardcoded by the firmware per object class.

✅ Why It Works on CompactLogix
Many CompactLogix PLCs (especially newer firmware versions) implement Get_Attributes_All more completely and correctly — at least for commonly used objects like:

Identity Object (Class 0x01)

Assembly Object (0x04)

Connection Manager (0x06)

That’s why tools like EIP clients, Wireshark dissectors, and software like PLC4X or pylogix sometimes show better results when used with CompactLogix.

❌ Why It Fails on ControlLogix
Some ControlLogix PLCs — especially older firmware versions — either:

Do not support Get_Attributes_All for many objects.

Or return partial/incomplete data, or simply a Service Not Supported error (status code 0x08).

This is by design and documented in some of Rockwell’s older EDS and object specifications. They often expect tools to query attributes individually using:

Get_Attribute_Single (Service Code 0x0E)

Or Get_Attribute_List (Service Code 0x03, which is optional but more flexible)

✅ Recommendation
To ensure maximum compatibility, especially with ControlLogix:

Use Get_Attribute_Single for known attributes (e.g., revision, product code, serial number, state).

Avoid Get_Attributes_All unless you've verified that the target object and device supports it.

Some tools (like PLC4X) handle this gracefully by falling back automatically.

🔍 Debug Tip
If you're testing manually or with a custom client:

Try sending Get_Attributes_All to Class 0x01, Instance 1 (Identity Object).
If that fails on ControlLogix, the service is not supported.

Then send Get_Attribute_Single for:

Attribute 1 (Vendor ID)

Attribute 2 (Device Type)

Attribute 3 (Product Code)

Attribute 4 (Revision)

Attribute 5 (Status)

Attribute 6 (Serial Number)

Attribute 7 (Product Name)

These are almost always supported.

[chrisdutz]

That being said, I think the proposed approach is valid as you and chatgpt mentioned it.
If you're willing to implement the fix and prepare a PR, I am willing to assist.
If you want someone else to address this for you, that's fine, I would be willing to do so, for a donation of at least 300€.

[korni128]

Thank you for your prompt response. I believe the most effective approach would be for me to submit a pull request. However, I currently lack direct access to a Rockwell ControlLogix PLC, and the code appears to be tricky due to the code generation part. At this moment, I'm unsure how to generate the code for the GetAttributeSingleRequest, similar to the GetAttributeAllRequest. Any guidance or resources you could provide would be appreciated.
I will also verify whether there is budget available for a donation.

[chrisdutz]

Hi "Korni" ;-)

Well in general we generate the generated-code from specifications we do in our own format: MSPEC. For the EIP protocol, this is in the file https://github.com/apache/plc4x/blob/develop/protocols/eip/src/main/resources/protocols/eip/eip.mspec

So I just had a look, it seems that it should be pretty simple to implement the Single item requests by filling the case here (The types are already defined, however the bodies are still left empty with a TODO): https://github.com/apache/plc4x/blob/develop/protocols/eip/src/main/resources/protocols/eip/eip.mspec#L159
Feel free to use the other parts of the mspec or other mspec files as inspriration.

Once you've updated the "protocol" module, all you need to do, is run the maven build of the java modules, with the enabled profile: "update-generated-code" (Be sure to have built the protocol with "mvn install" first as the plugin will use the compiled module as input). After that you'll see the files: https://github.com/apache/plc4x/blob/develop/plc4j/drivers/eip/src/main/generated/org/apache/plc4x/java/eip/readwrite/GetAttributeSingleRequest.java and https://github.com/apache/plc4x/blob/develop/plc4j/drivers/eip/src/main/generated/org/apache/plc4x/java/eip/readwrite/GetAttributeSingleResponse.java get updated.

It should generally be a simple task.

Please feel free to ask more questions if you have them ... I'm more happy if we had more people actively helping maintain PLC4X. As long as I have to do most of the work however, I no longer do it for free. I hope you understand that.