What Is a DNP3 Function Code?

Back to Blog

Request Function Codes a Master Sends

Master requests fall into a few families. Data requests are dominated by read (function code 1), which a master uses to poll classes and static data. Configuration and control use write (2) for values like the clock, and the control set - select (3), operate (4), and direct operate (5) - to command outputs. The select-then-operate pair underpins the select-before-operate handshake, while direct operate does it in one pass.

Device management has its own codes: cold restart (13) and warm restart (14) reboot an outstation, which is the mechanism behind a DNP3 cold restart. Enable unsolicited (20) and disable unsolicited (21) turn spontaneous reporting on and off, and immediate freeze codes capture counter snapshots. Knowing which family a code belongs to tells you at a glance whether a frame is reading, commanding, or managing the device.

Response Function Codes an Outstation Returns

Outstations have far fewer function codes because they mostly answer. The main one is response (129), returned to any solicited request - a poll, a write acknowledgement, a control confirmation. It always carries the two-byte internal indication field so status rides along with the data.

The second is unsolicited response (130), which an outstation sends on its own initiative when configured for it, without waiting to be polled. Distinguishing 129 from 130 in a capture immediately tells you whether the outstation was answering the master or reporting spontaneously, which is central to understanding the DNP3 unsolicited response model. A confirm (function code 0) can flow in either direction to acknowledge receipt at the application layer.

The Verb Needs a Noun: Function Codes and Object Headers

A function code almost never travels alone. Most requests pair the code with one or more object headers that name what the verb acts on: an object group, a variation, and a qualifier with a range or count. Read (1) plus a class object asks for buffered events; read plus a static object group asks for present values; write (2) plus a group 50 time object sets the clock. The function code says what to do, the object header says what to do it to, and the qualifier's range selects which point indexes the request touches. Decoding in that order - verb, then noun, then range - turns a wall of hex into a sentence you can read aloud.

This pairing explains why two frames with the same function code can be doing completely different jobs. A read of class 1, 2, and 3 objects is an event poll; a read of the same outstation's counters is a totalizer collection; both carry function code 1. Responses work the same way: response (129) is just the envelope, and the object headers inside tell you whether it carries binary input events, analog values, or nothing but status. When you compare a capture against a device's documentation, check both dimensions, because a device can support a function code but not the object group you asked for, and from the master's side the failure looks identical either way.

A Poll Cycle Read at the Function-Code Level

The table below lists the codes you will meet in a routine exchange, using symbolic traffic rather than any particular implementation's defaults. Committing these to memory covers the overwhelming majority of frames in a normal capture.

Code	Name	Sent by
0	Confirm	Either end
1	Read	Master
2	Write	Master
3 / 4 / 5	Select / Operate / Direct operate	Master
129	Response	Outstation
130	Unsolicited response	Outstation

Now read a cycle with those codes in hand. The master sends read (1) for the event classes; the outstation answers with response (129) carrying its buffered events and requests a confirmation; the master returns confirm (0), and only then does the outstation clear those events from its buffer. Later a field point changes and the outstation, with unsolicited reporting enabled, sends unsolicited response (130) on its own initiative; again the master confirms. Periodically the master issues an integrity poll - still function code 1, but requesting class 0 static data along with the event classes - to guarantee its database matches the field even if a message was lost along the way. Every step of that story is legible from the function-code byte alone.

Diagnosing Rejected and Unsupported Requests

DNP3 has no dedicated error function code for requests the outstation cannot honor. Instead, the outstation replies with an ordinary response (129) and raises bits in the internal indication field: one bit for a function code it does not implement, another for an object group it does not know, another for a parameter it cannot accept. A master that ignores those bits will happily log the exchange as successful while the command quietly did nothing. So the first move when a write or control seems to vanish is to read the IIN bits in the response, not to resend the request harder.

When a request is rejected, work from documentation toward the wire. Check the outstation's device profile to confirm the function code and object group are supported at all, then confirm the implementation subset level the device claims, because DNP3 defines subset levels and a code that is optional at the device's level may simply be absent. If the paperwork says it should work, capture the exchange and compare the exact function code, group, variation, and qualifier against a known-good request to the same device. In practice the gap is almost always in the noun rather than the verb: right function code, wrong object header.

Frequently Asked Questions