EtherNet/IP Performance Considerations

There are several areas to consider with regard to EtherNet/IP Performance:

• General Recommendations

• Considerations for RMC EtherNet/IP Performance

• Considerations for Master EtherNet/IP Performance

• Considerations for Network Performance

General Recommendations

The following recommendations will improve the performance and determinism of the network in general.

• Always use unicast I/O connections instead of multicast whenever possible. Notice that Allen-Bradley products only supported multicast connections prior to RSLogix 5000 v18.

• Do not use a lower RPI than you need. Usually an RPI of 10 ms or 20 ms is sufficient. Lowering the RPI will increase the load on every Ethernet component in the system, and beyond a certain point has no benefit. For example, if the RPI is lower than the scan time of the controlling PLC, then additional packets will not benefit the system.

• Never use hubs or other half-duplex switchgear. This will introduce collisions, which greatly reduce the scalability and determinism of a network.

• When using a multicast connection, never connect the EtherNet/IP I/O network to a general purpose network, except through a router. The multicast traffic on the EtherNet/IP network will be noticed by your IT department. Conversely, glitches on the general purpose network could affect your factory network. If only unicast I/O connections are used, then connecting to a general purpose network through a switch may be acceptable in some applications.

• Read Rockwell Automation’s EtherNet/IP Performance application guide (Publication ENET-AP001D-EN-P). It covers this subject in greater detail.

Considerations for RMC EtherNet/IP Performance

The RMC controllers support the following EtherNet/IP I/O bandwidth:

1 The RMC75E and RMC150E only support multiple I/O connections in multicast mode. The RMC200 supports multiple I/O connections in multicast or unicast mode. The first I/O connection always requires 2 packets per RPI. Subsequent multicast connections require 1 packet per RPI and subsequent unicast connection require 2 packets per RPI.

Considerations for Master EtherNet/IP Performance

The PLC EtherNet/IP I/O module must often support a large number of devices, including RMCs and other devices. Therefore, it is important to recognize the limits in bandwidth of your EtherNet/IP master controller, and to know how to determine the amount of bandwidth being utilized. This entire subject is covered in more detail in Rockwell Automation’s EtherNet/IP Performance application guide (Publication ENET-AP001D-EN-P), but will be addressed narrowly here for RMC connections.

Here are some published bandwidth limits for EtherNet/IP I/O controllers available as of this writing:

Notice that it is recommended that not more than 90% of this bandwidth be used on I/O connections.

The bandwidth required for each RMC depends on the RPI and the number of connections. The first connection requires 2 / RPI packets per second (where RPI is in seconds), and each additional connection requires 1 / RPI additional packets per second. The following chart summarizes the requirement:

Therefore, to determine the total bandwidth required for any group of RMCs being serviced by a single master EtherNet/IP I/O controller, simply add up the bandwidth requirement of each RMC connection. Usually the RPI for all RMCs will be set the same, so the total utilization can be calculated as shown:

