HART Commands: Universal, Common-Practice, and Device-Specific

What are HART commands?

HART commands are numbered requests a master device sends to a HART field instrument, and the instrument replies with data plus a two-byte response code. HART (Highway Addressable Remote Transducer) is a master-slave digital protocol, maintained as an open standard by the FieldComm Group, that rides on top of the same two wires carrying a 4-20 mA analog signal. The master (a handheld communicator, a control system, or an asset-management tool) asks; the slave (the transmitter or valve positioner) answers. Every exchange is keyed by a command number, so "read the primary variable" is a different number from "write the upper range value."

Commands fall into three classes by who defines them and who must support them: Universal (mandatory on every HART device), Common-Practice (widely implemented but optional), and Device-Specific (defined by the manufacturer for one device type). That tiering is the reason a single vendor-neutral communicator can work any HART instrument on the plant without per-vendor software.

How a HART command exchange works

A HART transaction is a request frame from the master and a response frame from the slave, and the response always carries a two-byte status field that tells you whether the command succeeded and how the device is feeling. The request frame names the device (by polling address or unique identifier), the command number, and any data the command needs (for example, the new range value you want to write). The device parses it, acts, and replies.

Those two status bytes are the part technicians often overlook. The first byte is communication / command response status (was the frame received cleanly, is the command supported, were the data values in range). The second byte is field device status (is the device malfunctioning, is a variable out of limits, has the configuration changed, is the loop current saturated or fixed). Reading those bytes is how a master knows the difference between "write accepted" and "write rejected because the device is write-protected."

Request frame: Address, command number, byte count, and any command-specific data, sent by the master.
Response frame: The same command number echoed, the two status bytes, and the requested data, sent by the device.
Response / status bytes: Two bytes that report communication health and field-device condition on every single reply.

The three classes of HART commands

HART defines three command classes: Universal commands that every device must implement, Common-Practice commands that most devices implement the same way, and Device-Specific commands unique to a manufacturer's model. The split is deliberate: it guarantees a baseline any tool can rely on, standardizes the most common field tasks, and still leaves room for vendors to expose features nothing else has.

Universal commands (every HART device must support)

Universal commands are the mandatory baseline implemented by every HART device regardless of manufacturer or type, and they are how any master identifies and reads any instrument cold. Because they are guaranteed present, a communicator can connect to a device it has never seen and immediately learn what it is and what it is measuring.

HART command 0 (Read unique identifier): returns the device's identity (manufacturer code, device type, and unique ID) plus protocol revision. This is the first command sent on connect and the anchor for a device profile. Command 0 is what makes HART "addressable."
Command 1 (Read primary variable): returns the PV and its engineering units, the core measurement (pressure, level, temperature, flow).
Command 2 (Read loop current and percent of range): returns the device's reported 4-20 mA value and percent of range.
Command 3 (Read dynamic variables): returns the loop current plus up to four dynamic variables (PV, SV, TV, QV) in one exchange.
Command 13 (Read tag, descriptor, date): returns the device's tag, descriptor, and date, the human-readable labels that populate an overview header.

One important nuance: command 2 returns the milliamp value the device thinks it is putting out, not a measurement of the actual loop current. Confirming the real current takes an independent measurement, which is a recurring theme in calibration work.

Common-Practice commands (widely implemented, optional)

Common-Practice commands are optional commands defined by the standard so that frequent tasks behave the same way across vendors, even though no single device has to implement all of them. When a device does support one, it works to the published definition, which is why a generic communicator can offer range, trim, and loop-test workflows without vendor code.

Range and span: writing the lower and upper range values (LRV/URV), and the "set range from applied PV" method that captures the 4 mA and 20 mA points live from the process.
Trims: PV zero trim and digital-to-analog (DAC) output trims that align the device's output to a known reference. DAC trims require a certified external milliamp measurement to be meaningful.
Loop test: commanding a fixed output current (for example 4, 12, or 20 mA) to verify wiring and the receiving system, then releasing back to live tracking.
Damping and transfer function: writing the damping time constant and the linear or square-root characteristic.
Additional device status: reading extended diagnostic and status detail beyond the two standard status bytes.

