Modbus TCP Values in the Wrong Tags? Check Transaction Matching
A dashboard occasionally puts a plausible value into the wrong point after a Modbus TCP polling change. The register map and scaling may be correct. Before adjusting either, check whether the client associates each response with the request that produced it. A response that is valid for one request can still be wrong for another destination tag.
This problem becomes worth investigating when polling software introduces multiple outstanding requests, retries or shared connections. Begin with evidence from an authorised test environment. Do not reproduce intermittent behaviour by flooding an operating controller or by changing process outputs.
Original ProSense engineering illustration. Equipment and plotted relationships are conceptual, not a live installation or software screenshot.
Key takeaways
Pair the connection and transaction identifier with saved request context before choosing a destination tag. Message validity and measurement freshness need separate checks.
Use the transaction identifier as the pairing key
The Modbus Organization’s TCP/IP implementation guide, V1.0b defines a two-byte Transaction Identifier in the MBAP header. The client assigns it and the server returns it. Identifiers must distinguish pending transactions on the same TCP connection; the guide permits several transactions to be active on one connection where implementation capacity allows.
The practical consequence is that the client needs enough saved context to identify the requested data and its destination when a reply arrives. Matching only the server address or assigning the next response to the oldest screen tag is inadequate when more than one request is pending. Check the driver’s supported concurrency before enabling it.
The pictured Monnit Ethernet wireless sensor gateway is a catalogue example of equipment used in Ethernet monitoring. Monnit’s Ethernet Gateway 4 interface guide describes read-only Modbus TCP access to gateway and sensor information. Confirm the supplied generation, firmware and supported client behaviour; this article does not establish a simultaneous-request capacity for that gateway.
Original workflow diagram summarising the checks in this guide. It does not establish a device specification or a customer test result.
Work through a two-request example
Hypothetical software test: a client sends request A with identifier 1201 for a temperature point, then request B with identifier 1202 for a humidity point on the same connection. Both requests remain pending. In the test harness, the reply carrying 1202 becomes available before the reply carrying 1201.
If the client uses arrival order to choose destination tags, it can place B’s data into A’s point. If it uses the returned identifier and saved request context, it routes the data for 1202 to B’s destination. The example illustrates a client validation test; it is not a report of behaviour observed on a ProSense customer installation.
Use clearly distinguishable simulated values and destinations so a swap is visible. Do not rely solely on range checks: two process values can overlap enough to pass plausibility checks. Verify the request identity, decoded value and destination tag together.
Collect a small, useful transaction trace
Record the affected client and server versions, connection configuration and exact symptom. Obtain an authorised packet capture or driver diagnostic trace containing both requests and responses. Limit the capture to the test endpoints and relevant time window, and handle it under the site’s information rules.
For each test request, record its connection, identifier, function, requested block, intended tag and send time. For the response, record the returned identifier, receive time, decoding outcome and destination actually updated. A spreadsheet with one row per request is often enough to expose an incorrect association without collecting hours of traffic.
Repeat first with one outstanding request, then with the supported concurrency used by the application. Keep the requested points and decoding rules unchanged during that comparison. If the symptom appears only with concurrency, investigate request bookkeeping and the driver’s limits before changing the physical instrument.
Keep response matching separate from response validation
Finding a matching transaction does not prove the returned data is acceptable. The implementation guide also requires checking the response header and function-specific message format. Keep protocol validation and exception handling in the diagnostic record, rather than labelling every received message as a successful measurement.
The same guide says to discard a response whose identifier does not match a pending transaction. Log such an event for investigation; do not attach it to whichever request is currently waiting. When reviewing timeouts, inspect how the driver retires old requests and manages identifiers during retry and reconnection.
An identifier is a transaction reference, not a sensor identity or a measurement timestamp. A matched response can still contain an older sensor value held by a gateway. Where freshness matters, validate the device’s documented age or timestamp information separately from the transaction match.
Avoid fixes that hide the evidence
Reducing concurrency may be an appropriate supported configuration, but document why it was chosen and repeat the application’s performance checks. Increasing a timeout without examining the trace can leave the wrong-tag problem intact. Changing engineering scaling can make one mistaken reading look reasonable while corrupting correctly matched readings.
Ask the driver or integration supplier to demonstrate matching behaviour in a controlled test. Include a deliberately delayed response and an expired transaction in that test plan where the test tools support them. Keep production controls isolated from simulated replies, and have competent personnel approve any commissioning changes.
Make the handover reproducible
Save the final driver settings, concurrency limit, timeout policy, point mapping and a short annotated trace. Record the software version and the expected treatment of unmatched responses. The acceptance result should show that each test value reached its intended destination, including after the approved reconnect test.
Send ProSense the exact gateway or instrument model, client software, a concise symptom description and the annotated request/response pair. These details help distinguish a transaction-association fault from a register-map, decoding or data-freshness issue without changing unrelated settings.
Diagnostic comparison
Observation | Next check |
Plausible value reaches wrong tag | Compare connection, transaction ID and saved destination context. |
Unmatched identifier arrives | Use documented discard handling; do not attach it to another waiting request. |
Matched value looks old | Verify freshness separately. |
Recommended equipment / related solutions
Review the instrument or gateway discussed in this article. Confirm the exact supplied model and relevant configuration before ordering.
Discuss selection and application scope with ProSense technical services.
Send the model and diagnostic evidence through ProSense Instruments technical enquiries.
Need help with your application?
ProSense Instruments - discuss instruments and gateways. ProSense Solutions - plan industrial integration. ProSight Software - explore dashboards and reporting. Compatibility with the selected device and gateway must be verified separately.
Instrument enquiries: sales@prosenseinstruments.com.au | 1800 560 854. Project enquiries: sales@prosense.com.au. Software enquiries: info@prosightsoftware.com.
Comments