Total Required Bandwidth = ( # of RMC connections ) x ( 2 / RPI )

Example

For 12 RMCs with an RPI of 20 ms each and one connection each, the total required bandwidth is 12 x ( 2 / 0.020 ), which is 1200 packets/second.

Using this formula, we can also calculate the maximum number of RMCs that can be supported by your controlling EtherNet/IP module:

Maximum Supported RMCs = Total Bandwidth x 90% / ( 2 / RPI )

Example

How may RMC connections can the 1756-EN2T support at a 10 ms RPI? The Total Bandwidth for the 1756-EN2T is 10000 packets/second, so the maximum number of RMC connections is found by 10000 x 90% / ( 2 / 0.010 ), which is 45 RMCs.

If the total bandwidth required exceeds 90% of the master EtherNet/IP I/O controller's bandwidth, then you will have to consider one of the following options:

• Increase the RPI for one or more of the RMC connections
  Increasing the RPI reduces the required bandwidth. For example, doubling the RPI will cut the bandwidth in half. Notice that in many cases, increasing the RPI comes at no cost to the system performance because the PLC may be unable to scan its ladder logic as frequently as the RPI.

• Replace the EtherNet/IP controller with a faster model
  If an EtherNet/IP controller with higher bandwidth is available for the same platform, then you may be able to upgrade the EtherNet/IP controller. For example, on the ControlLogix family, the 1756-ENET/B can be replaced by the 1756-ENBT or 1756-EN2T, or the 1756-ENBT can be replaced by the 1756-EN2T.

• Use multiple EtherNet/IP modules to divide the network
  By adding one or more additional EtherNet/IP communication modules to the PLC, each with its own isolated network with a smaller number of RMCs, the bandwidth requirement on each device is reduced. Notice that it is important that the individual networks are not connected to one another directly or through a switch, as this will largely defeat the benefits of dividing the network. It is acceptable to connect the networks using routers. However, it is important that someone with IT experience is consulted before doing so.

Example

Suppose one ControlLogix 1756-ENBT module will be controlling twenty-five (25) RMC connections. The intended RPI is 10.0 ms. Therefore the total bandwidth in packets/second is computed as follows:

The maximum allowable I/O load on the ENBT is 90% of 5000, which is 4500. Since 5000 is greater than 4500 packets/second, one of the following alternatives must be considered:

• Increase the RPI of one or more of the RMCs until the bandwidth is below 4500. Raising each to 12.0 ms or higher does this.

• Replace the 1756-ENBT with the 1756-EN2T. The bandwidth on the 1756-EN2T is 10,000 packets/second, which easily handles this load.

• Use two 1756-ENBT modules and divide the RMC connections between the two. For example, one could control 15 RMC connections (3000 packets/second), and the second could control 10 RMC connections (2000 packets/second), putting both within the recommended limits.

Considerations for Network Performance

The maximum amount of information that 100 Mbps Ethernet can carry in one direction is 100 million bits per second. If all packets on the network were EtherNet/IP I/O packets of the largest size supported by the RMC (125 four-byte REALs), then this would be a maximum of 21,600 packets/second (notice that packet overhead such as headers and inter-frame spacing are included in this estimate). The network utilization should be kept well below this maximum. As the utilization approaches the maximum, it becomes more and more likely that a packet will have to wait to get onto the wire, introducing small delays.

In addition to the limits of the wire itself, many devices have a maximum sustained rate that they can receive packets without falling behind in packet processing and eventually dropping packets. The RMC is one such device, since priority must be given to controlling motion above handling packets. No pre-determined maximum rate is currently available, but by reviewing the Ethernet Statistics in the devices, you can look to see if packets are being discarded.

Notice that EtherNet/IP multicast I/O connections can greatly impact the performance of an Ethernet network since—unlike unicast packets, which are sent directly to a single device—multicast packets are sent to all devices on the network by default. This increases the load on every device, including the switches, and each individual network segment.

If your network has a high utilization and/or network components are dropping packets due to high packet rates, you will want to look at ways of reducing the network utilization. There are three ways to reduce the network utilization:

• Change multicast I/O connections to Unicast
  As described above, multicast I/O connections can significantly increase the network load. Most applications do not require multicast I/O connections, but unfortunately because Rockwell did not support unicast I/O connections until RSLogix 5000 v18, most current EtherNet/IP installations use multicast. If you are using a EtherNet/IP controller that supports unicast and are not using multiple I/O connections per RMC, then you should make sure that all I/O connections are set up as unicast.

• Increase the RPI for one or more EtherNet/IP I/O connections
  The simplest way to reduce network utilization is to increase the RPI of EtherNet/IP I/O connections. Of course, this is only a possibility if the RPIs are unnecessarily low. This topic has been discussed above, so no more needs to be said here.

• Use multiple EtherNet/IP modules to divide the network
  By adding one or more additional EtherNet/IP communication modules to the PLC, each with its own isolated network with a smaller number of RMCs, the utilization on each sub-network is reduced. Notice that if multicast I/O connections are used, then it is important that the individual networks are not connected to one another directly or through a switch, as this will largely defeat the benefits of dividing the network. It is acceptable to connect the networks using routers. However, it is important that someone with IT experience is consulted before doing so.

• If using multicast I/O connections, use smarter switchgear
  As noted above, currently EtherNet/IP I/O connections generate a lot of multicast Ethernet traffic. This multicast traffic is treated like broadcast traffic by default, which means that every port on every switch in the network will send out a copy of each multicast packet, even though in most cases only one device on one port is interested in the packet. However, it is possible to be more efficient than this default behavior by using smarter switchgear to direct the multicast traffic only to those ports that are listening to the multicast traffic.

The current way of doing this uses a protocol called IGMP (Internet Group Management Protocol). Using IGMP to direct packets in switches to only the interested ports requires that (1) the switch supports IGMP Snooping, and (2) at least one switch or router connected to the network supports IGMP Query. Notice that some switches are now available that provide both IGMP Snooping and IGMP Query in the same switch.

See Also

EtherNet/IP Overview

Send comments on this topic.

Copyright © 2025 Delta Computer Systems, Inc. dba Delta Motion