How to setup EtherNet/IP communication for best performance (an example with SLIO Coupler)

This documentation shows the best practice on how to configure the basic settings of an EtherNet/IP generic device in order to achieve the best performance regarding communication.

Component Name	Version
iC922xM-EC / iC922xM-FSoE Controller	≥ 2024.3
iCube Engineer	≥ 2024.3
053-1IP01 SLIO Coupler	01V12.001

2. Supported Libraries

3. Solution details

Scope:

There are multiple ways to connect the Process Data Items of a generic device in an EtherNet/IP network. The most straightforward way to do it is to connect the PDIs of the adapter to global variables and manipulate the adapter's data with said variables. However, given the 50ms update time of the global variables, this is not the most time-efficient method for some applications that require faster communication times. This Application Note shows a method to get faster communications with EtherNet/IP adapters by using ports in Program Organization Units (POUs). However, bear in mind that EtherNet/IP architecture does not provide real-time communication and cannot be synchronous with any program task. Programs should not rely on exact times for this type of communication.

In the following example, an iC9226M-EC controller is used as the scanner, and an EtherNet/IP Coupler (with two 021-1BF00 digital input modules and two 022-1BF00 digital output modules) is used as the adapter. Some digital outputs are looped back to digital outputs so that the full roundtrip time can be seen on iCube Engineer's side by using the Logic Analyzer.

Setting up the project in iCube Engineer:

1. Create a project where at least the Data Types library (Y_DataTypes_Toolbox) is included.
2. Add a Generic Adapter Device to the EtherNet/IP node in the PLANT section.
3. Open the adapter's Settings tab under the EtherNet/IP node and fill in the information for the corresponding device (the picture below shows the settings used for the 053-1IP01 EtherNet/IP coupler in this example). RPI stands for Requested Packet Interval.
   
4. Add a program to the project and create two variables within it. In the Usage section, define one as IN Port and the other as OUT Port. The data type of the variables depends on the size of the device's input assembly instance and output assembly instance and should match the size defined in the adapter's setting windows (for example, in the image above, the assembly instance size is 496 bytes for both the input and the output and the ports, as seen in the following picture, are defined as arrays of 496 bytes).
   
5. Add one instance to the program to a task (preferably a fast task) under the Tasks and Events manager in the PLCnext node.
   
6. Navigate to the controller's GDS Port List in the PLCnext node and connect the variables created in step 4 to the respective ports of the EtherNet/IP device (O2T = Originator to Target = Output Assembly; T2O = Target to Originator = Input Assembly).
   
7. Write and Start the project.

Notes:

• The best-case scenario for the communication time between the EtherNet/IP adapter and the controller (scanner) can be calculated as RPI (Input assembly) + RPI (Output assembly) + the device's processing time. In this example, both RPIs are set to 2ms. The input delay of 021-1BF00 is 3ms (c.f. related technical manual), and the output delay (from "0" to "1") of 022-1BF00 is 30µs (negligible for the current example). This gives a best-case scenario of 7ms for the communication between the controller (scanner) and the device (adapter) doing a roundtrip communication. However, a few considerations need to be made:
• In practice, due to delayed network traffic or delays in either device's network stack, the total roundtrip time is likely to increase by a few milliseconds.
• The sampling of the port information depends on the task interval time, so the final time observed in the POU will be rounded up to multiples of said task interval. For example, in the given example, the task interval is 1ms, so the best-case scenario would still be 7ms, but if the task interval had been 6ms, then the 7ms needs to be rounded up to the closest multiple of 6ms, which is 12ms. Another factor that could add an extra task interval to the roundtrip time is the network traffic not lining up with the task update.
• To use the information obtained from the ports throughout the whole project, link global variables to the ports as seen in the following image and then use said global variables instead of the port variables to interact with the device.
  
• If the communication time with the EtherNet/IP adapter is not critical, simply connecting the adapter's PDIs to global variables without connecting the variables in the GDS Port List is also an option, as mentioned at the beginning of this document. See the following image for an example of a global variable connection.
  
• For higher RPIs, the lineup between network communication and task updates can further reduce the roundtrip time.
  

In this last section, the roundtrip time, as seen on the controller's side, is evaluated for both the POU ports method and the global variables method to see the advantages of the former.

For the POU port method, the best-case scenario for the settings used in this case is 7ms (as mentioned in the Notes section), but some extra time is expected in practice. When measured one time, a value of 9ms was observed for this configuration, as seen in the following image. Remember that this is not a fixed value for every roundtrip scan, and different measurements will lead to different times, but they should all be around a similar number, in this case, a few more milliseconds than 7ms.

As for the direct connection to global variables, a roundtrip time of 99ms was observed, as seen in the following image. Values between 50ms and 150ms are expected for the explained setup. In this case, the POU ports method led to an 11x faster roundtrip time, which shows the advantages of the first method.