What Is a DNP3 CROB (Control Relay Output Block)?
When a master closes a valve or trips a breaker over DNP3, the command travels as a very specific object: the control relay output block, or CROB. Anyone writing a control point map or diagnosing a command that fires the wrong way needs to know what a CROB carries. This page explains the CROB object, its control code, and the count and timing fields that shape how the output behaves.
DNP3 CROB Control Output in one line: A DNP3 CROB (control relay output block) is the object, in group 12, that a master uses to command a digital output on an outstation. It carries a control code selecting the action - trip, close, latch on, latch off, or pulse - plus a count of how many times to apply it and on/off timing for pulses. The CROB is the payload of a select, operate, or direct-operate command, so it defines exactly how the physical relay is driven.
What a CROB Command Carries
A CROB is more than an on/off bit. Its control code combines an operation type and a trip/close qualifier: latch-on and latch-off hold an output in a state, pulse-on and pulse-off drive it for a defined time, and the trip/close pair maps to the two coils of a control point such as a breaker. This structure is why DNP3 can command a momentary pulse to a spring-return valve and a maintained latch to a run/stop output using the same object.
The CROB also carries a count field, saying how many pulses to issue, and two timing fields giving the on-time and off-time for those pulses. A status field returns in the response so the outstation can report whether it accepted the command. The command reaches the outstation as the payload of a control function code, so the CROB and the DNP3 function code that carries it are read together in a capture.
CROB and Select-Before-Operate
A CROB rarely travels alone in critical control. It is the object inside a select-before-operate sequence: the master sends a select carrying the CROB, the outstation echoes the exact same CROB back to confirm it understood, and only a matching operate carrying the identical CROB causes the output to move. If the echoed CROB differs from what the master sent, the master aborts rather than operating the wrong point.
The alternative is a direct-operate command, which carries the CROB in a single request with no select step. Direct-operate is faster but skips the arm-and-verify safety of the two-pass sequence. Which one a point uses is a design decision the point map records, and it is one of the clearest places where control safety and speed trade off. Either way, the CROB is the object doing the actual work; select-before-operate just wraps it in a confirmation handshake.
Reading the CROB Status Byte
Every CROB response carries a status value, and it is the first thing to read when a control fails, because the outstation is telling you exactly which rule the command broke. The values are defined by the standard, so they mean the same thing across equipment. A field guide to the ones seen most often:
| Status | What the outstation is saying |
|---|---|
| Success | Command accepted and the output driven as requested |
| Timeout | The operate arrived too long after the select - the arm expired before the fire |
| No select | An operate arrived with no matching select before it - a sequence or addressing error |
| Format error | The CROB itself was malformed or inconsistent with what the point supports |
| Not supported | The control code asks for an operation this point cannot perform, such as a pulse on a latch-only point |
| Local | The point is under local control - a local/remote selector has the site, not the master, in charge |
Two of these deserve special respect. Local means a human at the site has taken authority, and the master should stop retrying, not escalate. Timeout between select and operate usually implicates link latency or the master's pacing rather than the outstation. A structured walk through these failures is in troubleshooting failed DNP3 control operations.
Pairing Commands with Feedback
A successful CROB status only proves the outstation drove its output; it does not prove the breaker moved or the valve closed. Sound control design pairs every commanded point with an independent feedback input - a position contact or status point whose DNP3 point index the master watches after operating. The master's logic then confirms the feedback changed state within an agreed window and raises a command-failure alarm when it does not.
This pairing belongs in the point map documentation: each binary output listed alongside its feedback input, the expected state change, and the confirmation window agreed for the site. When a command succeeds but the feedback never moves, the fault is downstream of the RTU - the wiring, the interposing relay, or the device itself - and making that distinction automatically is the difference between dispatching the right crew and the wrong one.
A Worked Pulse Configuration
Consider a spring-return valve that needs a momentary contact closure to travel, with the pulse duration specified by the valve controller's manufacturer. The right CROB uses the pulse-on operation with the trip/close qualifier set per the point map, a count of one, an on-time matching the manufacturer's specified duration, and an off-time that is irrelevant for a single pulse but still set sanely. The outstation energizes the output for the on-time, once, and releases it.
Now consider the classic misconfiguration: someone maps the same point with latch-on instead. The command still returns success, but the output stays energized indefinitely - which on a momentary-input device can mean a stalled actuator, an overheated coil, or a control that works once and never again until someone notices the held output. The reverse error, pulsing a point that needs a maintained latch, produces equipment that starts and immediately stops. Both failures return clean statuses, which is exactly why the operation type, count, and times belong in the reviewed point map and not in anyone's memory.
Frequently Asked Questions
What object group is a DNP3 CROB?
The control relay output block is object group 12. A master sends it to command a binary output point on an outstation, whether as a direct-operate request or as part of a select-before-operate sequence.
What are the CROB trip and close codes for?
They map to control points that have two coils, such as a breaker with separate trip and close operations. The trip/close field in the CROB tells the outstation which of the two the command is driving, alongside the pulse or latch operation type.
Do count and timing fields matter for a simple relay?
For a latch operation the timing fields are unused, but the count and on/off times control pulse operations - a momentary output driven for a defined duration a defined number of times. A spring-return or momentary-contact device relies on those fields being set correctly.
Can a CROB write an analog setpoint?
No. The CROB drives binary outputs only - trip, close, latch, pulse. Analog setpoints travel as a different object, the analog output block in group 41, which carries a value rather than an operation code. The two share the same select and operate machinery but are separate objects with separate point indexes.
What does it mean when a CROB returns success but nothing happens?
The outstation drove its output as commanded, so the failure is beyond it: field wiring, an interposing relay, the device's own local permissives, or a point map that aimed the command at the wrong output. Check the paired feedback input first, then the physical output at the RTU terminals, then the map. The status byte only vouches for the RTU's side of the transaction.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
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.