Modbus RTU CRC Validation: Separate Corruption From Framing Errors

Validate a Modbus RTU CRC over the complete documented frame, using the specified algorithm and CRC byte order. First establish correct frame boundaries and serial settings. A CRC failure can result from corruption, truncation, two frames joined together or a parser that selected the wrong bytes.

Treat a bad frame as untrusted data. Do not show its decoded register values merely because some bytes resemble a valid response. Preserve raw bytes and timing for diagnosis.

Verify the complete serial frame

The Modbus Serial Line specification defines RTU framing, timing and CRC handling. Its CRC field is transmitted low-order byte first. That rule is different from the encoding of register data and should have a separate implementation path.

Use a known official test vector or a manufacturer-provided trace to validate an implementation. Do not declare an arbitrary copied hexadecimal message correct without checking its origin and complete bytes.

Keep CRC and application interpretation separate

The Modbus Application Protocol specification defines normal and exception responses. An exception is a shorter valid application response and still needs correct RTU framing and CRC. A parser that always expects a normal data length can reject valid exceptions as corrupt packets.

After a frame passes CRC validation, check address, function and request context. A valid frame from another unit should not complete the current transaction. Likewise, a CRC-valid response does not prove that the chosen register map or scaling is correct.

Keep separate counters for CRC failures, timeouts, framing faults and protocol exceptions. Combining all of them into one communication-error count makes physical and configuration problems harder to distinguish.

Investigate failures by pattern

If every frame fails identically, inspect implementation details first: the included bytes, initialization, algorithm and trailing-byte order. If failures increase with cable route or node count, inspect wiring, reference, termination, loading and direction control.

If the first reply after a request is truncated, examine whether the adapter changed from transmit to receive in time. If long replies fail but short ones pass, inspect buffering and timing. Do not assume that increasing a response timeout repairs bytes that were never captured.

Capture timestamps where the adapter supports useful timing information. A text terminal that prints an entire line after buffering may not reveal the actual serial gaps.

Acceptance under the real bus conditions

Verify the parser against valid normal and exception frames, deliberately corrupted test frames and a truncated frame. Software tests should reject corruption without updating displayed data. Run such malformed-frame tests against a simulator rather than injecting arbitrary traffic into an operating installation.

Then test the real bus at its final length, node count and transaction rate. Record error categories and the duration of the observation window. Include idle-to-active transitions and individual endpoint restarts.

Save a rejected-frame sample with its expected request before clearing counters. An aggregate count cannot show whether every failure loses the first byte or corruption moves around the frame. Raw bytes and timing context help separate deterministic adapter turnaround from broader electrical trouble. They also let another engineer validate the calculation without repeating disruptive live tests. Keep the valid comparison frame from the same session so differences in addressing and payload length remain visible.

A pass means the documented operating conditions produce valid, correctly associated observations, and rejected frames remain visible in diagnostics. See Modbus RTU versus TCP for transport context. Review adapter behavior with an integration partner before treating all USB serial converters as equivalent.