Modbus TCP Timeouts: Keep Late Responses With Their Original Transactions
The Modbus TCP implementation guide uses transaction identifiers to associate requests and responses and requires distinguishable active transactions on a connection. This is different from workpiece identity. The client still owns connection lifetime, timeout handling and application-result association.
Define connection-scoped identity
Retain connection session, transaction identifier, device and application request, distinguishing wire fields from business identity. Transaction numbers can be reused. They should not become a permanently unique key across connections or restarts, nor silently replace the workpiece reference used by the application.
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.
Inspect pending-request state
Keep expected function, range and state at submission and match responses within the correct session and transaction. Do not pair by arrival order or the most recent request. Review duplicate, unknown and mismatched responses as well as a convenient sequence where everything completes in submission order.
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.
Explain timeout and reuse
Retain an explicit state after timeout and define identifier reuse and late-response handling. Ending a wait does not establish that the server did not process the request. Writes especially need confirmation through the device business contract instead of treating a missing response as proof of non-execution.
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.
Cover reconnection
In isolated validation, observe disconnection, reconnection and callbacks from earlier work. A new session must not treat residual earlier results as responses to new requests. Logs should identify the connection lifetime and application request associated with each record, including discarded late completions.
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 concurrent-request evidence
Retain joined concurrent, late-response and reconnection samples and document the device concurrency limit. An established TCP connection does not imply unlimited parallel request capacity. Accept bounded resource use and correct association together rather than treating a high submission count as the primary success measure.
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.