When a Modbus device cannot honor a request, it does not stay silent - it sends back a specific error, called an exception, that says why. Reading that exception turns a frustrating dead poll into a precise diagnosis: the function is unsupported, the address does not exist, the value is out of range, or the device itself has faulted. This guide decodes the common Modbus exception codes so a technician can tell whether the map is wrong, the register does not exist, or the field device is in trouble.
Modbus Exception Code in one line: A Modbus exception code is the error a device returns when it receives a request it cannot fulfill. The device replies with the original function code flagged as an exception and a single byte identifying the reason: 01 illegal function (the device does not support that operation), 02 illegal data address (the requested address does not exist on the device), 03 illegal data value (the value or quantity is out of the allowed range), and 04 slave device failure (the device encountered an internal fault). The code tells a technician exactly which layer of the problem to fix.
A normal Modbus response echoes the function code of the request and carries the requested data. An exception response is deliberately distinguishable from a normal one: the device sets the high bit of the function code so, for example, a request with function code 03 comes back with the exception-flagged form, and it follows that with a single exception code byte instead of data. A master that decodes responses can spot an exception immediately by that flagged function code and then read the one-byte reason.
This design means an exception is a positive answer, not a timeout. The device did receive the request, understood it well enough to reject it, and told the master why - which is fundamentally different from getting no reply at all. A no-reply usually points to a wiring, addressing, or communications problem: the request never reached a device, or reached the wrong one, or the response was lost. An exception points inward, at the request's content, because the device is present and talking and specifically declining what was asked.
Keeping that distinction clear is the first step in troubleshooting. If a poll simply times out, the technician looks at the physical layer and the addressing that routes the request to a device. If the poll returns an exception, the technician instead looks at what was asked - the function code, the address, the quantity, or the health of the device - because the exception is the device's own explanation of why the request was unacceptable. The four common exception codes each narrow that explanation to a specific cause.
Exception 01, illegal function, means the device does not support the function code that was sent. The request reached a real device that understood the frame but has no implementation for that operation - for instance, issuing a write-multiple-registers code to a device that only implements single-register writes, or sending a function the device simply does not offer. The fix is to use a function code the device supports, which its documentation or register map should list. This exception says the verb was wrong, not the address.
Exception 02, illegal data address, means the address requested does not exist on the device, or the requested range runs off the end of what the device implements. This is one of the most common exceptions during commissioning, and it usually points at either a genuine gap - the register the map promised is not actually there - or an off-by-one between the human register number and the protocol offset on the wire. Exception 03, illegal data value, is different: the address is fine, but the value or quantity in the request is out of the range the device accepts, such as asking for too many registers at once or writing a value the device rejects. Exception 03 is about the payload, not the location.
Exception 04, slave device failure, means the device tried to process the request but hit an internal problem - a hardware fault, a failed sensor behind the register, or an unrecoverable error in the device itself. Unlike 01, 02, and 03, which point at the request, exception 04 points at the device: the request was legitimate but the device could not carry it out. When a poll that worked yesterday starts returning exception 04, the field device rather than the Modbus map is the place to look, because the device is reporting that something inside it has gone wrong.
Exception codes turn troubleshooting from guesswork into a decision tree, and that is especially valuable on remote oil and gas sites where a technician may be reading the error from a control room rather than standing at the RTU. If the poll returns exception 01, the map has the wrong function code and the fix is in the SCADA configuration. If it returns 02, the address is wrong or does not exist, which sends the technician back to reconcile the vendor register list with what the master is polling. If it returns 03, the request is asking for too much or writing an invalid value, so the quantity or the written value needs adjusting. If it returns 04, the field device itself has faulted and needs attention on site.
A cloud SCADA platform makes this diagnosis remote and immediate. When Merobix polls a field device over Modbus and receives an exception, it can surface which code came back, so the person troubleshooting knows whether the problem is in the tag configuration, the register map, the request parameters, or the device hardware - without a truck roll to find out. That distinction is the difference between fixing a mapping error from a keyboard and dispatching a technician for a device that has genuinely failed.
The practical habit is to treat the exception code as the first clue rather than restarting the poll blindly. Codes 01, 02, and 03 are almost always fixable in the configuration - the wrong verb, the wrong address, or the wrong value - and a technician can resolve them by editing the map and re-polling. Code 04 is the one that usually means physical intervention, because the device is reporting its own failure. Reading the code before acting saves the wasted effort of re-checking wiring when the device is plainly answering, or of editing a map when the real problem is a faulted sensor in the field.
It means the address your request asked for does not exist on the device, or the requested range extends past the registers the device actually implements. During commissioning this most often comes from a register that is not really there or from an off-by-one between the human register number and the zero-based protocol offset on the wire. The fix is to reconcile the vendor register list with the exact offset the master is polling.
No, and the difference matters for troubleshooting. A timeout means no reply came back, which usually points to wiring, addressing, or communications - the request may never have reached a device. An exception means the device did reply, understood the request, and rejected it with a reason code, so the problem is in the content of the request or the health of the device rather than the physical link.
Exception 04, slave device failure, means the device tried to process a valid request but hit an internal fault, so the problem is the field device rather than your map. Unlike codes 01, 02, and 03, which you fix in the configuration, code 04 usually needs attention at the device - a hardware issue, a failed sensor behind the register, or an internal error. If a previously working poll starts returning 04, inspect the device itself.
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.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.