What Is a CIP Connection Type?
When you read that EtherNet/IP I/O is a Class 1 connection and a MSG instruction opens a Class 3 connection, those class numbers are transport classes, and they describe how a CIP connection behaves. This page explains the CIP connection types - the transport classes that distinguish cyclic I/O from request-response, and connected messaging from unconnected - so the terms in device manuals and diagnostic tools become concrete.
CIP Connection Types in one line: A CIP connection type is defined by its transport class. Class 0 and Class 1 carry cyclic I/O (implicit messaging), with Class 1 adding a sequence count. Class 2 and Class 3 carry request-response (explicit messaging), with Class 3 the common connected-explicit case. Unconnected messaging (UCMM) sends explicit requests with no established connection at all.
Transport Classes 0 Through 3
CIP defines transport classes that describe the run-time behavior of a connection. Class 0 and Class 1 are the I/O transport classes: they move data cyclically in a producer/consumer pattern with no per-packet acknowledgment, which is what implicit messaging needs. The practical difference between them is that Class 1 adds a 16-bit sequence count to each packet so the consumer can detect a missed or out-of-order update, while Class 0 omits it. Most EtherNet/IP I/O uses Class 1 for that reason.
Class 2 and Class 3 are the messaging transport classes: they carry request-response traffic over an established connection. Class 3 is the one engineers meet most often, because a connected explicit message - a MSG instruction that opens and keeps a connection - runs as a Class 3 connection. The connection is set up once and reused for repeated requests, which is cheaper than negotiating each time. Class 2 exists but is less commonly configured directly in typical controller work.
The key mental model is that transport class is orthogonal to what the data means. The same assembly can, in principle, move over Class 0 or Class 1; the class describes the delivery behavior - cyclic versus request-response, sequenced versus not - rather than the payload. This is why implicit versus explicit messaging maps cleanly onto class 0/1 versus class 2/3.
Connected Versus Unconnected Messaging
Beneath the transport classes sits a more basic split: whether a connection exists at all. Connected messaging establishes a CIP connection first - via a Forward_Open - and then exchanges data over it, whether that data is cyclic I/O (Class 1) or repeated explicit requests (Class 3). The connection reserves resources at both ends and gives the exchange a defined lifetime and timeout, which is what makes I/O deterministic and what lets a device detect that its owner has gone silent.
Unconnected messaging, the Unconnected Message Manager or UCMM, sends a single explicit request with no prior connection setup. It is how a browse tool reads an identity attribute from a device it has never talked to, and how the very Forward_Open that opens a connection is itself delivered. Unconnected messaging is convenient for one-shots but has no reserved resources and no keepalive, so it is unsuitable for anything that must be reliable or timed. The details are in CIP unconnected messaging.
Why the Connection Type Shows Up in Diagnostics
Connection types matter when you read diagnostics because the counters and timeouts differ by type. An I/O (Class 1) connection has a connection timeout derived from its RPI, and when the consumer stops hearing updates it declares the connection timed out and faults the I/O. An explicit (Class 3) connection has its own inactivity timeout. When a diagnostic screen distinguishes I/O connections from messaging connections, it is showing you these different objects, each with its own health.
Knowing the type also tells you where to look when connections run out. A device advertises how many connections of each kind it can support, and exhausting the explicit-message connection pool - often by opening MSG connections faster than they close - produces resource-unavailable errors even though I/O is fine. The CIP general status codes distinguish these cases. A monitoring platform such as Merobix reads only the resulting controller tags, so keeping the connection types straight at the controller is what keeps the upstream data trustworthy.
Frequently Asked Questions
What is the difference between Class 1 and Class 3 CIP connections?
Class 1 is an I/O connection: cyclic producer/consumer data with a sequence count, used for real-time I/O over UDP. Class 3 is a connected explicit-messaging connection: request-response over TCP, set up once and reused for repeated reads and writes such as a MSG instruction. Class 1 moves the continuous I/O image; Class 3 moves on-demand object access.
What is the difference between connected and unconnected messaging?
Connected messaging opens a CIP connection first with a Forward_Open, reserving resources and giving the exchange a timeout and keepalive - used for I/O and for repeated explicit traffic. Unconnected messaging (UCMM) sends a single explicit request with no setup, used for one-shot reads like a browse tool identifying a device, or for delivering the Forward_Open itself.
Which transport class does EtherNet/IP I/O use?
Almost always Class 1. Class 1 carries cyclic producer/consumer I/O and adds a 16-bit sequence count so the consumer can detect a dropped or out-of-order update. Class 0 also carries I/O but omits the sequence count and is rarer. Both are implicit-messaging transport classes that run over UDP, distinct from the Class 3 connections that carry explicit messages.
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.