Tutorial - Ethernet/IP in practice

Some time ago, you could have read about features of the extended communication protocol Communication – Ethernet/IP. Lately, it was necessary to start communication between the MES system built on the D2000 technology and the control system of a cogeneration unit of a particular customer. The control system is built on the PLCs made by Rockwell company (the main controlling unit was ControlLogix 1756 and smaller auxiliary wer CompactLogix 1769).

So, how to establish the communication?

We’ve been considering three possible ways:

· Communication via OPC DA (OPC Classic). Since the MES system is operating on Linux servers, the KOM process communicating with the OPC server would have to be run remotely (ideally on a computer where the OPC server is running).

· Communication via OPC UA. This seemed like the best way at the beginning but it turned out that the OPC UA server wasn’t available (because of licensing or other reasons).

· Native communication using the Ethernet/IP protocol.

Today, I would like to share with you experience of starting communication using the Ethernet/IP protocol.

Communication with CompactLogix

To establish communication with a small PLC CompactLogix was a piece of cake.

First, we had to create a line of the TCP/IP-TCP type and enter the IP address of PLC. The port is 44818, which is a default port for the Ethernet/IP protocol:

We didn’t change anything on the tab with protocol parameters, keepig all values to default:

We chose the Ethernet/IP protocol in the station configuration dialog:

Then, we created a text I/O tag that would read the value of the Product Name attribute of the instance #1 of the Identity Object class – that is the name of the device. In this figure, we can see that we communicated with the “1769-L16ER/A LOGIX5316ER” device.

Even the browsing worked without problems – next figure shows reading of the list of symbolic names from the device:

Communication with ControlLogix

Starting of communication with ControlLogix was a bit more adventurous. We also started with line configuration by entering the IP address and a port:

In line parameters, we turned on the optimized work with symbolic names. This optimization will cause the symbolic names to be converted to instance numbers, which are not only shorter but also PLC can work with them faster. Unlike CompactLogix , the PLC of the ControlLogix class supports this optimization.

We configured the station and immediately started with configuration of I/O tags with symbolic names that were agreed on. However, we couldn’t read them. Requests were returning the error “General Status = Path destination unknown [x05]” which means that symbolic names can’t be found in the device.

Browsing was also not working – when trying to read the Object_list attribute from the first instance of the Message Router Object class, we received the error “General status: Attribute not supported [x14]”.

Nevertheless, we can’t say that nothing worked. After configuring the I/O tag that reads the value of the Product Name attribute, we received a correct answer – we communicated with 1756-EN2TR-C which is “ControlLogix EtherNet/IP bridge Module”.

First, we suspected that there was some kind of a security setting (similarly to the Simatic S7-1200 and S7-1500, which need to have explicitly allowed access of third-party products). However, the supplier of the technology assured us that there is no such setting configured.

After a longer (and unsuccessful) labouring, using WireShark, we recorded functional communication between PLC and the ABCIP.exe Rockwell program, which supposedly serves as an equivalent of the D2000 KOM process (and provides the Rockwell OPC server with data).

First, we found out that protocol messages (Read Tag Service) are packed into the Multiple Service Packet Service message. This message is intended for performance optimization – it is possible to pack more messages into a single request.

So, we continued by implementing a station parameter Use Multiple Service Packet Service which would control messages packing. Within a day, the functionality was developed and tested against CompactLogix which could also process these messages. However, deploying a patch at a customer was disappointing – ControlLogix was still sending back errors, this time “General Status = Service not supported [x08]”. It seemed like it did not even support the message Multiple Service Packet Service!

Therefore, we looked at the communication record more closely.

Firstly, we noticed that unlike the D2000 KOM process that sends messages as Unconnected messages, ABCIP.exe uses Connected messages (this requires to first establish “connection” – this functionality is not implemented in the D2000 KOM process as it has not been necessary so far).

What was more important, the packets of the Unconnected Send type could be seen while establishing a connection. These packets can be used to wrap another packet and direct it to a particular “address”. The address can be for example communication port of a device and the address of a target device (e.g. serial port + MAC device address on serial line or the Ethernet port + IP address of a target).

In this particular case, the target address was 01 00. According to the standard, that means “back-plane, slot 0”.

Here, we started to understand the cause of our problems. PLC ControlLogix is probably modular – and since we are directly connected to the communication module, we can get to the CPU located in slot 0 only after entering the address “back-plane, slot 0”. Without explicit routing, we are talking only to the communication module that does not know any symbolic names, does not support browsing, and only knows a few objects required by the standard.

So, we continued by implementing station parameter Route Path for Unconnected Send that would enable us to enter the path. If this parameter is entered, messages for reading or writing values will be wrapped into the Unconnected Send envelope and will be sent to a specific path.

After the implementation, we set the parameter to the value 01 00 and tensely waited for a result.

Bingo! I/O tags with symbolic addresses gained values.

In the figure, we can see that the I/O tag M..ProductName has the value “1756-L85E/B” – that corresponds with “Allen-Bradley 1756-L85E Logic Controller”. So, we are not communicating with the communication module but with the main processor of PLC.

Why did we implement the parameter Route Path for Unconnected Send on the station level and not on the line level? This way we could create more stations within one line and communicate with the CPU, the communication module and alternatively with other modules that exist within the modular PLC or even with devices that are behind PLC!

In fact, later we needed to communicate with auxiliary processor located in slot 1, for which we created another station with value of parameter Route Path for Unconnected Send equal to “01 01”.

Even browsing was working – unlike the CompactLogix with only 33 symbolic tags defined, ControlLogix had almost six thousand.

Conclusion

Support of routing for the Ethernet/IP protocol that is necessary for communication with ControlLogix was implemented in the 12.0.60 version and is available on request in form of patches (cnf.exe and kom.exe). We hope that not only our colleagues from Ipesoft but also our OEM partners and customers will welcome further extending of the KOM process possibilities. This specific improvement of the Ethernet /IP protocol enables the access to ControlLogix PLCs directly from D2000 (on Windows, Linux or Raspberry PI platform), without the need to buy another communication software (e.g. OPC Classic or OPC UA server)