Overview
When a Modbus device cannot process a request, it returns an exception response instead of the expected data. The exception response contains an error code that identifies what went wrong — but only if you know how to read it.
Exception responses are the Modbus protocol’s only error reporting mechanism. Understanding them is essential for diagnosing addressing errors, unsupported function codes, and device-specific limitations during gateway configuration and commissioning.
This guide covers all standard exception codes, the response frame format, and practical troubleshooting for each error condition.
Exception Response Format
A normal Modbus response echoes the function code from the request. An exception response modifies the function code by setting the high bit (adding 0x80), then appends a one-byte exception code:
Modbus RTU Exception Frame
| Field | Size | Normal Response | Exception Response |
|---|---|---|---|
| Slave Address | 1 byte | 0x01 | 0x01 |
| Function Code | 1 byte | 0x03 (Read Holding Registers) | 0x83 (0x03 + 0x80) |
| Data | N bytes | Register values | Exception code (1 byte) |
| CRC | 2 bytes | CRC-16 | CRC-16 |
Modbus TCP Exception Frame
| Field | Size | Normal Response | Exception Response |
|---|---|---|---|
| MBAP Header | 7 bytes | Transaction ID + Protocol + Length + Unit ID | Same |
| Function Code | 1 byte | 0x03 | 0x83 |
| Data | N bytes | Register values | Exception code (1 byte) |
[!TIP] When viewing a Modbus packet capture, look for function codes above
0x80. If you sent FC0x03and received0x83, the device rejected the request. The byte following the function code tells you why.
Exception Codes Reference
Standard Exception Codes
| Code | Hex | Name | Description |
|---|---|---|---|
| 01 | 0x01 | Illegal Function | The function code in the request is not supported by the device |
| 02 | 0x02 | Illegal Data Address | The register or coil address in the request does not exist on the device |
| 03 | 0x03 | Illegal Data Value | The value in the request is outside the acceptable range for the target register |
| 04 | 0x04 | Server Device Failure | An unrecoverable error occurred while the device was processing the request |
| 05 | 0x05 | Acknowledge | The device accepted the request but needs extended time to process it (long-running operation) |
| 06 | 0x06 | Server Device Busy | The device is processing a long-duration command — retry the request later |
| 07 | 0x07 | Negative Acknowledge | The device cannot perform the programming function specified in the request |
| 08 | 0x08 | Memory Parity Error | The device detected a parity error in its internal memory (extended file area) |
| 0A | 0x0A | Gateway Path Unavailable | The gateway could not establish a connection to the target device |
| 0B | 0x0B | Gateway Target Device Failed to Respond | The target device behind the gateway did not respond within the expected time |
Exception Code Frequency in Integration Projects
Based on Chipkin’s support data across 437+ Modbus FSE projects:
| Code | Frequency | Typical Root Cause |
|---|---|---|
| 02 (Illegal Data Address) | ~50% of all exceptions | Off-by-one addressing error, wrong register convention |
| 01 (Illegal Function) | ~25% | Using FC03 when device only supports FC04, or vice versa |
| 0B (Gateway Target Failed) | ~10% | Slave ID wrong, device offline, wiring issue |
| 04 (Server Failure) | ~8% | Device firmware bug or internal fault |
| 03 (Illegal Data Value) | ~5% | Writing out-of-range value to setpoint register |
| Others | ~2% | Rare in field installations |
Exception Code 02: Illegal Data Address (Most Common)
This is the #1 exception code encountered in Modbus integration — responsible for roughly half of all exception responses in gateway projects.
Common Causes
| Cause | Symptom | Fix |
|---|---|---|
| Off-by-one addressing | Request for register 40001 returns exception 02 | Try register 40000 (0-based) — see Modbus Addressing & Register Reference |
| Wrong register convention | All registers return exception 02 | Verify whether the device uses Modicon (1-based) or PDU (0-based) addressing |
| Register doesn’t exist | Some registers work, specific ones fail | Check the device register map for valid address ranges |
| Register count too large | Reads of 1–10 registers work, larger reads fail | Reduce the register count per request (max 125 for FC03/FC04) |
| Wrong function code for address range | FC03 for addresses that require FC04 | Some devices split data across holding registers (FC03) and input registers (FC04) |
[!WARNING] The addressing convention (0-based vs 1-based) varies by device manufacturer. A register listed as
40001in the documentation might be address0in the PDU (0-based) or address1(1-based). Always verify with a single known register before building the full point map. See How to Read a Modbus Register Map for step-by-step guidance.
Diagnostic Steps
- Test a single known register — pick one register from the manufacturer documentation that you know exists
- Try both address conventions — if register
40001fails, try addresses0and1 - Verify the function code — try FC03 (holding registers) and FC04 (input registers)
- Reduce register count to 1 — eliminate count-related failures
- Check slave ID — some devices respond to the wrong address with exception 02 instead of silence
Exception Code 01: Illegal Function
The device does not recognize or support the requested function code.
Common Causes
| Cause | Symptom | Fix |
|---|---|---|
| Device only supports read | Write commands (FC05, FC06, FC16) return exception 01 | Verify the device’s supported function codes — some devices are read-only |
| FC03 vs FC04 confusion | FC03 returns exception 01 but FC04 works (or vice versa) | Check which function codes the device supports for each register range |
| Advanced function code | FC23 (Read/Write Multiple) returns exception 01 | Not all devices support advanced function codes — fall back to FC03 + FC16 |
| Diagnostic function code | FC08 returns exception 01 | Diagnostic function codes are optional and rarely supported on field devices |
[!TIP] When encountering exception 01, request the device’s supported function code list from the manufacturer. Most Modbus devices support only FC01–FC06 and FC15–FC16. Advanced codes (FC08, FC17, FC20–FC24, FC43) are uncommon in building automation equipment.
Exception Codes 0A and 0B: Gateway Errors
These codes are specific to gateway devices — they indicate a problem between the gateway and the downstream target device, not a problem with the Modbus request itself.
| Code | Meaning | Root Cause | Fix |
|---|---|---|---|
| 0A (Path Unavailable) | Gateway cannot route to the target | Wrong slave ID, target network unreachable, routing table misconfigured | Verify slave ID and gateway routing configuration |
| 0B (Target Failed to Respond) | Gateway reached the target but got no response | Device offline, wrong baud rate, wiring fault, device not at expected address | Check serial connection to downstream device, verify baud rate and wiring |
[!NOTE] Exception 0B through a Modbus TCP gateway often means the gateway successfully received your TCP request but the serial-side Modbus RTU device is not responding. Troubleshoot the serial connection, not the Ethernet connection. See the Modbus Troubleshooting Guide for serial diagnostic procedures.
Exception Codes 05 and 06: Timing-Related
| Code | Meaning | Action |
|---|---|---|
| 05 (Acknowledge) | Device accepted the request but is still processing | Wait and poll again — the device will respond when complete. Do not resend the request. |
| 06 (Server Busy) | Device is busy with a previous operation | Retry after a delay (typically 1–5 seconds). If persistent, the device may be overloaded with requests. |
These exceptions are uncommon in normal read operations. They typically occur during:
- Firmware updates via Modbus file transfer
- Configuration writes to non-volatile memory
- Calibration operations that require hardware settling time
[!TIP] If you receive persistent exception 06 responses, reduce the polling rate. Some slower devices (older PLCs, embedded controllers) cannot handle rapid sequential requests — add a 50–100ms inter-request delay in the gateway configuration.
No Response (Silence) vs Exception Response
The most confusing diagnostic scenario: the device returns nothing at all.
| Behavior | Meaning | Common Cause |
|---|---|---|
| Exception response | Device heard the request, understood the framing, but rejected the content | Addressing error, unsupported function code |
| No response (timeout) | Device either didn’t hear the request or doesn’t exist at that address | Wrong slave ID, baud rate mismatch, wiring fault, device powered off |
| Broadcast (address 0) | Request sent to all devices — no response expected by protocol | Normal behavior for broadcast writes |
[!CAUTION] No response is worse than an exception response. An exception at least confirms the device is on the network and responding. Complete silence means you need to verify the physical layer first — see the Modbus RTU Pre-Commissioning Checklist for serial verification steps.
Capturing Exception Responses
Modbus RTU (Serial)
Use the CAS Modbus Scanner or any Modbus diagnostic tool to send test requests and observe responses. Exception responses appear as error codes in the tool’s response pane.
Modbus TCP (Ethernet)
Use Wireshark with the mbtcp display filter:
mbtcp.modbus.func_code >= 0x80This filter shows only exception responses, making it easy to identify which requests are failing.
For specific exception codes:
mbtcp.modbus.exception_code == 2This filters for Illegal Data Address (02) exceptions only.
Related Articles
- Modbus Addressing & Register Reference — addressing conventions that cause exception 02
- How to Read a Modbus Register Map — interpreting manufacturer documentation correctly
- Modbus Troubleshooting Guide — broader symptom-based diagnostics
- Modbus RTU Pre-Commissioning Checklist — verify physical layer before debugging exceptions
- Modbus Data Types & Byte Order Reference — 32-bit value handling
Chipkin Tools
- CAS Modbus Scanner — Send test requests and view exception responses in real time
- QuickServer — Protocol conversion gateway with Modbus exception logging
- QuickServer — Multi-protocol gateway with built-in Modbus diagnostics
- Chipkin Support — Exception code diagnosis and register map analysis