Modbus Exception Codes Explained — What They Mean & How to Fix

How Exception Responses Work

When a Modbus slave can't process a request, it doesn't just stay silent — it sends back a specific exception response so the master knows exactly what went wrong. The structure is always the same: the function code byte with its high bit set (function code OR 0x80), followed by a single exception code byte.

Exception response structure:
Byte 0: Function Code | 0x80
Byte 1: Exception Code

Example — a FC03 (0x03) request that fails:
83 02   → FC03 exception, code 0x02 (Illegal Data Address)

This matters because 0x83 is easy to misread as garbage data if you're not expecting it. If the first byte of a response has its top bit set, you're looking at an exception, not a normal read/write result — check the second byte before doing anything else.

0x01 — Illegal Function

The slave doesn't implement the function code you sent at all. This is a capability mismatch, not a data problem.

Request — FC04 (Read Input Registers) to a device that only supports FC03:
04 00 00 00 02

Response:
84 01   → FC04 exception, code 0x01 (Illegal Function)

Fix: Check the device's Modbus register map documentation for which function codes it actually supports. Many low-cost sensors and energy meters only implement FC03 (Read Holding Registers) and FC06/FC16 (write), and map every value — including analog inputs — as holding registers rather than using FC04.

0x02 — Illegal Data Address

This is the exception you'll see most often. The starting address plus the quantity requested falls outside the range of registers, coils, or inputs the device actually has.

Request — read 10 holding registers starting at address 200 on a device
that only has 100 registers defined:
03 00 C8 00 0A

Response:
83 02   → FC03 exception, code 0x02 (Illegal Data Address)

Fix: This is almost always one of two things. First, an off-by-one error — Modbus documentation numbers registers starting at 1 (e.g. 40001), but the address on the wire is 0-based (PDU address 0). Second, requesting more registers than the device implements in one call — always cross-check against the device's published register map before assuming your master code is broken.

0x03 — Illegal Data Value

The address is valid, but the value in the request's data field isn't something the device will accept.

Request — FC05 (Write Single Coil) with an invalid value (only 0xFF00
and 0x0000 are legal):
05 00 10 12 34

Response:
85 03   → FC05 exception, code 0x03 (Illegal Data Value)

Fix: For FC05, only send exactly 0xFF00 (ON) or 0x0000 (OFF) — anything else triggers 0x03. For FC03/FC16, requesting a quantity above the protocol limit (125 registers for reads, 123 for writes) also returns this code, even if the starting address is valid.

0x04 — Slave Device Failure

The request was well-formed and the address was valid, but the slave hit an internal error trying to actually execute it — a hardware fault, a sensor out of its calibrated range, or a firmware bug.

Fix: This isn't something your master application can fix by retrying the same request. Check the physical device — power cycle it, check sensor wiring, or check the manufacturer's error log if the device exposes one. Persistent 0x04 responses on the same register usually point to a hardware issue, not a protocol issue.

0x05 & 0x06 — Acknowledge / Slave Busy

These two are related: the slave accepted the request but can't complete it immediately.

• 0x05 (Acknowledge) — the slave has accepted a long-duration command and is processing it in the background. It's telling the master "I got it, give me time."
• 0x06 (Slave Device Busy) — the slave is currently executing a long-duration program (firmware update, calibration, file transfer) and cannot accept the new request at all right now.

Fix: Both codes mean "retry later," not "this request is wrong." Implement a retry with a short backoff (typically 1-5 seconds) rather than treating either as a hard error or logging it as a fault.

0x0A & 0x0B — Gateway Exceptions

These only appear when you're going through a Modbus gateway (e.g. a TCP-to-RTU bridge) rather than talking to a device directly.

• 0x0A (Gateway Path Unavailable) — the gateway itself is misconfigured or overloaded and can't route the request onward.
• 0x0B (Gateway Target Device Failed to Respond) — the gateway forwarded the request fine, but the actual end device on the serial line never responded (different from the gateway itself failing).

Fix: 0x0A means check the gateway's own configuration and network connectivity. 0x0B means the problem is downstream of the gateway — check the RTU wiring, baud rate, and unit ID of the target device on the serial segment.

Quick Reference Table

Testing Exception Handling Without Hardware

Most integration bugs around exception handling only surface when something unexpected happens on a live system — which is exactly the wrong time to discover your master application crashes on a 0x02 response instead of logging it and retrying gracefully.

With ModbusSimulator, you can:

• Configure exactly which registers, coils, and inputs exist, then deliberately request outside that range to trigger 0x02 on demand
• Send values that violate FC05/FC06/FC16 constraints to trigger 0x03 and confirm your master rejects or retries correctly
• Verify your polling logic doesn't crash, hang, or misinterpret an 0x8X byte as valid register data
• Test both Modbus TCP and Modbus RTU exception behavior with the same simulator, without needing separate hardware for each

This matters because exception handling is exactly the kind of code path that rarely gets exercised in normal testing but shows up the moment a sensor goes offline or a register map changes in the field.

For the full function code reference these exceptions map to, see Modbus Function Codes Explained. If you're chasing a specific symptom like a device that never responds at all, see Modbus Slave Not Responding — Checklist or the broader Modbus Troubleshooting: Common Errors and Fixes guide.

Frequently Asked Questions