[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.

[andvasp]

Hi Guys,

I am facing the same problem.

I forced the Connection Manager in the Plc4x code and it works properly.

I am inclined to implement the GetAttributeSingle.

I could do the GetAttributeSingleRequest and Received a partial valid response. The response status was succeeded but the attribute value was not serialized. Although, I do not need it to know if Connection Manager is available since status is success, it is important to know attribute value response.

May you assist me on this @chrisdutz?

Thanks!

[andvasp]

Hi @chrisdutz!

I implemented this functionality based on the version before the spi3 refactoring and I am adapting it to match the new version. I see you plan to release a new version in the next few days. If I submit a PR by Tuesday would it be possible to review and potentially include it in this upcoming release? Let me know your thoughts!

Best regards,
Anderson.

[chrisdutz]

Hi Anderson,

sure ... would be cool if you could manage to get it updated till then. I'll then have a look and hopefully merge it before cutting the release branch.

Chris

[andvasp]

Hi @chrisdutz !

Implementing this functionality I found a bug on EipTcpConnection::openConnectionManager because the field below is not a uint16. Interesting that the error does not happen on versions before sp3.

private final int connectionSerialNumber = ThreadLocalRandom.current().nextInt();

Caused by: org.apache.plc4x.java.spi.buffers.api.exceptions.BufferException: Value 1333777152 is out of range for 16 bits. Valid range is 0 to 65535

I believe tomorrow I can push a PR for a review.

Best regards,
Anderson.

[chrisdutz]

That would be greatly appreciated 😁

[andvasp]

Hi @chrisdutz!

I fixed the error mentioned above. The PR detecting the availability of the connection manager and message router via GetAttributeSingle is ready.

However, I hit a blocker when reading values using the connection manager. It looks like a regression, as it worked before spi3 on my implementation. I'm getting this error:

Caused by: org.apache.plc4x.java.spi.buffers.api.exceptions.BufferException: No encoding defined for unsigned integer values
at org.apache.plc4x.java.spi.buffers.bytebased.ReadBufferByteBased.lambda$readUnsignedByte$0(ReadBufferByteBased.java:122)

How would you like to proceed? Should I submit the PR as-is, or we take a look into this SPI encoding issue first?

[chrisdutz]

This is not a regression ...

Pre SPI3 we had one set of hard-coded encoders shared for all drivers. With SPI3 this is now fully pluggable and modularized. However now you need to define all used encodings for every entry-class that you use. I guess you are directly using an mspec generated type that hasn't set the "unsigned-integer" encoding.>

If it's the default one this should do the trick:

unsignedIntegerEncoding='"unsigned-binary"'
Setting all encoders to the defaults EIP is using would be this:

unsignedIntegerEncoding='"unsigned-binary"' signedIntegerEncoding='"twos-complement"' floatEncoding='"IEEE754"' stringEncoding='"UTF8"'

[andvasp]

Hi Chris!

Thank you for the information.

I checked and eip.mspec is already using the encoded information.

I fixed the error by updating the code as shown below:

From:
ReadBufferByteBased read = new ReadBufferByteBased(servicesData, WithByteBasedOption.WithByteOrder("LITTLE_ENDIAN"));

To:
ReadBufferByteBased read = messageCodec.createReadBuffer(servicesData);

Is this the correct solution, right? If so, there are other occurrences of creating ReadBufferByteBased and WriteBufferByteBased that I will replace as well before submitting the PR.

[chrisdutz]

Yeah... That looks good.
Ideally you shouldn't need to set that. However you mentioned integer encoding issues but omitted the endianess. That's odd.

However, your code looks good.

Chris

[andvasp]

@chrisdutz I submit the PR #2671 that targets the problems mentioned above when using Connection Manager.