An introduction to Open User Communication for TIA Portal and S7 PLCs and a step-by-step tutorial for sending data between PLCs using the TSEND_C and TRCV_C blocks.
Often, communication between multiple PLCs is required in automation projects.
In modern PLCs, there are so many communication options available that it can be hard to decide which one to use. Each communication option has advantages, disadvantages, and a unique way of working.
In this article, I'll provide a quick start guide for communication between PLCs using TCP/IP on Open User Communication. In the next sections, I will;
Open User Communication is a method of passing data over Ethernet in SIMATIC systems. With Open User Communications, you can use a number of different protocols to send and receive data in a PLC. The protocols available for Open User Communication are;
Let's look at each protocol in more detail.
TCP is a communication protocol that is suitable for transmitting medium to large quantities of data at high speed over an ethernet cable. With the TCP protocol, a connection is established between the sender and receiver and data transmission is acknowledged. This means that connection or communication issues can be detected and diagnosed within the user program. TCP is a common communication protocol and can be used for communication with Siemens PLCs as well as third party systems.
ISO on TCP is a legacy communication protocol that can be used to communicate with older SIMATIC devices like S5 PLCs. Unless you have a good reason, you should not select ISO on TCP as the communication protocol for new projects with modern PLCs.
UDP is a communication protocol for transmitting small amounts of data at very high speeds. Unlike TCP, UDP is a connectionless protocol so you can't be sure that the data being sent is being received by the receiver. Once again, UDP is a non-proprietary protocol so it can be used to communicate with Siemens and third party devices.
For more information on the differences between TCP, ISO on TCP, and UDP, check the SIOS Entry "What properties, advantages and special features are offered by the protocols TCP, ISO-on-TCP, UDP and ISO Transport?"
When you communicate with Open User Communication, you are creating a communication connection between a PLC and another device. In a SIMATIC system, each communication connection uses a connection resource in the PLC. This connection resource is the service that manages the communication connection in the background.
The number of connection resources available depends on the model of the PLC being used. For example, an S7-1516-3 PN/DP CPU has 256 connection resources available. In contrast, an older S7-317-2 PN/DP only has 32 connection resources.
A connection resource is used when a communication connection is established between the PLC and another device. A communication connection can be established in two ways - by configuration or by programming.
A configured connection is set up during the engineering phase of a project. This type of connection is hardcoded in the user program. Since the connection is hardcoded, it uses a connection resource as soon as the program is downloaded. This connection resource is used even when there is no connection between the PLC and the partner device.
In contrast, a programmed connection can be used to establish a connection with a device when its required and to disconnect from the other device when communication is complete. Programmed connections are more complex to manage but they can be useful for managing the resources of the PLC in a more economical way.
In the application example, we will be using the TSEND_C and TRCV_C Open User Communication blocks to create a programmed connection between two S7-1500 PLCs.
Understanding connection resources can be a complex topic and there are differences in the way connection resources are managed in older S7-300 and S7-400 PLCs in comparison to newer S7-1200 and S7-1500 PLCs. If you are interested in learning more about how connection resources are managed in SIMATIC PLCs, you can check the SIOS entry "Comparison: How are the communication resources managed in the S7-300 and S7-1500?"
Now that we understand what Open User Communication is and how Open User Communication uses Connection Resources in the PLC, let's talk about some of the advantages and disadvantages of using Open User Communication.
Most of the protocols supported by Open User Communication like TCP and UDP are industry standard protocols. This means that they are supported by devices supplied by other vendors. If you are trying to communicate data between a S7 PLC and a third party device, TCP on Open User Communication is a very common, easy way to do this.
Communication with third party devices could also be achieved using Modbus/TCP, however TCP is a more common, modern communication protocol.
The TCP protocol has diagnostics built in so it is understand if the PLC is connected to its partner and if data is being sent or received. As we'll see later on, TIA Portal also includes some useful features for troubleshooting Open User Communication connections while online with the PLC.
This is a big advantage of other communication protocols like S7 Communication (PUT/GET) where diagnostics has to be engineered by the user.
The main advantage of the TCP protocol over older communication protocols used by Siemens, like the ISO protocol, is that TCP can be routed over ethernet. This means that Open User Communication with TCP or UDP can be used to communicate with devices in other subnets of a local network or over the internet.
The Open User Communication blocks in TIA Portal, TSEND_C and TRCV_C, have an easy-to-use set up wizard. This makes engineering TCP or UDP communication between two PLCs incredibly easy.
Extended instructions can be used for Open User Communication which provide security and encryption. More on those extended instructions later.
Since TCP is a connection oriented communication protocol, both the client (sender) and server (receiver) have to be programmed in order to transmit data using Open User Communication with TCP.
This involves more engineering work than single sided communication protocols like S7 (PUT/GET) Communication where only one side has to be programmed.
Since a TCP connection is non-deterministic, it can take some time for the server and client to detect that a connection has been broken. This means that the diagnostic status of the Open User Communication blocks may report an error some time after the connection has actually been broken.
The rest of this article is a tutorial that describes the steps involved in using Open User Communication blocks to set up a connection between two S7-1500 PLCs and transmit data. In this tutorial, we will be setting up a Programmed Connection that is managed by the TRCV_C and TSEND_C blocks. These blocks have combined functionality that manages connecting to a partner, transmitting or receiving data, disconnecting from a partner.
In TIA Portal, I have created a new project and added two S7-1500 PLCs. In the Network view, I have connected both PLCs together on the same subnet.
In PLC_1, the PLC which is sending data, I have enabled the clock byte at MB0 so that we have some dynamic data to send to the receiving PLC.
In PLC_1, I have created a new global DB to store the data to be sent to the other PLC called DB_Data. Since Open User Communication is compatible with Optimized Blocks, this DB can be optimized or unoptimized.
In the Main OB, I move the Clock Byte's data into an element of DB_Data for sending.
PLC_1 is the sender, or client, in the project so in PLC_1 I create a call to TSEND_C. This instruction can be found in the Instructions tab under Communication > Open user communication. In this same folder, there are other instructions which can be used to control communication connections in a more granular way than what is possible with the TSEND_C and TRCV_C blocks.
After creating an instance DB for the call to TSEND_C, we can tag up the block call. The most important pins here are;
Next, I will parameterize the CONNECT pin using TIA Portal's built-in wizard. To launch the wizard, click on the icon in the top right corner of the TSEND_C block and expand the properties pane at the bottom of TIA Portal.
In the Configuration tab, click the Partner dropdown to specify the partner device. You can choose 'Unspecified' to configure the connection with a device that is not in the same project or select a PLC in the same project. The advantage of having the partner PLC in the same project is that TIA Portal will automatically populate the data for the partner device for you.
Other options such as multicast and broadcast are available but they are beyond the scope of this tutorial.
Next, we have to specify the configuration mode of the connection. As I mentioned previously, you could have a configured connection, which is a connection that is hardcoded in the PLC during the engineering phase or a programmed connection, which is a connection that is connected and disconnected within the user program. In this example, we will create a programmed connection. The default configuration mode, "Use program blocks" is the mode required to create a programmed connection.
To set up a new programmed connection, click on "<new>" in the connection data dropdown menu.
When you a create a new connection data instance, TIA goes out and creates a DB to hold the connection data and fills any missing data like the connection ID.
If you want, you can open and monitor the Connection Data DB, PLC_1_Send_DB by opening it at Program blocks > System blocks > System resources > PLC_1_Send_DB. When you open the DB, you will see that this a DB derived from the data type TCON_IP_V4. TCON_IP_V4 is a Siemens data structure used to store all data related to a TCP connection.
As you can see, TIA Portal has automatically filled in all of the required information in this DB to enable communications with the remote PLC. In case you want to change any of the connection properties, the elements of this DB are;
Back in the Configuration tab of the TSEND_C instruction, we also have to create a connection data instance for the receiving PLC. In the Connection data dropdown of the partner device, click on <new> to create the connection data instance.
Since both PLCs are in the same project, TIA Portal can go out and create the connection data DB in the other PLC automatically.
Now the sending side of the connection is completely configured.
PLC_2 is the receiver, or server. In the Main OB of PLC_2, I create a call to TRCV_C which manages the server's connection to the client device. Again, this instruction can be found in Instructions > Communication > Open user communication.
After creating an instance DB for the call to TRCV_C, we can tag up the block call. The most important pins here are;
To parameterize the CONNECT launch the configuration wizard by clicking on the icon in the top right corner of the TRCV_C. The Configuration tab of the TRCV_C block opens in the bottom pane of TIA Portal.
The good news is that, because the client is in the same project, we have less work to do here to configure the server connection. Once again, select I specify the partner device in the partner dropdown. In this case, I will select PLC_1, the client PLC in the project. When I select a PLC from the same project, all of the information about the device is automatically filled out including the interface, subnet, and IP address.
In the connection data dropdown, we can select the connection data instance that we previously created while configuring the TSEND_C block. When you select the existing connection data instance, all of the previously configured information is imported to the configuration.
Now the server side of the connection is completely configured.
With both sides of the connection completely configured, we can download user program to both PLCs and Go Online. Because we have added system blocks, a full compile and download is required, so the PLCs will be stopped during download.
When you Go Online and monitor the Main OB in both PLCs, you should see that the status pin of the TSEND_C and TRCV_C instructions are 16#7000. This value indicates that no job is being processed.
In the project, modify the value of M_Send_Data to TRUE so that the client PLC will actively try to establish a connection with the server PLC. The status word updates to 16#7002 to indicate that the client is attempting to establish a connection.
In the server PLC, modify the value of M_Enable to TRUE to enable a connection with the client. You should see the status pin of the TSEND_C block update to the value 16#7005, which indicates that a data transfer is in progress. Likewise the status pin on the TRCV_C block updates to the value 16#7006 which indicates that data is being received.
Monitoring the DATA pin of the TRCV_C blocks also shows the data being received by the server PLC.
As well as diagnostics via the STATUS pin, TIA Portal provides extended diagnostics for Open User Communication in the UI. To open the connection diagnostics, click on the diagnostics icon in the top right corner of the TSEND_C or TRCV_C instruction. The Hardware Config opens.
Switch to the connections tab in the right pane and select the connection to be diagnosed. In this case, we are diagnosing connection 1.
Finally, in the bottom pane open the Connection Information tab in the Diagnostics tab. Here you can see information about the connection as well as extended diagnostic information for troubleshooting the connection like the error message for the last connection termination.
In this article, we learned what Open User Communication is, what protocols are supported by Open User Communication, and how we can use the Open User Communication blocks TSEND_C and TRCV_C to communicate data between two S7 PLCs using the TCP protocol.
Open User Communication is a modern way to communicate between PLCs and with other devices. Open User Communication is commonly used because it is faster than Modbus/TCP and, unlike the S7 Communication protocol, it can be routed over Ethernet.
The only major disadvantage to working with Open User Communication is that both sides of the connection must be engineered. This means that there is more effort involved in realizing an Open User Communication connection than an S7 Communication connection.
Sign up to the mailing list to get a new post about industrial automation and controls engineering delivered to your inbox every week.
Learn the skills you need to start your journey as a PLC programmer. Enroll in PLC Bootcamp to learn how to write and test your first PLC program for free.