.png)
Modbus Exception 02? Check the Requested Address Range Before Retrying
A Modbus read returns an exception while a connection indicator remains green. Increasing a timeout is unlikely to explain a repeatable rejection of the same address range. First distinguish a valid exception response from silence, then check the requested function, starting address and quantity against the exact device register map.
Original conceptual illustration; not a specific product, live software screen or customer installation.
Key takeaways
A valid exception response is different from a timeout.
An address range includes its starting offset and full requested quantity.
Keep diagnostic reads controlled and preserve the complete request and reply.
1. Identify the response before changing settings
The Modbus application protocol identifies an exception by setting the most significant bit of the requested function code. For a holding-register read using function 03 hexadecimal, the exception function is 83 hexadecimal. The accompanying exception code provides the diagnostic category.
This article concerns documented read requests. It does not authorise writes, resets or configuration changes to plant equipment. Obtain captures through approved diagnostics or an isolated arrangement; adding an uncontrolled polling client can introduce a second fault.
Record the endpoint identity and request context as well as the bytes. A correctly formed exception from the wrong mapped device does not establish that the intended asset rejected the read. Preserve the register-map revision, device model and firmware for the investigation.
2. Interpret exception 02 as a range question
The protocol defines exception 02 as an illegal data address, including an invalid combination of starting reference and transfer length. Check the whole requested block. A valid first address does not make every subsequent address in that block available.
Do not confuse a register label in a manual with the protocol offset expected by the client. Establish the documented notation at both ends. Check whether the chosen function accesses the intended data area, rather than assuming all numerical register labels belong to holding registers.
An integration tool may aggregate nearby points into one read. Review the actual transmitted quantity and any undocumented gaps crossed by that optimisation. Keep a smaller documented test read available so that block formation can be examined separately from value decoding.
3. A hypothetical boundary failure
Imagine a test instrument whose approved map exposes holding-register offsets 200 through 209 inclusive. A request starting at 208 for two registers stays within that region. A request starting at 208 for three includes 210, which is outside the stated map.
If the second request receives exception 02, compare the request with that boundary before changing the network timeout. The first request is address-valid under the invented map, but its interpretation still depends on the specified data type and word order.
If a value occupies two registers, do not read half of it as a shortcut and treat the result as a complete measurement. Choose a documented complete value inside the valid region for the controlled test. These offsets are illustrative and must not be copied into real equipment.
Original explanatory diagram. Examples are hypothetical; verify the actual equipment, interface contract and project requirements.
4. Keep other exception categories separate
Exception 01 concerns an unsupported or currently disallowed function. Exception 03 concerns an invalid request data value or structure; it is not a general statement that the measured engineering value exceeded a plant alarm limit. Use the exact protocol and equipment documentation for the received code.
A timeout means that a suitable matching reply was not received within the defined wait. It does not reveal the same evidence as an explicit rejection. Keep character errors, message integrity failures, exceptions and silent non-response as separate commissioning observations.
Do not automatically retry a deterministic invalid range at a high rate. Agree how the client should flag the affected point and notify the responsible integrator without creating unnecessary traffic. Recovery behaviour and rate limits must be validated for the actual system.
Capture one approved read and its matching exception response.
Resolve function, address convention, starting offset and quantity.
Compare every requested address with the exact map.
Retest the deployed configuration and verify data quality and interpretation.
5. Close the loop with a reproducible read
Retest one documented read after one justified change. Preserve both request forms, replies and timestamps. If the corrected block succeeds, compare the decoded result with an independent expected value before approving the measurement mapping.
Confirm that the production poll configuration uses the corrected grouping and that the affected data quality recovers as intended. A successful diagnostic tool read does not prove the deployed client was updated. Retain the unsuccessful evidence so the boundary error remains explainable.
Provide ProSense Solutions with the exact model, firmware, register-map page, client address convention, transmitted request and exception response. Remove sensitive network details. That package supports a focused integration review without guessing from a connection light or a screenshot of an empty chart.
Related guide and project resources
Need help with your application?
Send the relevant equipment documentation, field definitions and a sanitised example of the behaviour you need to verify. Confirm the available functions and integration requirements for the exact equipment and deployment.
