.png)
Modbus TCP Reads Arrive in Pieces: Test Message Assembly Before Adding Delays
A gateway reads a device reliably on the bench, then intermittently rejects replies after deployment. One possible cause is a client that treats each socket receive result as a complete Modbus message. Changing a delay can alter how bytes happen to arrive and hide the fault without correcting the parser.
Original conceptual illustration; not a live software screen, specific product or customer installation.
Key takeaways
A receive operation is not a Modbus message boundary.
Use the declared length and retain incomplete or surplus bytes.
Test split, combined and interrupted responses in an isolated environment.
1. Separate transport delivery from protocol messages
The Modbus TCP implementation guide provides explicit message-length information in the MBAP header so a receiver can identify boundaries even when transmission splits a message. An application must work with the ordered byte stream it receives, rather than rely on a particular packet or receive-call arrangement.
When selecting a gateway, include message-assembly evidence in the integration brief. The BG200 industrial IIoT gateway listing is a starting point for a Modbus TCP project; confirm its exact firmware, connected-device requirements and supported diagnostic access. This guide does not claim a fault in that product.
2. Write the receive-state requirements
Record the connection, intended endpoint, function and expected reply shape. Establish how the selected client accumulates bytes, validates a header and decides that the complete declared message is available. Use a supported library and its documented limits rather than an improvised parser.
The seven-byte MBAP header includes a length field that counts the bytes following that field, including the Unit Identifier. Consequently, total ADU length is six plus the declared length. Do not add seven to that field and accidentally consume a byte from the next message.
After extracting one complete message, retain remaining bytes for the following message. If the current message is incomplete, retain its bytes until completion or an explicitly handled failure. Define bounded storage, acceptable lengths and behaviour on connection closure.
3. Build a controlled fragmentation test
Suppose a hypothetical, valid reply contains twelve bytes. Deliver its first five bytes and then the remaining seven through an approved test endpoint. The expected outcome is one correctly decoded reply after the complete twelve bytes have arrived, with no premature measurement produced.
Next deliver two complete replies together. The expected outcome is two independently validated messages, each associated with its original request. Also split the stream at every possible boundary in a small fixture. These are synthetic software tests, not instructions to disturb an operating control network.
Include a truncated message followed by connection closure. The client must not complete the missing portion using bytes from an unrelated later connection. Record the failed transaction and the approved recovery behaviour so that stale measurements cannot appear as fresh successes.
Original explanatory infographic. Values and test cases are hypothetical; equipment selection and implementation require project-specific verification.
Diagnostic comparison
Observation | First check |
Fails only on short receives | Retained bytes and complete-length condition |
Loses every second reply | Surplus bytes after the first message |
Reply assembled; value still wrong | Transaction match and register decoding |
4. Diagnose before adjusting retries
Capture the raw stream, receive-operation boundaries, declared lengths and parser decisions in an isolated test. A packet capture and an application log describe different boundaries; neither alone proves how the client buffered the data.
Keep message assembly distinct from transaction matching. A fully assembled reply can still belong to a different request. Verify transaction identity, function, unit routing and returned quantity before accepting its values. Do not loosen those checks to make intermittent errors disappear.
Avoid using a fixed sleep as a framing rule, discarding extra bytes after the first reply, or assuming a successful TCP connection validates a measurement. Increasing every timeout can conceal a parser defect while making genuine failures slower to detect.
Document the expected ADU and length interpretation.
Exercise every split boundary in a small fixture.
Test two replies delivered together.
Test truncation, closure and independent transaction matching.
5. Turn the findings into handover evidence
Retain the client and gateway versions, fixture bytes, split positions, expected outcomes and actual results. Repeat the fixture after a library or firmware change that affects communications. Include malformed-length cases under the library’s documented failure policy.
The acceptance record should show one result per intended response, no result for an incomplete reply and no unexplained loss of surplus bytes. Verify that error counters and operational quality reflect failures rather than quietly substituting the last good value.
For a ProSense Solutions enquiry, provide a sanitised capture, register-map revision and network architecture. Ask for a scoped integration assessment that includes framing and transaction tests. Keep physical network work and application-specific validation with competent personnel under site procedures.
Recommended equipment / related solutions
For a Modbus integration enquiry, assess the BG200 industrial IIoT gateway. Its catalogue lists Modbus TCP and RTU support; confirm the exact firmware, device map and required acceptance tests.
For a broader remote-asset monitoring scope, review the ProSense RTU Monitoring Kit. Confirm the supplied interfaces and whether a kit is appropriate; it is not a substitute for checking the connected device or an authorisation for control writes.
Related practical guide: Modbus TCP Replies Crossed? Match Transactions Before Trusting the Register Value
Frequently asked question
Will a longer socket timeout fix framing?
It may change when an error appears. It does not establish correct message assembly; validate the receive-state logic and its failure policy.
Technical references
Need help with your application?
Send the equipment models, current documentation and a sanitised test example. Discuss this integration and equipment requirement with ProSense; confirm the actual functions, interfaces and acceptance scope before purchase or deployment.