Device-Specific commands (vendor-defined)

Device-Specific commands are defined by the manufacturer for a particular device model and exposed to tools through that device's descriptor. They cover features the standard never anticipated: a radar level transmitter's echo curve, a Coriolis meter's drive gain, a temperature transmitter's sensor-matching coefficients. Their command numbers and data layouts are not interchangeable between vendors or even between models from the same vendor.

Historically, the way a master learned these commands was the Device Description (DD), defined in the Electronic Device Description Language (EDDL): a vendor-supplied file that tells the tool which numbers exist, what data they carry, and how to render them. A communicator without the right DD could still do everything Universal and Common-Practice, but the vendor's special features stayed dark until the descriptor was loaded.

A short HART command list

A few of the most recognized HART commands, by number, name, and class. This is a reference sample, not the full HART command list, which runs to hundreds of entries across the three classes.

Number	Name	Class
0	Read unique identifier (device identity)	Universal
1	Read primary variable	Universal
2	Read loop current and percent of range	Universal
3	Read dynamic variables (PV/SV/TV/QV)	Universal
13	Read tag, descriptor, date	Universal
35	Write range values (LRV/URV)	Common-Practice
40	Enter / exit fixed current mode (loop test)	Common-Practice
48	Read additional device status	Common-Practice
Vendor	Echo curve, sensor matching, drive gain, etc.	Device-Specific

Why this tiering lets a universal communicator work

The three-class structure is exactly what allows one tool to work any HART instrument without per-vendor software, because the Universal and Common-Practice tiers are guaranteed to behave the same everywhere. A communicator can connect, send command 0 to learn the device's identity, read its measurement with command 1 or 3, read its labels with command 13, and then offer ranging, trimming, and loop testing through Common-Practice commands, all without knowing the manufacturer in advance.

Device-Specific features are the only part that historically required vendor-supplied descriptors. So the practical truth is: the overwhelming majority of day-to-day instrument work (identify, read, configure, range, calibrate, loop test) lives in the two standardized tiers. A well-built universal communicator covers that work for every device on the bus and only needs vendor descriptors to reach the long tail of proprietary features.

How OmniBus uses universal and common-practice HART

OmniBus speaks universal and common-practice HART so the screen shows instrument behavior, not raw command numbers or byte payloads. OmniBus is a universal, vendor-neutral handheld HART communicator, calibration recorder, and field node from PragOptics (Fortiview Holdings). Rather than locking to one manufacturer's descriptors, it works from the standardized command tiers and presents tasks the way a technician thinks about them: "range it, trim it, verify it, prove it."

That choice is what makes it manufacturer-independent. The brochure puts it plainly: OmniBus communicates with HART field instruments regardless of manufacturer, with no per-vendor handheld and no descriptor licensing, and organizes commands by device family (Temperature, Level, Pressure, PID Control) so the screen only shows what the connected instrument can actually do. Under the hood, a single command logic layer drives what the operator sees, what the backend executes, and what the historian records, so behavior stays consistent across every device class.

It also handles the command 2 caveat head-on. Because a HART device's reported milliamp value is only what the device thinks it is putting out, OmniBus measures the real loop current with its own onboard milliamp circuit and writes that trusted value into the As-Found / As-Left calibration record, rather than trusting the device's self-report. And on the network side, its multi-modal HART-IP engine auto-detects whether it is connected to a wireless gateway host or a single instrument and adapts the screen accordingly, while keeping the same command vocabulary underneath.

OmniBus speaks standard, universal HART on the wire, with no proprietary protocol games. The innovation is above the wire: in visualization, in orchestration, and in the audit trail.