How to Budget EtherNet/IP Connections on a Controller

Count Every Connection the Controller Terminates

The connection pool is consumed by more than the obvious I/O, so list every consumer. Each direct implicit connection to a remote adapter costs one connection. Each produced or consumed tag costs one, and a produced tag consumed by several controllers can cost one per consumer depending on how it is multicast, which is where the concept of a produced/consumed tag intersects the count. Listen-only connections that a second controller opens to your device also draw from the target's pool, so a shared device is more expensive than it looks. Write one line per connection so nothing hides.

Explicit messaging is the category people forget in the budget. Every unconnected message can be sent through the shared unconnected buffer, but connected explicit messages, and the connections HMIs and data historians open to read tags, each hold a connection open for as long as they are active. A busy plant with several HMI clients and a monitoring gateway polling the controller can quietly consume a meaningful slice of the pool. Count these deliberately, because they scale with how many systems talk to the controller, and that number tends to grow over the life of the plant.

Distinguish connections that the controller originates from connections it merely terminates as a target, because different limits can apply to each role and to the Ethernet module versus the controller itself. A communication module has its own connection ceiling separate from the controller's, and a design can pass the controller budget while overflowing the module. Read both limits from the datasheets and tally the count against each, the same discipline you use when you budget packet load in sizing an RPI against bandwidth.

Use Rack-Optimized Connections and Leave Headroom

The strongest lever for reclaiming connection count is the rack-optimized connection. Instead of opening a direct connection to every digital module in a remote rack, a rack-optimized connection folds all the rack's digital input and output data into a single connection to the adapter. A rack of eight digital modules that would cost eight direct connections costs one when rack-optimized, an eight-to-one saving that can be the difference between a design that fits and one that does not. The tradeoff is that rack-optimized data updates as a block on one RPI and does not carry the per-module status that a direct connection provides, so analog modules and any module whose diagnostics you need are usually kept as direct connections.

Mixing the two is normal and deliberate: rack-optimize the plain digital modules to save count, keep analog and diagnostic-critical modules direct for their per-module data. This mixed strategy is usually how a dense rack fits inside both the connection budget and the packet budget at once. Decide the mix module by module based on whether you need that module's individual status, not by a blanket rule.

Whatever total you arrive at, do not fill the pool. Leave clear headroom below the controller's published limit for the connections that appear after commissioning: an added HMI, a temporary laptop running a configuration tool, a new monitoring gateway, a produced tag a neighboring cell asks for next year. A controller run right up to its connection ceiling has no room to absorb any of these, and the failure mode is a connection that silently will not open rather than a clear warning. Headroom is cheap insurance against a change request that would otherwise force a redesign.

Frequently Asked Questions