PLC - PLC Communication with PUT/GET (S7 Communication)

Advantages, Disadvantages, and an Application Example

Often, communication between multiple PLCs is required in automation projects.

In modern PLCs, there are so many options for communication available that it can be hard to decide which one to use. Each communication option has advantages and disadvantages, as well as a unique way of working.

In this article, I’ll provide a quick start guide for configuring S7 Communication (PUT/GET) between two S7 PLCs.

In the next sections, I will;

  • Explain the advantages of using S7 Communication
  • Explain the disadvantages of using S7 Communication
  • Demonstrate how to set up S7 Communication between two PLCs using the PUT instruction

Advantages of S7 Communication

S7 Communication is a single-sided mechanism

S7 Communication is a popular way to communicate between PLCs because it is a single-sided communication protocol.

That means that you only have to program the communication in one PLC. Using the PUT/GET instruction blocks this PLC can exchange data with a partner whose program has not been modified.

S7 Communication can access any part of the partner

To be honest, I wasn’t sure if this was an advantage or a disadvantage. Even if it’s a security nightmare, it’s a convenient feature that you can use PUT/GET instructions to read and write data from any part of the partner CPU.

This means that you can read and write data from memory areas, data blocks, input areas, and output areas of a partner PLC. Convenient, but potentially dangerous too.

Disadvantages of S7 Communication

S7 Communication does not have security

Once S7 Communication is enabled in a CPU, there is no way to block communication with a partner device.

This means that any device on the same network can read and write data to the CPU using the S7 Communication protocol.

S7 Communication isn’t compatible with optimized blocks

Since S7 Communication is based on pointers and absolute addresses, it is not compatible with optimized blocks.

When you work with unoptimized blocks in a project, you miss out on many of the important innovations in S7–1200 and S7–1500 PLCs including space-optimized storage for S7–1500 PLCs and speed-optimized access for S7–1200 PLCs.

S7 Communication is only suitable for small amounts of data

S7 Communication is not suited to transferring large amounts of data between PLCs.

The maximum amount of data that can be sent per job via the PUT/GET instructions is 160 bytes for S7–1200 PLCs and 880 bytes for S7–1500 PLCs.

Using S7 Communication for PLC to PLC Communication

Hardware Configuration

To demonstrate how to configure S7 Communication for PLC to PLC communication, I’ll start a new TIA Portal project and add PLCs to the Hardware Configuration.

In S7–1200 and S7–1500 PLCs, S7 Communication is disabled by default. In order for these two PLCs to communicate via S7 Communication, S7 Communication must be enabled in both PLCs.

You can enable S7 Communication in the PLC properties, under the ‘Protection and Security’ tab.

Enable S7 Communication in the PLC Configuration

Next, I’ll create an S7 Connection between the two PLCs. I can do this by switching the display to connections (1) and choosing ‘S7 connection’ in the connection type dropdown menu (2).

Choose S7 connection in the connection type dropdown

With the connection type selected, I can click and drag from the Profinet connection of one CPU to the other to draw the S7 connection between the PLCs.

Once the S7 connection is created, your Hardware Configuration should look like this:

S7 Connection after configuration

Software Configuration

In PLC_1 (the sending PLC), create a new Data Block called ‘DB_PUT_Data’. As the name implies, this Data Block will store the data that we are sending for the S7 Communication PUT instruction.

We will send the Clock Byte to PLC_2. Inside of DB_PUT_Data, declare a static variable ‘Clock_Byte’ of type Byte to store the Clock Byte (1).

The PUT and GET instructions only work on unoptimized Data Blocks, so be sure to disable ‘Optimized block access’ in the Data Block’s properties (2).

Create and configure the block DB_PUT_Data

Open OB1 and move the Clock Byte to DB_PUT_Data for sending.

Drag the ‘PUT’ function from the Instructions task card and drop it into network 2 of OB1. The ‘PUT’ and ‘GET’ functions are located in the Communication > S7 communication folder.

Create a call to the PUT function block

If you’re comfortable with pointers, then you can parameterize the block’s interface manually.

Otherwise, you can click the ‘Start Configuration’ button to open the PUT configuration wizard.

Click ‘Start configuration’

The configuration wizard opens and shows you that the connection is not correctly configured.

We can see that we have to specify the connection partner.

The connection is not correctly configured

The connection partner can be ‘unspecified’ or another PLC in the same project.

When you choose to use an unspecified connection partner, you can fill in the IP address of the device to communicate with.

Connection configuration with an unspecified partner

When you choose to communicate with another PLC in the same project, TIA Portal automatically configures the connection details for you based on the hardware configuration of the other PLC.

Connection configuration with another PLC in the same project

In the ‘Block parameter’ tab, you can easily create the pointers to the ‘Write area’ (ADDR_1), where the data will be written to on the partner PLC, and the ‘Send area’ (SD_1), where the data to be sent is stored.

Fill in the required information for these parameters as shown below.

Use the configuration wizard to create pointers

Minimize the configuration wizard to see how the block has been parameterized in OB1:

Result of the configuration wizard

Finally, I’ve programmed some logic to continuously PUT data in the partner PLC while the memory bit ‘M_PUT’ is true.

The logic for trigger PUTting of the data

With our configuration and programming complete, we can download the two PLCs and check if the communication is working.

In OB1 of PLC_1, toggle M_PUT to true to start the communication. In PLC_2, monitor the contents of QB0 in a watch table to make sure that it’s receiving the data.

In this example, we can see that QB0 of PLC_2 has changed from 16#0 to the contents of the clock byte and is being updated regularly:

PLC_2 is receiving the clock byte

You can see in this example that we are writing directly to the output area of the partner PLC. This is potentially very dangerous and demonstrates why PUT/GET instructions (and S7 Communication in general) should be used with extreme caution.

Wrap Up

In this article, we’ve looked at how to communicate between two PLCs using the S7 Communication protocol.

The main advantage of using the S7 Communication protocol is that it is a single-sided configuration. We only have to update the program in one PLC to exchange data in both directions with a partner PLC.

However, there are some disadvantages to using the S7 Communication protocol too. The main concern is that there is no security for this communication protocol — once it’s enabled in a PLC, that PLC is open to communication with any partner.

After talking about the advantages and disadvantages of S7 Communication, we looked at how to set up communication between two PLCs using PUT and GET instructions. This included,

  • Configuring the PLC properties
  • Configuring the hardware
  • Configuring the software

This overview is more than enough to get started with S7 Communication.

For those of you who want to dive deeper into the protocol, I suggest checking this document from Siemens: S7 Communication with PUT/GET.

Latest articles