Modbus RTU CRC errors when request and response are read “glued together” on /dev/ttyS0

[akiracc]

Body:

Hi,

I’m using the EPICS modbus module over RS‑485 (Modbus RTU) on Linux (/dev/ttyS0) and I’m seeing systematic CRC error messages after adding a new device to the bus.

At the protocol level, the individual Modbus frames on the wire look correct. The problem seems to be that my IOC sometimes reads both the request and the slave response in a single serial read, and the current receive logic appears to treat that whole chunk as one frame when checking the CRC. That leads to repeated CRC error messages even though the request and response, taken separately, each have a valid CRC.

Environment

• EPICS base: (please fill in)
• modbus module version: (please fill in)
• OS: Linux (serial port /dev/ttyS0)
• Link: RS‑485, 2‑wire, 9600 baud
• Cable length: ~1–2 m, mixed star + daisy‑chain wiring
• No physical termination resistors currently installed on the bus
• Multiple Modbus RTU slaves on the same line

Observed behavior
After adding a new Modbus device on the RS‑485 bus, the IOC log shows repeated CRC errors, even when I later remove that new device and restore the wiring to the previous configuration.

Here is an excerpt from the IOC log (timestamps and direction shown by my logging):

========================================================================================

\x04\x03 \x02\x00\x02n^
2026/05/08 14:53:20.027 /dev/ttyS0 read 8
\x04\x03 \x02\x00\x02n^
2026/05/08 14:53:20.052 /dev/ttyS0 read 9
\x04\x03\x04\x00,\xfb\x84-\xa9
2026/05/08 14:53:20.052 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.053 /dev/ttyS0 write 8
\x04\x03 \x04\x00\x02\x8e_
2026/05/08 14:53:20.066 /dev/ttyS0 read 8
\x04\x03 \x04\x00\x02\x8e_
2026/05/08 14:53:20.089 /dev/ttyS0 read 9
\x04\x03\x04\xff\xff\xe0"f\xce
2026/05/08 14:53:20.090 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.091 /dev/ttyS0 write 8
\x04\x03 \x06\x00\x02/\x9f
2026/05/08 14:53:20.104 /dev/ttyS0 read 8
\x04\x03 \x06\x00\x02/\x9f
2026/05/08 14:53:20.128 /dev/ttyS0 read 9
\x04\x03\x04\xff\xff\xe67\xa4\xa1
2026/05/08 14:53:20.128 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.129 /dev/ttyS0 write 8
\x04\x03 \b\x00\x02N\
2026/05/08 14:53:20.142 /dev/ttyS0 read 8
\x04\x03 \b\x00\x02N\
2026/05/08 14:53:20.166 /dev/ttyS0 read 9
\x04\x03\x04\x00\x00\x00\x00\xaf3
2026/05/08 14:53:20.166 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.167 /dev/ttyS0 write 8
\x04\x03 \n\x00\x02\xef\x9c
2026/05/08 14:53:20.181 /dev/ttyS0 read 8
\x04\x03 \n\x00\x02\xef\x9c
2026/05/08 14:53:20.205 /dev/ttyS0 read 9
\x04\x03\x04\x00\x00\x10\xce#g
2026/05/08 14:53:20.205 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.782 /dev/ttyS0 write 8
\x02\x03\x00\b\x00\x02E\xfa
2026/05/08 14:53:20.806 /dev/ttyS0 read 17
\x02\x03\x00\b\x00\x02E\xfa\x02\x03\x04A\xfa\x00\x00\xfd>
2026/05/08 14:53:20.807 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.808 /dev/ttyS0 write 8
\x02\x03\x00\x04\x00\x02\x85\xf9
2026/05/08 14:53:20.831 /dev/ttyS0 read 17
\x02\x03\x00\x04\x00\x02\x85\xf9\x02\x03\x04B\xaaT\x8b\x83\xcc
2026/05/08 14:53:20.832 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.835 /dev/ttyS0 write 8
\x02\x03\x00\x00\x00\x02\xc48
2026/05/08 14:53:20.859 /dev/ttyS0 read 17
\x02\x03\x00\x00\x00\x02\xc48\x02\x03\x04\x00\x00\x00\x00\xc93
2026/05/08 14:53:20.860 modbusInterpose::readIt, CRC error
2026/05/08 14:53:20.887 /dev/ttyS0 write 8
\x02\x03\x00\x06\x00\x02$9
2026/05/08 14:53:20.910 /dev/ttyS0 read 17
\x02\x03\x00\x06\x00\x02$9\x02\x03\x04C8;\xd0O\xd6
2026/05/08 14:53:20.911 modbusInterpose::readIt, CRC error
2026/05/08 14:53:21.154 /dev/ttyS0 write 8
\x02\x03\x00\f\x00\x04\x849
2026/05/08 14:53:21.182 /dev/ttyS0 read 21
\x02\x03\x00\f\x00\x04\x849\x02\x03\b@g\az\v\xdd\xa6\xa0\xb9\xde
2026/05/08 14:53:21.183 modbusInterpose::readIt, CRC error
2026/05/08 14:53:21.183 /dev/ttyS0 write 8
\x01\x03\x00\b\x00\x02E\xc9
2026/05/08 14:53:21.196 /dev/ttyS0 read 8

