A protocol exception is an answer
Exception 01 usually points to an unsupported function. Exception 02 points to an illegal address or range. Exception 03 points to an invalid quantity or value. Keep the request and exception response together; changing serial wiring after a clean exception is usually wasted effort.
A timeout starts at the transport boundary
On RTU, verify port ownership, framing, Unit ID, wiring, bias, and termination. On TCP, verify route, port, firewall, and gateway Unit ID. Use retries only after one request is known to be correct; otherwise they merely repeat the same mistake more slowly.
CRC errors mean the line produced a bad frame
Check baud and parity first, then grounding, cable topology, termination, noise, and adapter quality. Record the raw bytes and frequency. An isolated CRC failure under heavy traffic is a different problem from every response failing in exactly the same way.
TCP does not carry the Modbus RTU CRC. If a Modbus TCP connection reports a CRC problem, inspect the gateway or encapsulation mode instead of treating it as a normal TCP integrity check.
Classify the failure before changing settings
Start with the last layer that produced trustworthy evidence. A completed TCP connection narrows the network problem but says nothing about the Modbus Unit ID. Valid RTU bytes with a bad CRC prove that the receiver saw activity, while a valid exception proves framing, addressing, and response timing were good enough for the server to parse the request. Each result justifies a different next test.
Keep transport errors separate from protocol errors in logs. Connection refused, certificate rejected, serial port busy, timeout, malformed length, bad CRC, and Modbus exception should not collapse into one red status. The distinction is what prevents a software setting from becoming an unnecessary wiring change.
- Exception: inspect function, address, quantity, and device state
- Timeout: inspect route, framing, Unit ID, and timing
- CRC failure: inspect serial settings and signal integrity
- Malformed response: preserve all bytes and transaction context
Use retries as evidence, not camouflage
A deterministic exception should not be retried automatically. Illegal Function and Illegal Data Address normally return the same result until the request changes. Timeouts and CRC failures may justify a small retry count, but record every attempt and its latency. A request that succeeds only on the third attempt is degraded communication, not a clean success.
Compare failures by source and time. If every source fails together, investigate the shared transport. If one address range fails while other requests remain healthy, inspect that range, function, or server processing path. If failures correlate with a drive start or relay operation, capture the timing and examine grounding, routing, and electromagnetic noise.
Build a reproducible failure record
For RTU, save port, baud, data bits, parity, stop bits, Unit ID, timeout, request bytes, received bytes, CRC status, adapter, and topology. For TCP or TLS, save host, port, Unit ID, connection result, certificate error where relevant, MBAP header, PDU, and timing. Add the expected behavior and the shortest sequence that reproduces the fault.
Do not send only the final formatted value. The raw frame often reveals a shifted address, wrong byte count, stale transaction ID, gateway exception, or response from another Unit ID immediately. A small evidence package turns an intermittent complaint into something firmware, controls, and support teams can inspect independently.