Most Modbus problems fall into one of four buckets: the master gets no response at all, it gets a corrupted frame (CRC error), it gets a valid frame too late (timeout), or it gets a clean reply that says “I refuse” (an exception response). Each bucket points to a different layer of the stack, so the fastest way to fix a link is to first classify which one you are looking at, then work the cause list for that category. This guide walks through that classification and decodes every standard Modbus exception code with its likely cause and field fix.

Step One: Classify the Failure Before You Touch Anything

Before changing wiring or registers, look at what the master actually reports. The four primary symptoms map to very different root causes, and chasing the wrong one wastes hours.

A protocol analyzer or even a simple line sniff tells you which bucket you are in within seconds. On RS-485 multidrop links, the physical-layer buckets dominate, so confirm the bus is healthy before suspecting firmware.

The Modbus Exception Codes, Decoded

When a slave can parse your request but cannot honor it, the Modbus Application Protocol specification requires it to return an exception response. The function code is echoed with bit 7 set, and a single exception byte explains why. These codes are defined in the official Modbus Application Protocol spec and are identical across RTU, ASCII, and TCP. The table below lists every standard code with what it means and the most common real-world fix.

Code (hex) Name What it means Likely cause and fix
01 Illegal Function The function code is not supported by this slave. You sent, say, FC06 to a read-only input device, or a device that only supports FC03/FC04. Check the device register map and use a supported function code.
02 Illegal Data Address The starting address plus quantity falls outside the device’s valid range. Off-by-one between 1-based documentation and 0-based wire addressing, or reading past the end of a block. Subtract 1 from the documented register and verify the count.
03 Illegal Data Value A value in the request data field is out of allowed range. Quantity exceeds the per-request limit (125 registers for FC03/04, 2000 coils for FC01/02), or a written value is rejected. Split the request or clamp the value.
04 Slave Device Failure An unrecoverable error occurred while the slave processed the request. Internal hardware fault, sensor failure, or firmware fault. Power-cycle, check device diagnostics, and confirm the addressed point physically exists.
05 Acknowledge The request was accepted but needs a long time to process. Used with programming commands. The master should poll with a Read Exception Status or repeat the request rather than treat it as an error.
06 Slave Device Busy The slave is engaged in a long-duration command and cannot respond now. Back off and retry after a delay. Often seen during firmware operations or when polling a device faster than it can service.
08 Memory Parity Error A parity error was detected in the device’s extended memory during a read. Specific to FC20/FC21 file-record access. The stored record is corrupt; the device may need a memory check or reload.
0A Gateway Path Unavailable A gateway could not allocate an internal path to route the request. The gateway is misconfigured or overloaded. Check the gateway’s routing/mapping table and connection limits.
0B Gateway Target Failed to Respond No response was received from the target device behind a gateway. The downstream device is offline, has the wrong unit ID, or the serial leg failed. Verify the target slave address and the gateway’s serial settings.

Codes 0A and 0B are the ones you will meet most often in real installations, because almost every modern system bridges serial Modbus to TCP or MQTT through a gateway. A 0B in particular is a “the gateway is fine, the device behind it is not” signal, which narrows the search dramatically. Getting register access right in the first place avoids most 01, 02, and 03 errors, and our guide to Modbus register mapping and the 4x/3x/0x/1x model covers the addressing rules that trip up new integrators.

CRC Errors: It Is Almost Always the Physical Layer

A CRC error means the bytes that arrived do not match the two-byte checksum appended by the sender. In RTU mode the CRC-16 is computed over the entire frame, so a single flipped bit fails the whole message. When CRC errors are intermittent, the usual suspects are:

If CRC errors track with nearby motor starts or VFD switching, treat it as an EMC problem. Galvanic isolation breaks ground loops and clamps common-mode noise; an isolator such as the ISO-M485 RS-485 signal isolator is the standard first move on noisy plant floors. For transient and lightning energy, surge protection belongs on the line as well, and our deep dive on surge protection for RS-485 and Modbus networks explains where SURIOTA’s T485-105 SPD fits. The full wiring discipline, including grounding and termination placement, is covered in RS-485 wiring, termination, and common faults.

Timeouts and No-Response Faults: A Diagnostic Flow

When the master reports nothing back, walk this ordered checklist. Stop at the first item that resolves the fault, because later items assume earlier ones are good.

  1. Slave address. Confirm the unit ID matches the device’s configured address and is unique on the bus. Two devices on the same address collide and produce CRC noise or silence.
  2. Serial parameters. Baud rate, data bits, parity, and stop bits must match exactly. Standard baud rates are 9600 and 19200 (the spec’s required defaults), up to 115200. A parity mismatch is a classic cause of consistent CRC errors with no valid frame.
  3. Wiring polarity. A/B (sometimes labeled D+/D-) swapped is the single most common no-response cause. Swap and retest.
  4. Termination and bias. Verify 120-ohm termination at both ends and that bias is present.
  5. Response timeout tuning. Slow devices and gateways add latency. Raise the master timeout (200 to 1000 ms is typical for multidrop serial) and the inter-frame gap before declaring failure.
  6. Turnaround / DE timing. On half-duplex RS-485, the driver-enable line must release in time for the slave to reply. Late turnaround clips the response.

This same logic scales when you bridge serial to the network edge. A device like SURIOTA’s SRT-MGATE-1210 Modbus-to-MQTT gateway exposes per-slave timeout, retry, and polling-interval settings, so when you see exception 0B on the TCP/MQTT side you can isolate whether the fault is the gateway path or the serial leg behind it.

Frequently Asked Questions

What is the difference between a Modbus timeout and an exception code?

A timeout means no valid reply arrived within the master’s wait window, which points to addressing, wiring, or serial-parameter problems. An exception code means a complete, valid reply did arrive, but the slave is reporting that your request was illegal or could not be served, so the issue is in the request logic, not the physical link.

Why do I get exception code 02 (Illegal Data Address) when the register exists in the manual?

This is almost always a 1-based versus 0-based addressing mismatch. Documentation often lists register 40001, but the value placed on the wire is 0. Subtract 1 from the documented register number, and make sure your starting address plus quantity does not run past the end of the device’s defined block.

How do I stop intermittent CRC errors on a long RS-485 run?

Confirm exactly two 120-ohm terminators (one at each physical end), add fail-safe bias, keep the topology a daisy chain with short stubs, and address grounding. If errors correlate with electrical noise, add a galvanic isolator and an RS-485 surge protector at the panel entry.

What does exception code 0B mean on a Modbus TCP gateway?

Code 0B, Gateway Target Failed to Respond, means the gateway accepted your request and tried to route it, but the target serial device never answered. Check that the unit ID matches a real device, that the serial settings on the gateway match the device, and that the downstream leg is wired and powered.