If I split these into separate frames manually, they seem valid:

• Request: 01 03 00 04 00 02 85 ca (slave 1, function 3, start 0x0004, 2 registers)
• Response: 01 03 04 43 2d 74 4d 98 8b (4 data bytes + CRC)

Same pattern for the other examples: the first part of the read buffer is identical to the request I just wrote, and the trailing bytes match what looks like a valid Modbus RTU response (address, function, byte count, data, CRC).

However, modbusInterpose::readIt reports a CRC error, which suggests that the code is probably computing CRC over the entire 17 or 21 bytes (request + response) instead of over each frame individually.

What I suspect is happening

1. The serial driver sometimes returns both the outgoing request (echoed back) and the incoming response in a single read.
2. The current Modbus receive logic in the module appears to:

• Treat the entire read buffer as one frame, and

• Compute CRC over that whole buffer instead of:

  • Stripping any echoed request, and
    

  • Parsing one Modbus RTU response frame at a time based on address/function/byte count (for function 3/4), or length for other functions.
    

3. As a result, I get CRC error in the log even though the actual response frame on the wire has a correct CRC.

Note: I understand that my RS‑485 wiring is not perfect (short bus, mixed star + daisy chain, no terminators). But at 9600 baud, 1–2 m, this ran stably for about a year before adding the new device. The CRC errors now appear systematically when the request and response bytes are read “glued together”, which looks more like a framing/parse issue than random bit errors.

What I’d like to ask / propose

• Could the Modbus RTU receive logic be adjusted so that it:

  • Treats the serial input as a byte stream and parses one Modbus RTU frame at a time, rather than assuming that one read() corresponds to exactly one frame?
  • For function 03/04 responses, uses the byte count field ([addr][func][byteCount]…) to determine the expected frame length (3 + byteCount + 2 bytes) and only then performs CRC on that exact slice.
  • Optionally detects and discards an echoed request (if the first N bytes of the buffer are identical to the last transmitted request), then parses the following response frame(s) normally.

• If there is already a recommended configuration or an option in the current module that:

• Disables request echo handling,

  • Or enables stricter RTU framing based on byteCount,
  • please let me know how I should configure it.

Reproduction outline

1. RS‑485, 9600 baud, short cable (~1–2 m), multiple slaves.
2. Use modbus module to poll holding registers from multiple slave addresses (e.g. 1 and 4).
3. Enable detailed logging around modbusInterpose::readIt and serial I/O.
4. Observe that some read() calls return “request + response” concatenated, and that these cases are logged as CRC error even though the request and response, if separated, have valid CRCs.

If you need more details (EPICS/modbus version, device list, or additional logs), I can provide them. I’m also happy to test a patch that changes the receive framing logic.

Thanks for your work on this module, and for any guidance on how to fix or work around this “glued frames” CRC issue.

[MarkRivers]

I think the real issue is that your device is echoing the Modbus command. That is not correct, the Modbus specification does not allow that.

Here is the communication I see with an RS-485 Modbus device using traceIOHex:

01 02 01 00 a1 88
2026/05/11 13:17:34.792 gsets22:4002 write 8

01 04 00 00 00 2a 71 d5
2026/05/11 13:17:34.821 gsets22:4002 read 89

01 04 54 00 00 41 de 12 75 43 1a e2 80 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 78 02 84 02 84 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 08 00 00 00 08 00 00 10 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 86 ce
2026/05/11 13:17:34.878 gsets22:4002 write 8

01 03 00 00 00 2e c5 d6
2026/05/11 13:17:34.909 gsets22:4002 read 97

