What Are T-to-O and O-to-T in CIP Connections?

Back to Blog

Originator, Target, and the Two Directions

A CIP connection has two ends with defined roles. The originator is the device that opens the connection - in EtherNet/IP I/O, that is the scanner, usually the controller. The target is the device the connection is opened to - the adapter, usually a remote rack, drive, or sensor. This originator and target framing is fixed for a given connection and comes straight from who issued the Forward_Open, mirroring the scanner and adapter roles.

Given those roles, the two data directions name themselves. O-to-T, originator-to-target, is data going from the controller out to the device - the controller's outputs: commands, setpoints, output states. T-to-O, target-to-originator, is data coming from the device back to the controller - the device's inputs to the control system: process values, statuses. So from the controller's ordinary point of view, O-to-T is output and T-to-O is input, and the labels are simply naming the same thing by direction of flow rather than by controller perspective.

Each direction is independent. O-to-T has its own assembly, its own byte size, and can have its own RPI; T-to-O likewise. A connection is really two data streams glued together by one Forward_Open, and both streams are negotiated at open. This is why a connection can be fine in one direction and wrong in the other, and why sizing errors are always specific to a direction.

Why the Directions Cause Configuration Errors

The directional labels cause trouble because they invite two mistakes. The first is mapping the wrong assembly to a direction - putting the input assembly where the output belongs - which either refuses the connection on a size mismatch or, worse, connects but exchanges the wrong data. The second is sizing a direction wrong, entering the byte count for one assembly against the other, which the Forward_Open rejects. Both trace back to keeping O-to-T and T-to-O straight against the device's documented input and output assemblies.

The discipline that avoids this is to anchor on the device datasheet's own labeling. The datasheet says which assembly instance is the input (the data the device produces, T-to-O) and which is the output (the data it consumes, O-to-T), with the sizes for each. Matching those to the connection's O-to-T and T-to-O fields directly, rather than reasoning about direction from scratch each time, is what keeps them correct. The sizes feed the Forward_Open request, which is where a direction error surfaces as a status code.

RPI, Timeouts, and Heartbeats per Direction

Because the two directions are independent streams, their timing is independent too. Each direction has its own RPI - the interval at which its data is produced - and a connection can legitimately run a fast T-to-O for responsive inputs alongside a slower O-to-T where outputs change rarely. The timeout for each direction derives from its own RPI and a timeout multiplier, so slowing an RPI also stretches how long a lost stream takes to be declared dead. Guidance on picking the values is in choosing an RPI.

Input-only connections make the direction split vivid. A listen-only or input-only connection still has an O-to-T half, but it carries no output data - just a heartbeat the originator produces so the target knows its consumer is alive. When that heartbeat stops, the target times out the connection even though no outputs were ever involved. Seeing an O-to-T stream of essentially empty packets in a capture is therefore normal for these connection types, not a fault.

The Run/Idle Header and the Four-Byte Surprise

The O-to-T direction usually carries something besides output bytes: a 32-bit run/idle header prepended to the data, whose run bit tells the target whether the originator is in Run mode or Idle. On Idle, a well-behaved device discards the received output data and applies its configured idle action - hold last state or go to a safe state - which is why outputs can drop out when a controller is switched to program mode even though the connection stays up.

That header is also behind one of the most common sizing mysteries. The header is exactly four bytes, fixed by the specification, and configuration tools differ on whether the size they ask for includes it. When a connection is refused on a size mismatch that is off by exactly four bytes in the O-to-T direction, the run/idle header setting is almost always the culprit - one side counting it, the other not. T-to-O may use a header or not depending on the connection format the device documents, so check both directions against the datasheet rather than assuming symmetry.

A Direction-by-Direction Reference

When a connection misbehaves, walk it one direction at a time against this map:

Label	Flow	Controller view	Typical contents
O-to-T	Originator to target	Outputs	Commands, setpoints, output states, run/idle header, or heartbeat only
T-to-O	Target to originator	Inputs	Process values, device status, diagnostics

In a packet capture the two directions appear as separate streams with separate connection IDs, which makes direction-specific faults visible. A T-to-O stream that stops arriving while O-to-T continues means the device quit producing - power, an internal fault, or a network path problem on the return leg such as multicast filtering - while a stopped O-to-T implicates the controller side. When the connection is refused at open rather than dying later, decode the error against the CIP general status code list before changing anything, because the status usually names the offending direction's size or timing outright.

Frequently Asked Questions