Modbus Exception Codes: Full Reference Table

Back to Blog

The Exception Code Table

The table below lists each standard exception code, its name, and where the fault lies, so you can route the problem to the right layer at a glance.

Code	Name	Points at
01	Illegal function	Request: device does not support that function code
02	Illegal data address	Request: address does not exist on the device
03	Illegal data value	Request: value or quantity out of allowed range
04	Server device failure	Device: valid request, internal fault
05	Acknowledge	In progress: long command accepted, poll later
06	Server device busy	Transient: device occupied, retry later
08	Memory parity error	Device: file-record memory integrity fault
0A	Gateway path unavailable	Gateway: no path to the target configured
0B	Gateway target failed to respond	Gateway: target device did not answer

Reading the code first is what saves time. A code 02 sends you to the register map, covered in the Modbus register addressing reference, while a code 04 sends you to the device, as the Modbus exception 04 reference explains.

Grouping the Codes by Where to Look

The codes fall into natural groups. Codes 01, 02, and 03 are request-side: the device is telling you that the function, the address, or the value in your request is not acceptable, and each is fixed by correcting the request. These are the everyday exceptions an integrator meets while building a map, and the general mechanism behind them is in the Modbus exception code reference.

Codes 04 and 08 are device-side integrity faults, 05 and 06 are in-progress states that call for polling or retrying rather than changing anything, and 0A and 0B are gateway-path errors that mean the problem is between the master and a serial device behind a gateway rather than in either endpoint. A code 0B in particular often means the target serial device is dead or its unit identifier is wrong, which ties back to the Modbus unit ID and slave address reference.

How an Exception Response Is Built

The wire format is worth knowing because it is how you spot an exception in a raw capture. A normal response echoes the request's function code; an exception response echoes it with the most significant bit set - the value 0x80 added - followed by the one-byte exception code. So a read holding registers request, function 03, that fails on addressing comes back as 0x83 02: function 0x83 marks the exception, 02 names the cause. If a capture shows a function code of 0x80 or higher, subtract 0x80 to recover the original function and read the next byte as the code.

A worked symbolic case: the master asks for N registers starting at address X. If X exists on the device but X plus N minus 1 runs past the end of its map, the device answers 0x83 02, because the standard requires the whole requested range to be valid, not just its first address. One other rule completes the picture: a request that fails its CRC is silently discarded, never excepted, since the device cannot trust anything in a corrupted frame - so corruption produces timeouts, while exceptions always come from an intact, understood request the device chose to refuse.

A Diagnostic Sequence That Routes You Fast

With the table in hand, a fixed sequence turns any exception into a short investigation:

1. Decode the exception code first - it names the layer at fault before you touch anything.
2. For 01 through 03, reproduce the failure with a minimal single-point read or write, then walk that request against the vendor's register map documentation.
3. For 04 or 08, put the request aside and interrogate the device itself: local display, diagnostic registers, and a restart only under the site's procedures.
4. For 05 or 06, wait and poll again before changing anything - they describe states, not faults, and the exception code 06 reference covers sensible retry behavior.
5. For 0A or 0B, address a different unit ID behind the same gateway to separate a gateway configuration problem from a single dead serial drop.

It also pays to capture a few known-good exchanges while the system is healthy. A baseline of working frames makes the eventual bad day far shorter, because you can compare the failing request byte for byte against one the device used to accept.

Exceptions Versus Silence

An exception, even an unwelcome one, is good news of a kind: it proves the physical layer, the framing, and the device's protocol stack all work, because the device received the request intact, parsed it, and formally declined it. Silence belongs to a different family of faults - wiring, a baud or parity mismatch, a dead device, or simply the wrong unit ID, since a serial device ignores frames not addressed to it rather than objecting to them. That no-response branch of troubleshooting has its own guide under Modbus timeout and slave not responding.

Gateways blur this line deliberately. Because a gateway answers the master on behalf of downstream serial devices, raw silence from a drop is converted into an 0B exception, so behind a gateway you may never observe a true timeout at the master. That conversion only works if the gateway's own wait-for-response setting is longer than the slowest serial device's genuine response time - a value that is device- and site-specific - so a gateway that throws 0B intermittently under load is sometimes just configured too impatient rather than fronting a failing device.

Frequently Asked Questions