What Are HART Response Codes?
When a HART write is rejected or a read comes back empty, the device almost always told you why in its response code, and learning to read that code turns a mysterious failure into a specific one. This page explains how HART response codes work, the difference between a communication error and a command-specific rejection, and the codes you meet most when a configuration change will not take. It is for technicians and integrators debugging HART exchanges rather than guessing at them.
HART Response Code in one line: HART response codes are the first status byte a device returns, telling a host whether its command succeeded, hit a communication error, or was rejected for a command-specific reason. A cleared code means success; a communication-error code means the transaction itself failed; and command-specific codes explain refusals like a value out of range, the device busy, or the command not implemented. Reading the code turns a vague failure into a specific one.
Communication Errors Versus Command Responses
The response code lives in the first status byte of a device's reply, and it splits into two fundamentally different kinds of feedback depending on one bit. If the communication-error bit is set, the device is telling you the transaction itself failed - a parity error, a framing error, an overrun, or a checksum mismatch - and the rest of the reply is not meaningful. This is a physical-layer or link-layer problem, and it points at wiring, noise, or signal quality rather than anything about the command's content.
If the communication-error bit is clear, the remaining bits carry a command-specific response code, and now the number means something about the command you sent. A cleared value here is success: the device understood and executed the command. A nonzero value is the device's structured explanation of why it did not simply do what you asked, and the meaning of that number is defined per command, so the same numeric code can mean different things for different commands. This is the layer where a rejected write tells you its reason.
Distinguishing these two cases is the first move in any HART debugging. A communication error and a command rejection call for completely different responses: the first sends you to check wiring, loop resistance, and signal integrity, exactly the territory the HART FSK physical layer page covers, while the second sends you to look at the command and the device's current state. Confusing the two wastes time chasing a wiring fault that is really a rejected value, or vice versa.
The Command-Specific Codes You Actually Meet
A handful of command-specific responses account for most of the rejections you see in practice. A too-high or too-low code means the value you tried to write is outside the device's acceptable range - trying to set a range span the sensor cannot support, for instance. A device-busy response means the device cannot service the command right now, often because it is executing a longer operation, and the host should retry shortly rather than treat it as a hard failure. These are the everyday reasons a configuration change is refused.
Two more are worth recognizing on sight. A command-not-implemented response means this device simply does not support the command you sent, which is common when a host tries a common-practice or device-specific command the device never implemented - a reminder that only universal commands are guaranteed. An in-write-protect-mode response means the device is refusing changes because it has been locked, so no amount of retrying will help until the write protection is cleared. Reading these codes tells you whether to retry, to stop, or to change what you are asking.
For anyone building an integration, honoring response codes is what separates a driver that fails gracefully from one that fails mysteriously. A host that treats a device-busy the same as a hard error will abandon a device that only needed a moment; a host that ignores a command-not-implemented will keep trying something that can never work. The related page on reading HART variables with a modem shows where these codes surface in practice, and the device-status page covers the separate second status byte that reports device health rather than command results.
Frequently Asked Questions
How do I tell a HART communication error from a command rejection?
Check the communication-error bit in the first status byte. If it is set, the transaction itself failed - a parity, framing, overrun, or checksum problem - and you should look at wiring, noise, and signal quality. If it is clear, the remaining bits carry a command-specific response code, so a nonzero value there is the device explaining why it rejected the command's content rather than a wiring fault.
Why was my HART configuration write rejected?
The response code usually says. A too-high or too-low code means the value is outside the device's acceptable range; a device-busy code means it cannot service the command right now and you should retry; a write-protect code means the device is locked against changes; and a command-not-implemented code means the device does not support that command at all. Reading the code turns a vague refusal into a specific reason.
What does a HART device-busy response mean?
It means the device cannot service your command at this moment, often because it is executing a longer internal operation. It is not a hard failure - the correct host behavior is to wait briefly and retry rather than abandon the exchange. A host that treats device-busy the same as a fatal error will give up on a device that only needed a moment to become ready.
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.