Part II · Chapter 9

Exceptions and Diagnostics

Most of the time a request succeeds. This chapter is about the rest of the time: the complete list of exception codes, what each is really telling you, and the diagnostic tools that let you test a serial line and read a device's own error counters.

The exception response, once more

When a server understands a request but can't carry it out, it replies with an exception response. It takes the original function code, sets the high bit (adds 0x80), and follows it with one exception code byte naming the problem. A failed Read Holding Registers (0x03) comes back as 0x83; a failed Write Single Coil (0x05) as 0x85. No normal function code uses that high bit, so its presence is an unmistakable signal that what follows is an error report, not data.

An exception response is always this short: address, marked function code, exception code, CRC. The spec's own example, from server 17, is 11 83 02 C1 34.

The exception codes

A modest list covers everything a device can report. The first three are by far the most common day to day; the gateway codes appear only when a gateway sits in the path.

Three of these deserve a closer word.

• Illegal Data Address (02) is the beginner's constant companion. It almost always means an addressing mistake: a forgotten reference-number conversion, a count that runs past the end of a table, or the wrong table entirely.
• Illegal Data Value (03) doesn't mean "I dislike this number." It means the quantity or value broke this request's rules: 200 registers when the limit is 125, or something other than 0xFF00 / 0x0000 written to a coil.
• Acknowledge (05) and Server Device Busy (06) aren't failures at all. They're timing signals: wait and try again rather than give up.

From symptom to cause

Combine the three outcomes from Chapter 3 with these codes and you have a fast first-pass diagnosis for almost any Modbus problem:

• Normal response: the path works. Wrong-looking data is a scaling or interpretation question for the register map.
• Exception: the device is alive and listening, so look at what you asked. 01: it lacks that function. 02: fix the address. 03: fix the quantity or value.
• Silence: the device isn't hearing you, so look at the connection: wiring, unit address, serial settings, power.

This one decision is the spine of Modbus troubleshooting, and Chapter 16 fleshes it out with tools and worked cases. The point to carry forward: Modbus is unusually diagnosable. The protocol nearly always tells you which of three worlds your problem lives in, and that alone eliminates most of the guesswork.

The Diagnostics function

Beyond exceptions, serial Modbus has a dedicated Diagnostics function, code 0x08, for testing a link and reading a device's internal health counters. It's a serial-line tool: over TCP the network provides its own diagnostics, but on RS-485 it's genuinely useful. After the function code comes a two-byte sub-function that selects the test, then a two-byte data field.

The most immediately useful sub-function is the simplest. Sub-function 0x0000, Return Query Data, is a loopback test: the client sends some arbitrary data and the server must send the exact same data straight back.

If the echo matches, you've proven the full round trip: the wiring, the serial settings, the addressing, and both devices' ability to frame and check a message. That's wonderfully reassuring when you're bringing a new bus to life, because it isolates the communication path from any question about register maps or data meaning.

The diagnostic counters

A serial Modbus device quietly keeps counters about its own communication, and other Diagnostics sub-functions read them. They turn "the bus is flaky" into hard numbers. The most telling:

To read a counter, send its sub-function with a data field of 00 00; the response carries the count in that field. Reading the CRC error count from server 1, and a reply reporting 37 errors:

Read together, these counters are diagnostic gold:

• A steadily climbing communication error count points straight at electrical trouble (noise, a missing termination resistor, a marginal connection) because it counts frames that arrived with a broken CRC.
• A high exception error count points instead at a software or configuration problem: the device receives frames cleanly but refuses them.
• Comparing the bus message count with the server message count shows how much of the bus traffic is even meant for this device.

A common workflow: clear the counters with sub-function 0x000A (01 08 00 0A 00 00 C0 09), run the system for a while, then read them back to see exactly what went wrong and how often. The counters are 16 bits wide and wrap after 65,535, so read them often enough on a busy bus.

Read Exception Status

One more small serial function rounds out the toolkit: Read Exception Status, code 0x07. The request is just the address and function code; the response returns a single byte of eight device-specific status bits. What those bits mean is defined by each device (over-temperature, a calibration fault, a low battery), so you need the manual to read them.

Here the status byte 6D is 0110 1101: bits 0, 2, 3, 5 and 6 are set, and only the device manual says what each one means. The value of the function is its brevity: a quick "are you healthy?" poll that costs almost nothing, useful for keeping a light eye on a device between fuller reads. (The name is historical: these status bits have nothing to do with exception responses.)