.png)
Modbus TCP Replies Crossed? Match Transactions Before Trusting the Register Value
A valid-looking register value can belong to the wrong outstanding request. Before changing scaling or instrument wiring, establish which TCP connection, transaction identifier and request context produced the response. A packet arriving next is not automatically the answer to the last question sent.
Original conceptual illustration; not a specific product, live software screen or customer installation.
Key takeaways
Match by transaction and connection, not arrival order.
Keep the requested register context.
Test delayed and expired replies separately.
1. Separate transport delivery from application ownership
TCP delivers an ordered byte stream within a connection. That does not make every received application message the answer your polling task currently expects. A client can have multiple Modbus transactions pending, so request ownership must survive beyond the send operation.
The Modbus TCP implementation guide uses the MBAP transaction identifier to associate a response with the request previously sent on that connection. An identifier with no pending transaction is discarded. Treat this as a matching rule, rather than a measurement quality guarantee.
2. Keep the request context until completion
For an integration acceptance test, record the connection, transaction identifier, destination unit, function, requested register range and expected response shape. The pending entry also needs a timeout decision. Capture timestamps so a delayed reply can be distinguished from a new attempt.
A register response normally contains returned values rather than repeating the complete requested starting address. If application code has lost the request context, decoding the bytes correctly still cannot prove which process point they describe. Preserve the mapping alongside the pending transaction.
3. A hypothetical crossed-response test
Imagine request A reads tank level and request B reads temperature, with distinct transaction identifiers. An isolated test server delays A while B completes first. Both replies contain two data bytes, and either value could look plausible after scaling.
The acceptance result should show B updating temperature only and A updating level only. Then let A expire before its response arrives. Check that the expired response does not populate a newer point or restart an obsolete transaction. This is a proposed test, not a claim about a particular gateway.
Original explanatory diagram. Hypothetical values and proposed checks are described in the text; this is not a product specification or field result.
4. Investigate before increasing retries
Compare a sanitised packet capture with the client transaction log. Look for identifier reuse while an older request remains relevant, reconnect behaviour, unexpected unit identifiers and response lengths. Keep the gateway and downstream device model and firmware in the evidence pack.
Do not repair a matching defect by simply increasing a timeout or forcing every message into the latest polling slot. A temporary single-outstanding-request test can help isolate the fault, but its throughput and reconnect behaviour still need validation before deployment.
Record the request context and connection.
Delay one synthetic reply while another completes.
Expire a request and inspect the late response.
Verify the correct point, history and quality state.
5. Make completion observable
A completed test should identify which requests succeeded, expired or were rejected, and which stored points changed. Include read-only historical verification so an incorrect value cannot disappear behind a subsequent correct update. Use synthetic points and an approved isolated environment.
Matching a transaction does not establish register meaning, engineering units, freshness at the sensor or cybersecurity. Those require separate checks. For a ProSense integration enquiry, supply the exact register map, a redacted trace and the intended polling concurrency so the discussion starts with reproducible evidence.
Related guide and project resources
Technical references
Need help with your application?
Send the relevant point list, equipment documentation and a sanitised example of the behaviour you need to verify. Confirm the available functions and integration requirements for the exact equipment and deployment.
