What Is the CIP Connection Manager Object?
Behind every EtherNet/IP connection sits one object that sets it up, tracks it, and tears it down: the Connection Manager. Understanding it explains where connection resources come from, why a device runs out of them, and why some diagnostics report connection counts. This page explains what the CIP Connection Manager object is, what it does, and why its limits shape how many connections a device can hold.
CIP Connection Manager in one line: The CIP Connection Manager object (class code 0x06) is the object responsible for establishing, maintaining, and closing connections in a CIP device. It handles the Forward_Open and Forward_Close services, tracks each connection's state and timeout, and manages the finite pool of connection resources - which is why a device advertises a maximum number of connections it can support.
What the Connection Manager Does
The Connection Manager is class code 0x06, and it is the object that owns connections. When a Forward_Open arrives, the Connection Manager validates the request, allocates the resources for the connection, and sets up the tracking that keeps it alive. When a Forward_Close arrives, or when a connection times out, the Connection Manager releases those resources. Every I/O connection and every connected explicit connection in the device exists because the Connection Manager created and is maintaining it.
It also routes the connection-establishment traffic itself. The Forward_Open request is delivered to the Connection Manager, often as an unconnected message, and the Connection Manager decides whether the connection can be granted based on resources, the validity of the connection points and sizes, and the keying. So the Connection Manager is both the object that holds connections and the object that decides whether a new one may open.
Because it tracks each connection's timeout, the Connection Manager is what detects a silent connection and tears it down. When a consumer stops hearing an I/O producer for the connection-timeout period, it is the Connection Manager logic that declares the connection dead, frees its resources, and lets the fault propagate. This is the mechanism behind the timeouts described elsewhere - the RPI sets the interval, the Connection Manager enforces it.
The Connection Pool and Its Limits
A device has finite resources, so the Connection Manager can hold only a bounded number of connections at once. The device advertises this limit, and it is often split by type - so many I/O connections, so many explicit connections. This is why a device can happily run its I/O while refusing new explicit-message connections: the two draw from different parts of the pool, and one can be exhausted while the other is fine.
Exhausting the pool is a real and common failure. Opening explicit-message connections faster than they are closed - a MSG design that leaks connections - fills the explicit pool until new Forward_Opens are refused with a resource-unavailable status, even though the device is otherwise healthy. Recognizing this pattern requires knowing the pool exists and is managed by the Connection Manager. The CIP general status codes distinguish a resource exhaustion from a keying or sizing failure, which points you at the pool rather than the wiring.
Why the Connection Manager Shows Up in Diagnostics
Diagnostic screens that report how many connections a device is holding, or that let you see and reset connections, are reading and acting on the Connection Manager. When a device is near its connection limit, that is visible here, and it is the place to look when new connections are being refused for no obvious reason. Treating the connection count as a monitored quantity, not just a hidden internal, turns a mysterious intermittent failure into a capacity problem you can plan around.
For the broader architecture, the Connection Manager is entirely a field-and-controller concern; SCADA does not touch it. A monitoring platform such as Merobix reads the tags a controller exposes after the controller's Connection Manager interactions have set up the field connections. When field data goes intermittent, a Connection Manager running out of resources or timing out connections is a candidate root cause, and diagnosing it there restores the clean tags the SCADA layer trends. The relationship to the broader CIP connection types is that the Connection Manager is what instantiates each of those types.
Frequently Asked Questions
What is the CIP Connection Manager object?
It is class code 0x06, the object that establishes, maintains, and closes connections in a CIP device. It handles the Forward_Open and Forward_Close services, allocates and releases connection resources, and tracks each connection's timeout so it can detect and tear down a silent one. Every I/O and connected explicit connection in the device is created and managed by it.
Why does a device run out of connections?
Because the Connection Manager holds a finite pool of connection resources, often split between I/O and explicit connections. Opening explicit-message connections faster than they close - a leaking MSG design - can exhaust the explicit pool while I/O keeps running, so new Forward_Opens are refused with a resource-unavailable status even though the device is otherwise healthy. The device advertises its connection limits.
How does the Connection Manager detect a dead connection?
It tracks each connection's timeout, derived from the RPI and its multiplier. When a consumer hears no update for that period, the Connection Manager declares the connection timed out, frees its resources, and lets the fault propagate. This is the mechanism behind EtherNet/IP connection timeouts: the RPI sets the interval and the Connection Manager enforces the deadline.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.