PLC-PLC Communication with TCP/IP (Open User Communication)

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;

  • Give an introduction to Open User Communication in TIA Portal and SIMATIC systems
  • Explain how connection resources in a PLC work
  • Explain the advantages and disadvantages of Open User Communication
  • Demonstrate how to set up communication between two S7 PLCs using the TRCV_C and TSEND_C Open User Communication blocks.

What is Open User Communication?

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;

  • TCP
  • ISO on TCP
  • UDP

Let's look at each protocol in more detail.

TCP

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

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

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?"

Connection Resources

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.

Advantages of Open User Communication

Suitable for Third Party Devices

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.

Built-In Diagnostics

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.

Routable Over Ethernet

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.

Easy to Set Up

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.

Can be Used for Secure Communication

Extended instructions can be used for Open User Communication which provide security and encryption. More on those extended instructions later.

Disadvantages of Open User Communication

Both Sides Must Be Programmed

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.

Connection Error is not Immediate

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.

Using Open User Communication for PLC to PLC Communication

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.

Setup the Project

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.

Connect the PLCs 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.

Create a New Project with Two PLCs

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.

Prepare data for sending

Configure Sending Side (Client)

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.

TSEND_C

After creating an instance DB for the call to TSEND_C, we can tag up the block call. The most important pins here are;

  • REQ, which starts the send job on a rising edge. This bit will be true when our Send_Data memory bit is true, there is not a request active, and the current job is not done.
  • CONT, which controls the connection with the server. When CONT is TRUE a connection is established and maintained. When CONT is FALSE, the client disconnects from the server. I have connected the CONT pin with the same Send_Data memory bit used to start the send job.
  • CONNECT is a pointer to the structure which contains the connection description. For a TCP connection, this structure is the UDT TCON_IP_V4. We'll look at how to use the TSEND_C wizard to set up this structure in a moment.
  • DATA is a pointer to the data to be send from the client to the server.
Parameterize TSEND_C

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.

Open the TSEND_C Wizard

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.

Specify a partner device for the connection

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.

Create a new connection data structure for the connection

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.

Connection Data Instance

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.

PLC_1_Send_DB

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;

  • InterfaceId, the ID of the physical ethernet interface being used for communication. 64 is the standard interface ID for the first ethernet interface on Siemens PLCs. If you want to use a different interface, you can find its ID in the hardware configuration of the project.
  • ID, a unique identifier for the connection. Every Open User Communication connection in the project must have a unique ID.
  • ConnectionType, defines the communication protocol being used. The value 16#0B shows that the TCP protocol is being used in this connection. A value of 16#13 would indicate that the UDP protocol is being used.
  • ActiveEstablished identifies which device in the connection is responsible for establishing connection. A best practice to follow is that the sending device should establish connection while the receiving device listens passively for a connection.
  • RemoteAddress is the IP address of the device to connect to. For the sending (client) PLC, this must be filled out with the IP address of the other device. For the receiving (server) PLC, the RemoteAddress field can contain the IP address of the sending PLC or can be left as all 0's. When the RemoteAddress is left as 0's, the server PLC will accept a connection from any device.
  • Finally, we have the RemotePort and LocalPort configuration. In principle, you can use any ports you want to communicate between devices. Ports are generally specified to facilitate routing and firewalling in networks so that only packets from specified ports can travel on the network.

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.

Partner 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.

Connection Data instance for receiving PLC

Now the sending side of the connection is completely configured.

Configure the Receiving Side (Server)

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.

Create a call to TRCV_C

After creating an instance DB for the call to TRCV_C, we can tag up the block call. The most important pins here are;

  • EN_R, which enables the receiving of information from a client. I have connected a memory bit, M_Enable to this pin.
  • CONT, which enables the connection to the client. I have connected the same memory bit, M_Enable to this pin.
  • CONNECT, which contains the connection information for the communication connection. We'll parameterize this pin using the configuration wizard.
  • DATA, which is a pointer to the location where the received data should be stored. The structure of this data should match the structure of the data being sent by the client exactly. The received data can be stored in optimized blocks.
Parameterize TRCV_C

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.

Open the TRCV_C Configuration wizard

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.

Specify the partner device for the TRCV_C block

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.

Select the previously created connection data instance

Now the server side of the connection is completely configured.

Download and Test

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.

Download and Test

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.

Data is being received by the server

Connection Diagnostics

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.

Extended diagnostics for communication connections

Wrap Up

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.

Learn Something New Every Week

Sign up to the mailing list to get a new post about industrial automation and controls engineering delivered to your inbox every week.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

PLC Bootcamp

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.