What Is CIP Unconnected Messaging (UCMM)?

Back to Blog

How Unconnected Messaging Works

Connected messaging sets up a connection first - reserving resources, agreeing timing - and then exchanges data over it. Unconnected messaging skips that: the UCMM simply sends an explicit request to a target and waits for the response, with nothing established beforehand. There is no connection object, no reserved resource at either end, and no timeout tracking - just a request and a reply. This makes it lightweight for one-off interactions where setting up a connection would be more overhead than the single request justifies.

The UCMM is how a tool talks to a device it has never spoken to. A browse or discovery tool reads the Identity object of every device on a network with unconnected requests, because it would be absurd to establish a connection to each device just to ask what it is. One-shot diagnostics, occasional configuration reads, and discovery all naturally use unconnected messaging.

Crucially, unconnected messaging is also how connections themselves are born. The Forward_Open that establishes a connection is typically delivered as an unconnected message to the target's Connection Manager. So unconnected messaging is not just for casual reads - it is the bootstrap for the entire connected world. Once the connection exists, ongoing traffic moves over it, but the request that created it arrived unconnected.

Where Unconnected Messaging Is the Wrong Choice

The very thing that makes unconnected messaging convenient - no reserved resources, no setup - makes it unsuitable for anything that must be reliable or timely at volume. There is no connection to guarantee resources, no keepalive to detect a silent peer, and each request stands alone. Sending a high rate of unconnected requests is inefficient compared with establishing a connection once and reusing it, because every request pays the full path-and-response cost with none of a connection's amortization.

The correct pattern for repeated explicit access is to open a connected (Class 3) explicit connection and reuse it, as a MSG instruction can be configured to do. Unconnected is for the genuinely occasional or the bootstrap; connected is for the repeated. Choosing unconnected for a steady stream of reads loads the device's UCMM handling and gives you none of the reliability a connection provides, a distinction that maps onto the broader CIP connection types.

What a UCMM Request Looks Like on the Wire

On EtherNet/IP, explicit messaging travels over TCP port 44818 through the encapsulation layer, and the encapsulation command distinguishes the two explicit worlds: unconnected requests ride in SendRRData, while connected explicit traffic uses SendUnitData over an established connection. Inside the unconnected request sits the CIP essentials - a service code saying what to do, a path naming the class, instance, and attribute to do it to, and any request data. The reply carries a general status code that says exactly how the target felt about the request, which is why capturing traffic during a dispute settles it quickly.

Reaching a target that is not directly on the wire adds one wrapper: the request is embedded in the Connection Manager's Unconnected_Send service with a route path, and each bridge or backplane hop unwraps one path segment and forwards the rest. This has a useful diagnostic consequence - a bad route path fails at the hop that could not resolve its segment, so a path-related error tells you where along the route the request died, not just that it died.

Unconnected and Connected Explicit, Side by Side

The practical differences compress into a small table.

	Unconnected (UCMM)	Connected explicit (Class 3)
Setup	None - the request goes straight to the target	Forward_Open first, then traffic over the connection
Resources	Nothing reserved at either end	Connection object held at both ends
Timeout detection	Only the requester's own timer	Connection timeout monitored at both ends
Best fit	Discovery, one-shot reads, bootstrapping connections	Repeated explicit reads and writes

Read down the columns and the design rule writes itself: anything that happens once per device per session belongs on the left, and anything that happens on a schedule belongs on the right. The gray zone is the occasional-but-recurring request - a diagnostic read every few minutes, say - and the deciding factor there is usually how many other unconnected consumers the target already serves.

When UCMM Requests Fail: Symptoms and Causes

Devices service a limited number of simultaneous unconnected requests, and the limit is device-specific, per the manufacturer's documentation. Exhaustion has a distinctive signature: browse and configuration tools time out sporadically while established I/O keeps running untouched, because I/O owns reserved connection resources and UCMM traffic is handled from whatever capacity remains. The situation builds innocently - a scan tool here, a data collector doing unconnected polls there - until the pool is empty at busy moments and every tool's user blames the network.

Diagnosis starts with reading the reply instead of assuming. An error response with a general status tells you the request arrived and was refused, and reading a CIP general status code narrows the cause to a path, service, or data problem; no response at all points to a wrong route, a dead device, or resource exhaustion. When the same unconnected poll fails intermittently on a schedule, the durable fix is rarely retry tuning - it is moving that traffic onto a connection established with a Forward_Open request so the resources are reserved once and the per-request gamble disappears.

Frequently Asked Questions