Simplification of communications during the upgrade

Can the D2000 upgrade also help your communications? Can something about them be improved or simplified? This blog describes a recent real-life situation.

We recently upgraded a smaller control system (up to 10 thousand tags). We were moving from D2000 version 10.0.37 (the first build of this version was released in October 2014) to the latest version 22.0.74. The application included communications with PLCs from Rockwell (CompactLogix) and Schneider (Modicon Telemecanique).

Both communications were implemented using OPC servers - Rockwell RSLinx and Modicon OPC Factory Server. During the upgrade, the hardware also changed - the new version was installed on new Dell PowerEdge R350 servers. In the case of Rockwell RSLinx, it would be possible to migrate the existing license to the new server, in the case of the Modicon OPC server, it would be necessary to purchase a new license.

We tried another way - we migrated these communications without using OPC servers. We used communication protocols that the D2000 KOM process directly supports. Why did we make this decision? On the one hand, it was more cost-effective to use the protocols built into D2000 - their price for the customer was lower than the price of OPC servers. And in the future, we saved the work associated with installing possible patches and security fixes of OPC servers. Moreover, if it were necessary to create a redundant system by adding another server, additional costs associated with the purchase, installation, and configuration of OPC servers can be spared. If the customer is thinking about migrating to Linux, we can do this as well - we have the necessary protocols available on the Linux platform as well (in contrast to OPC communication, which requires Windows). And finally - we have all the source codes of the implemented communication protocols in our hands, so we can correct any errors or expand the communication protocols as needed.

The migration was relatively quick and trouble-free. So how did we go about it?

Migration of Rockwell communication to Ethernet/IP protocol

We already wrote about starting communication with CompactLogix in another blog in the past. Line and station configuration was easy. First, we created a TCP/IP-TCP line and entered the IP address of the CompactLogix and the standard Ethernet/IP port 44818 on it.

Subsequently, we created a station with Ethernet/IP communication protocol on this line. In the Time parameters tab, we set the interval between readings to one second. In the Protocol parameters tab, we left everything at the default values.

In the next step, it was necessary to move all I/O tags (several hundred) from the original OPC station to the newly created station. This is possible using XML export/import or CSV export/import. We used XML export, then changed the parent in the XML file to a new station and went to do XML import. In addition, it was necessary to change the address of the I/O tags. In order not to do it manually (for several hundred I/O tags), we changed them before the XML import.

In OPC communication, the address was in the form [PLC_ID]Symbolic_name, see the following figure:

Since the OPC server is used for communication with several PLCs, the [PLC_ID] prefix is used to identify a specific PLC, and the Symbolic_name to identify a specific value in the PLC.

In the configuration for the Ethernet/IP protocol, we see a much larger dialog, but the only thing that is filled in is the symbolic name:

In the Ipesoft D2000 real-time application server, the address of the I/O tag is stored internally as two text strings.

Let's compare the following two figures - the textual representation of the original OPC address and the address in the Ethernet/IP protocol for a specific I/O tag:

We see that in the first address it is necessary to replace the prefix "[PLC2]" with the prefix "S="and add a semicolon at the end. The second address must be cleared.

For such simple find/replace operations on multiple XML files in one directory, we use the rxfind utility. In addition to simple text replacement, it can also work with regular expressions.

Replacing the prefix "[PLC2]" (the parameter /B:2 causes backups of the original XML files not to be created):

rxfind.exe *.xml /B:2 "/P:\[PLC2\]" "/R:S="

Backslashes are necessary to suppress the special meaning of square brackets in regular expressions.

Adding a semicolon to the end of the first address:

rxfind.exe *.xml /B:2 "/P:</PointAddress1>" "/R:;</PointAddress1>"

Change of parent from station B.PLC2n to station PLC_DT1:

rxfind.exe *.xml /B:2 "/P:<ParentId>B.PLC2n</ParentId>" "/R:<ParentId>PLC_DT1</ParentId>"

Subsequently, we imported all the I/O tags. During the XML import, there was a change of the parent and a change of the address of the I/O tags. All other bindings (location in schemas, connection in structured variables, archiving) were preserved.

Migration of Modicon communication to Modbus protocol

This migration was very similar. Modicon PLCs use native Modbus TCP protocol. So first we created lines of the TCP/IP-TCP type and configured each IP address of the PLC and the standard Modbus port 502. Since it was necessary to communicate with five PLCs, it was necessary to create five lines.

Subsequently, we created a station with the Modbus communication protocol on this line. In the Address tab, we set the address to 1, and in the Time parameters tab, we set the interval between reading values to one second. In the Protocol parameters tab, we set the Addressing model parameter to the value "MODBUS data Mode" - this means that the addresses of the I/O tags will not be 0-65535 but 1-65536. We also shortened the time parameters Wait First Timeout and Wait Timeout from 100 ms to 5 ms. In this way, we achieved faster processing of responses from the PLC.

The address of the digital I/O tag for the Modicon OPC server was in the form

MBT:<IP_Address>!%M  <memory_address>         for example MBT:10.102.20.220!%M851

The address of the integer or analog I/O tag was in the form

MBT:<IP_Address>!%MW<memory_address>       for example MBT:10.102.20.3!%MW200

where IP_Address is the IP address of the PLC and <memory_address> is the Modbus address of the I/O tag.

For the Modbus protocol we need the following addressing:

- input digital I/O tags are in the form 1.<memory_address>, e.g. 1.109 (the syntax means that the function 1=Read Coils is used for reading)

- input-output digital I/O tags are in the form 1-5.<memory_address>, e.g. 1-5.10 (syntax means that function 5=Write Single Coil is used for writing)

- input integer and analog I/O tags are in the form I3.<memory_address>, e.g. I3.20 (the syntax means that the function 3=Read Holding Registers is used for reading and the two-byte value is interpreted as a signed Integer)

- input-output integer and analog I/O tags are in the form I3-6.<memory_address>, e.g. I3-6.21 (the syntax means that the function 6=Write Single Register is used for writing)

The IP address of the PLC is not part of the address of the I/O tag, as it is entered at the level of the communication line.

The following two figures show the address of a specific input-output integer I/O tag with an OPC address and a Modbus address.

The process of changing the I/O tags was thus similar to the changing for communication with CompactLogix PLC. But this time we used CSV export and import for a change. We did the exports sequentially for different types of I/O tags – first for digital inputs, then for digital outputs, then integer/analog inputs and finally integer/analog outputs. To replace the strings (changing the parent, replacing the address prefix e.g. "MBT:10.102.20.3!%MW"with "I3-6" for integer/analog outputs) a simple text editor was enough for us.

Conclusion

Communication works smoothly after the SCADA system has been migrated. The customer was pleased that he did not have to deal with the installation of two OPC servers and that he would not have to take care of them and apply updates to them afterward. When, in 8-10 years, the next generation replacement of the SCADA server is considered, the customer will no longer have to deal with communication at all. And what's more, he also has the freedom to choose an operating system – he can decide to switch from Windows to Linux.

November 9, 2022, Ing. Peter Humaj, www.ipesoft.com