Introduction

In a recent article, we covered “PROFINET Shared Device”, which gives a device the capability to share IO data with multiple controllers. This time we will discuss I-Device, which operates on the IO controller level. This optional feature allows a controller to be both a device and controller simultaneously, allowing for controller to controller (some might say peer to peer) communications with PROFINET IO.  There are many benefits of the functionality.  For example, it allows setup of communications between IO controllers from different manufacturers. In addition, interesting peer to peer application scenarios can be accomplished easily, since communications are configured rather than programmed.

Applications

One example where you may utilize I-Device is if you have a main IO controller/data concentrator and other “sub level” controllers which need the same information from the concentrator. Let’s imagine we are running a juice factory. In our factory, each machine needs to know the juice type for some local configuration. Like the box type on the packing machine or the label on the labeling machine. The sub level controllers act as IO device peers, the master controller sends the juice type to all of them.  Then the sub level controllers tell their local IO devices the current juice recipe.

Another reason for I-Device is to communicate between different controllers without writing a lot of communications code.  It gives you the capability to configure a fast (1 ms or less update time) PROFINET real-time connection (RT/IRT) between two or more controllers, even from different manufacturers. Implementation is uncomplicated, I -Devices are set up like a regular IO device on the controller. For programming, it’s only necessary to handle the IO logic. First, you will setup the I-Device by creating a configuration and max IO buffer size on the I-device controller.  Then you will export a GSD file of the I-Device and import that into the controller configuration tool to set up.  Then, each controller has an input and output buffer to move data to/from the partners in your application. The following diagram shows an example of an I-Device setup and the benefits:

Click to expand

Shared I-Device

Going back to our Shared Device discussion, an I-Device can optionally in most cases also be operated also as a shared device, meaning you can have multiple controllers reading/writing to the same controller as a shared device.  Perhaps we have two data concentrators or software redundancy?  This can lead to some really interesting application ideas and designs with PROFINET, as you’re not really limited in scope.

Terminology

To discuss the term I-Device further, the “I” stands for “intelligent” device.  This basically means that each controller has its own application program (logic).  For your information, some vendors may not use the term I-device, so double-check if your controller can also support device connections on the spec sheet.

Conclusion

In conclusion, I-Device is optional and straightforward. If your vendor supports it, there should be a way to generate and export a device GSD file and import it into other controller tools for setup.  The benefits are that an I-Device can be part of a modular architecture with higher level controllers, support multi-vendor communication in real time without special communication programming, and often times even operate as a shared device too.