PLC-PLC Communication with I-Device

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 I-Device in TIA Portal. In the next sections, I will;

• Give an introduction to I-Device
• Explain the advantages and disadvantages of I-Device
• Demonstrate how to set up I-Device communication between two PLCs in TIA Portal

I-Device 101

I-device is an extremely fast way to pass data between PLCs. It runs at the same speed as the Profinet bus in Real-Time (RT) or Isochronous Real-Time (IRT). This means that we can get down to a data transfer time of 1 or 2 milliseconds for sending data between PLCs.

Not only is I-device an incredibly fast way to transfer data, but it is also easy to set up. The configuration of I-device communication is done entirely at the hardware level so there is no software configuration required.

Once I-device communication has been set up, there are built-in diagnostics available to troubleshoot the connection between PLCs.

On top of this, I-device is a flexible communication protocol. It is capable of handling safety-certified communication, which means that safety related signals like e-stop statuses can be passed between PLCs using I-device, and I-device can be used to communicate with another third-party device that is Profinet enabled.

Like all communication protocols, I-device communication has its limits. One of the most important disadvantages of I-device communication is that all of the devices communicating via I-device must live in the same subnet. If you did want to pass data between subnets, it is still possible to do by using a PN/PN coupler.

Since I-device communication occurs at an I/O level, there is no security available for this communication and I-device communication uses actual I/O resources in the controller.

Based on these advantages and disadvantages, it becomes clear that I-device communication is appropriate for communicating small amounts of data very quickly between Profinet enabled devices in the same subnet. If you need to communicate with non-Profinet enabled, third-party systems then a communication protocol like Modbus/TCP might be more appropriate. If you need to communicate between devices on separate subnets, then a communication protocol that can be routed over Ethernet like TCP/IP is a better option. If you need to communicate between two S7 PLCs and don't have many I/O resources available in the control, then PUT/GET communication might be a better option provided you accept the security risks associated with it.

With all this in mind, let's have a look at how to set up I-device communication between two PLCs.

PLC-PLC Communication with I-Device

Project Set-Up

In TIA Portal, I have created a new project and added two PLCs. Both PLCs are IO Controllers.

In this example, PLC_1 will be an IO master for PLC_2. PLC_2 will act as both an IO master for its own IO slaves and an IO slave for PLC_1. We can do this configuration entirely in the hardware configuration without any software configuration.

Configure PLC_2

Click on the Ethernet port of PLC_2 and navigate to the Operating Mode section of the Properties pane to find the I-device configuration. Enable I-device communication by checking the IO device checkbox.

The Assigned IO controller configuration becomes available. We could leave this as "Not assigned" if the I-device master was in another project. In that case, we would set up our transfer areas and export the GSD file for this I-device.

This GSD file could then be imported into the other project as an IO Device in the Hardware Configuration.

In this example, both devices are in the same project, so we can browse directly to the device that will act as the IO controller.

Next, we want to fill in the Transfer Areas. The best practice here is to give meaningful names since these transfer areas are addressed symbolically in the user program. Since both controllers are in one project, we can define the addresses in both controllers simultaneously.

In this case, our IO controller will output information on QB 0. The same data will be received by the I-Device on IB 0. The length of the data to be transferred is one byte.

To send data in the opposite direction, you can simply click on the direction arrow.

Download and Test

In PLC_1, I have configured the clock byte as MB 0. In the Main OB, I use a MOVE instruction to transfer the Clock Byte to QB 0 to test the communication with PLC_2.

Now, I will compile and download both PLCs. Once the updates have been downloaded, there is no need to establish a connection - the communication between the devices is automatic and cyclical.

In a Watch Table in PLC_2, I can see that I am receiving the Clock Byte.

Wrap Up

In this post, we learned what I-Device communication is and how to set up PLC to PLC communication using I-Device.

Once again, I-Device is a simple way to exchange small amounts of data rapidly between devices on the same subnet. I-Device communication won't be appropriate for all applications, but I recommend it as a replacement for PUT/GET communication which is no longer recommended by Siemens.

If you want to learn more about I-Device communication, you can check out the SIOS article covering the topic here