Modbus Exceptions: Diagnose Application Errors on a Working TCP Connection
Modbus exception responses contain an exception-marked function and an exception code. The protocol defines meanings including codes 01 through 04 and explicitly distinguishes code 03 from judging whether an application-level physical value is outside its expected range.
Separate exception from no response
Retain the returned function and code, distinguishing normal response, exception response, connection failure and wait timeout. An exception indicates that a server returned a protocol-level result. Reporting every such outcome as network unavailable erases the layer information needed for useful investigation.
For this review, identify the delivered device, software and configuration revisions first. Record unsupported, disabled and untested capabilities separately. Evidence from another model is useful context, but cannot establish what the delivered combination actually provides. Keep the original input beside the settings used to interpret it.
Review function and range
For 01, review whether the requested function is allowed. For 02, inspect the address-and-quantity combination. A valid first register does not establish a valid full block, so retain the whole requested range rather than only the first register label shown in an interface.
Retain the original input and the reason for the decision, rather than a successful screenshot alone. Change only the variables agreed for the comparison, and keep the before-and-after configuration. List conditions that were not exercised explicitly; they should not silently become part of the accepted operating range.
Interpret code 03 precisely
The protocol uses 03 for unacceptable request-field content such as an inconsistent structure and explicitly excludes a generic judgement about the application meaning of stored data. Do not report pressure or temperature overrange from that code alone. Inspect quantities, lengths and function-specific fields, then consult device-specific additions.
Use the three illustrated observations as starting questions, rather than as diagnoses of an installation that has not been inspected. Check record completeness, units and identity before selecting the next observation. An unresolved result is more informative than a confident explanation assembled from missing fields or unrelated test runs.
Keep device context for failures
Code 04 describes a server failure while performing the requested action; other codes have their own scope. Retain device state and original request. A code name is not a diagnosis of one failed hardware component, and indiscriminate unlimited retries are not an adequate explanation or recovery policy.
Let the site owner choose an approved isolated way to exercise relevant exceptions. Record normal operation, the exceptional condition and recovery separately. The purpose is to establish how the application recognises and explains untrustworthy input, without requiring production equipment to act on deliberately invalid results.
Deliver explainable reporting
Keep protocol code and business context visible, with request identity, function and range available in logs. Use the device contract to distinguish retry, configuration correction and maintenance review. Replay representative exceptions after mapping or client changes so that reporting remains accurate at the actual failure boundary.
Deliver the configuration, representative samples, result table and unresolved questions together. Agree who reviews subsequent changes. The receiving team should be able to select one conclusion and trace it back to its input and decision path without relying on the original author to reconstruct the missing steps.
Original documentation and further reading
Continue with related articles in this section, or use selection guides to prepare the next review. Apply the device-specific documentation and agreed operating conditions when implementing a test.