01 03 5c 00 01 00 01 00 01 00 01 00 00 41 20 00 00 41 20 28
f6 41 f0 87 b9 44 bb 05 32 44 e0 f1 03 46 ea 5e 2e 3f a6 04
19 3f a5 7d bf 46 6a 50 63 46 6a 50 63 41 f0 00 00 41 f0 00
00 00 02 00 00 00 01 00 00 44 d7 76 0f 40 00 00 00 00 00 07
d0 07 d0 00 0f 00 0f 0f a0 07 d0 00 0f 00 0f 0f 5e
2026/05/11 13:17:34.909 gsets22:4002 write 8

01 01 00 00 00 1f 7d c2
2026/05/11 13:17:34.916 gsets22:4002 read 9

01 01 04 10 00 00 10 fe dd
2026/05/11 13:17:34.916 gsets22:4002 write 8

01 02 00 00 00 06 f8 08
2026/05/11 13:17:34.923 gsets22:4002 read 6

01 02 01 00 a1 88
2026/05/11 13:17:34.923 gsets22:4002 write 8

01 04 00 00 00 2a 71 d5
2026/05/11 13:17:34.952 gsets22:4002 read 89

01 04 54 00 00 41 e1 0d 8c 43 1a b2 f5 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 78 02 84 02 84 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 08 00 00 00 08 00 00 10 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 47 93
2026/05/11 13:17:35.009 gsets22:4002 write 8

01 03 00 00 00 2e c5 d6
2026/05/11 13:17:35.040 gsets22:4002 read 97

01 03 5c 00 01 00 01 00 01 00 01 00 00 41 20 00 00 41 20 28
f6 41 f0 87 b9 44 bb 05 32 44 e0 f1 03 46 ea 5e 2e 3f a6 04
19 3f a5 7d bf 46 6a 50 63 46 6a 50 63 41 f0 00 00 41 f0 00
00 00 02 00 00 00 01 00 00 44 d7 76 0f 40 00 00 00 00 00 07
d0 07 d0 00 0f 00 0f 0f a0 07 d0 00 0f 00 0f 0f 5e
2026/05/11 13:17:35.040 gsets22:4002 write 8

01 01 00 00 00 1f 7d c2
2026/05/11 13:17:35.047 gsets22:4002 read 9

01 01 04 10 00 00 10 fe dd

Note that the read message does not contain an echo of the write message.

This is the output when I use asynTraceIOEscape.

2026/05/11 13:22:59.010 gsets22:4002 write 8
\x01\x01\x00\x00\x00\x1f}\xc2
2026/05/11 13:22:59.018 gsets22:4002 read 9
\x01\x01\x04\x10\x00\x00\x10\xfe\xdd
2026/05/11 13:22:59.018 gsets22:4002 write 8
\x01\x02\x00\x00\x00\x06\xf8\b
2026/05/11 13:22:59.024 gsets22:4002 read 6
\x01\x02\x01\x00\xa1\x88
2026/05/11 13:22:59.024 gsets22:4002 write 8
\x01\x04\x00\x00\x00*q\xd5
2026/05/11 13:22:59.053 gsets22:4002 read 89
\x01\x04T\x00\x00A\xfb\xe1eC\"P4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00x\x02\x84\x02\x84\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\b\x00\x00\x00\b\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00xX
2026/05/11 13:22:59.110 gsets22:4002 write 8
\x01\x03\x00\x00\x00.\xc5\xd6
2026/05/11 13:22:59.141 gsets22:4002 read 97
\x01\x03\\\x00\x01\x00\x01\x00\x01\x00\x01\x00\x00A \x00\x00A (\xf6A\xf0\x87\xb9D\xbb\x052D\xe0\xf1\x03F\xea^.?\xa6\x04\x19?\xa5}\xbfFjPcFjPcA\xf0\x00\x00A\xf0\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00D\xd7v\x0f@\x00\x00\x00\x00\x00\a\xd0\a\xd0\x00\x0f\x00\x0f\x0f\xa0\a\xd0\x00\x0f\x00\x0f\x0f^
2026/05/11 13:22:59.141 gsets22:4002 write 8
\x01\x01\x00\x00\x00\x1f}\xc2

Again the read message does not contain an echo of the write message.

There should be a way you can disable the device echoing the Modbus commands, because that violates the Modbus specification.

[MarkRivers]

@akiracc have you made any progress on this? Can you disable the echo on your device?