EtherNet/IP capabilities and limits
| Parameter | Detail |
|---|---|
| Ethernet/IP Adapter | |
| Configurable cyclic update | 1 - 20ms Default: 2ms |
| Maxinum number of assembly instances | 128 |
| Maximum number of connections | 128 (shared with scanner) |
| Minimum performance specifications | 1 connection 128 bytes @ 1ms 10 connections 500 bytes @ 10ms |
| Ethernet/IP Scanner | |
| Maximum number of connections | 128 (shared with adapter) |
| Minimum performance specifications | 1 connection 128 bytes @ 1ms 4 connections 500 bytes @ 4ms 10 connections 500 bytes @ 10ms 100 connections 500 bytes @ 50ms |
A connection is a single assembly-instance-pair (T2O + O2T) which is exchanging data cyclically between an adapter and a scanner. Connections are established by "ForwardOpen" commands over the wire.
Adapter:
When the iC922x is an adapter, the number of scanners that may try to connect is unknown.T2O instances can be connected-to by multiple scanners. The overall system design may change over time, etc.
So, the number of adapter instances and the number of incoming remote scanner connections are not directly related.
Each incoming connection (T2O<->O2T instance-pair) from a remote scanner consumes one connection from the local stack.
Scanner:
Each "Generic Adapter Device" on the scanner side is also a single connection (T2O<->O2T instance-pair), and also consumes one connection on the local stack. The stack's connection pool is shared between the local adapter and local scanner components.
An example scenario:
- Configure the local EIP scanner with 20 "Generic Adapter Device" connections. These might point to different IP addresses or they might all point to the same IP address, but different instance-pairs.
- This will always consume 20 connection-IDs from the total pool of 128, leaving 108 available for adapter use.
- Configure the local EIP adapter with 10 T2O instances and 10 O2T instances
- The adapter might get 0, 1, 10, 20, or even more scanners connecting to these instances, in all sorts of ways. It is difficult, without knowing all the details of all the remote scanners which **might** be on your system, whether they keep connections open all the time or connect only when needed, etc.
- When a connection from the remote scanner times out or is otherwise disconnected, it will linger around for a little while in the local stack before it gets cleaned up. During this time, the remote scanner might try to open a new connection, temporarily consuming more than one connection from the pool.
- This is why the user should leave at least some buffer in the number of connections in the overall system design.
- If the connection-pool is full, and additional scanners attempt to open connections, then either:
- it will get an informative error-response indicating that the conneciton pool is exhausted, OR
- it will timeout on the TCP connect (which is not the same as an EIP connection), which would appear as though adapter-is-offline to the remote scanner.