Does an exception mean the connection works?

It proves that a valid Modbus response returned for the request. It does not prove that the requested function, address, or downstream route is correct.

Should a client retry every exception?

No. Repeating Illegal Function or Illegal Data Address normally repeats a deterministic configuration error. Busy or Acknowledge may justify a controlled delay and retry.

Is an unknown exception code still a valid Modbus exception?

Preserve it as received and check the vendor documentation. Standard codes have defined meanings, but a device may return a non-standard value that should not be silently reinterpreted.

Modbus exception codes: a practical troubleshooting reference

Decode the response shape first

For a rejected FC03 request, the response function is 0x83. A following 0x02 means Illegal Data Address. On TCP, validate the MBAP transaction ID and length before interpreting the PDU; on RTU, validate the slave address and CRC.

Inspect the exception fields in your frame

Codes 01 through 08 describe the server

01 Illegal Function: the server does not support or permit the requested function. 02 Illegal Data Address: the address, width, or complete range is not valid. 03 Illegal Data Value: a request field or written value is not allowed. 04 Server Device Failure: the server could not complete the operation. 05 Acknowledge and 06 Server Device Busy describe delayed processing. 08 Memory Parity Error is reported for a server memory integrity failure.

Codes 0A and 0B describe a gateway route

0A Gateway Path Unavailable means the gateway could not allocate or establish the path. 0B Gateway Target Device Failed to Respond means the gateway attempted the downstream transaction but did not receive a response. Inspect the gateway's serial route, Unit ID, timing, and downstream device rather than only the client-to-gateway TCP link.

Choose the next test from the exception

For Illegal Function, test a documented function rather than changing addresses at random. For Illegal Data Address, reduce quantity and verify the start offset and address space. For Illegal Data Value, inspect request fields, encoded write values, and device constraints. For Server Device Failure, capture the exact request and inspect device diagnostics or logs before repeating it indefinitely.

Acknowledge and Server Device Busy indicate that immediate completion was not available. Follow the device's documented polling or completion mechanism and use a bounded delay. They are not permission for an unbounded retry loop.

01: verify function support and current device mode
02: verify start, quantity, width, and address space
03: verify encoded fields or written value
04: inspect server diagnostics
05/06: apply documented delay and bounded retry
0A/0B: inspect the gateway route and downstream bus

Correlate the response with the original request

On TCP, the transaction ID should identify the request that produced the exception. On RTU, only one request should own the line and the returned server address should match the target. Without this correlation, a valid-looking exception may belong to another concurrent operation or a stale gateway response.

Preserve the function, address, quantity, Unit ID, transport, attempt number, and latency. The exception byte alone loses the context needed to explain why the server rejected the operation.

Report vendor-specific behavior without rewriting the standard

Devices sometimes return a generic Server Device Failure where a more precise code would be useful, or use exceptions differently across firmware versions. Describe the observed request and response exactly, then add the vendor interpretation as a note. Do not rename the protocol code in the raw evidence.

If a request works on one firmware and fails on another, record both versions and the smallest differentiating frame. That is actionable evidence for a vendor and a safer basis for a compatibility note than a broad claim that the model does or does not support the function.