Module owned and configured by another controller

Hi everyone,

I work with an Allen Bradley PLC (L18ERM) on a test plateform that is only composed of the processor and one EtherNet/IP device:

L18ERM firmware version: v20.12
RSLogix 5000 version: v20.01

When I try to open a connection on my device, I get the following errors:
- Communication error: Code 16#0106 / Module owned and configured by another controller
- Connection request error: Code 16#0205 / Invalid parameter

Connection tests have already been done with others PLCs without any problem:
- L43 / L43S
- L32E
- L45

It seems that there is something to do with the latest range of Allen Bradley PLCs (CompactLogix 5370 Controllers) as I get the same errors with a L33ER controller.

Does anyone have an idea of what could cause this and/or what I could try to fix this?

Thanks a lot.
Johan

Welcome to the Forum !

This may require some protocol analysis to get to the root cause.

In general, all ControlLogix and CompactLogix create their I/O connections the same way.

One notable difference about the 5370 series compared to the older CompactLogix is that they consider the EtherNet/IP port to be integrated into the CPU, rather than being a daughtercard in Slot 01 or on the 1768 bus.

That may lead to something different about the Originator Path, for example, in the connection establishment traffic.

What exactly is the third-party device ? Is it ODVA Conformance Tested ?

Hi Ken,

thanks a lot for your prompt answer.

The device I use is actually a new device that my company will release shortly. It has not been tested by a Test Service Provider yet, so in fact, there might be some bugs or mistakes in the way EtherNet/IP stack has been implemented in the device...

However, I do not understand why the module is seen as "already owned and configured" knowing that I only have one controller on my EtherNet/IP network.

Do you know any kind of specific tests I could do to clarify what is happening?

Once again, thank you for your time and help.

Maybe the device firmware is incorrectly turning the I/O instance of the Connection object into the Established state at the same time as it turns the Explicit instance of the Connection object into the Established state.

Or maybe the CompactLogix 5370 is more strict about some aspect of the connection establishment handshake than its predecessors were.

I am not aware of any differences in the CompactLogix 5370's I/O connection establishment protocol, compared to the older CompactLogix platform controllers. There might be some, but I have never seen one documented.

If this were my system, I would set up a protocol analyzer like Wireshark or Frontline Test Equipment's NetDecoder, and compare the connection traffic that you get from a CompactLogix that works to the connection traffic you get from a CompactLogix that doesn't.

Thank you, I am going to do some tests tomorrow and keep you informed. I also contacted the provider of the EtherNet/IP stack (Pyramid Solutions) we bought 2 years ago, in case some important updates have been released in the last years...

Hi Ken,

thanks to the support of Pyramid Solutions that provided the EtherNet/IP stack, we found that there was an issue in the "sockaddr structure" used to establish the connection.


The firmware of our device is now updated and it runs well.
Thanks for your help and support.[FONT=&quot][/FONT]