The existing implementation of the Ethernet/IP communication protocol for the Ipesoft D2000 application server is almost six years old. Various improvements have been added during that time – support of proprietary Rockwell Read/Write Tag services along with their Fragmented variants, optimization of work with symbolic address, work with redundant PLCs, browsing, and even encapsulation of PCCC messages in Ethernet/IP protocol used by older PLCs.
Today I would like to mention read performance optimization.
A requirement from practice
When we upgraded six water company SCADA systems in 2023 and connected them to the MES system through a transparent gateway, we also simplified communications - among other things, we no longer put the Rockwell OPC server RSLinx on the new servers, but we made do with our implementation of the Ethernet/IP protocol. The advantage was that the customer did not need additional software (which must be purchased, updated, etc.). A potential advantage is that, if necessary, we can also run the application server (or its communication subsystem) on the Linux platform.
The upgrade was successful, the communication was stable for a long time, however, there was one BUT – the RSLinx OPC server was able to read values faster than the D2000. In the short term, we implemented a temporary solution - we moved several tens of measured points that had to be "fast" to a separate communication line and station - i.e. the D2000 Kom process created a dedicated TCP connection for them - and the read speed was just over 2 seconds (of which 1 second was the configured delay between reads). The remaining over 1000 objects were at the original station, their periodic reading took about 15 seconds.
Optimization
Subsequently, we started dealing with the optimization in the implementation of the Ethernet/IP protocol. Instead of each measured point being read by a separate message (Read Tag Service), the Multiple Service Packet Service is used for wrapping of multiple reading requests into one packet.
Each such "bulk" read request and each "bulk" response must additionally meet the condition that its size does not exceed the Max Packet Size (504 bytes by default). In order to fulfill this condition, the first reading after the start of the D2000 Kom process is standard - and after receiving the response, the data sizes are stored (since the Ethernet/IP protocol also allows the reading of entire arrays or structures). Subsequently, if the optimization is turned on by the Use Multiple Service Packet Service station parameter, read message merging will be used.
Deployment
A few days ago, the D2000 Kom process with optimization was deployed at the customer. The result – reduction of the reading cycle for over 1000 measured points from 15 seconds to 2.2 seconds. And one second of that is the configured delay at the station.
How about a PLC, specifically the CompactLogix 1769-L36ERM? In the diagnostic web interface, the use of the communication module did not change and remained between 7.1-7.2%.
Communication could be sped up even further - the Send Delay parameter, specifying the delay between sending individual readings, is set to 10 ms by the customer in order not to overload the respective CompactLogix by the communication - in the past, in a specific case, we had problems with the stability of several CompactLogix PLCs, if we were too demanding.
However, the achieved two seconds are completely sufficient for the customer, and further speed-up is simply not necessary today.
Conclusion
Optimizing the reading speed in the Ethernet/IP protocol implementation in the Ipesoft D2000 real-time application server will please those of our customers and OEM partners who need to communicate with PLCs by Rockwell - one of the three largest PLC manufacturers in the world. And I am personally pleased that the D2000 Kom process is a bit better again.
May 17, 2024, Ing. Peter Humaj, www.ipesoft.com
