tokio-modbus fails to read data while direct serial communication works

[Alarak-Alex]

Issue: tokio-modbus fails to read data while direct serial communication works

Problem Description

When trying to read Modbus RTU data from a device, direct serial communication works successfully, but tokio-modbus library fails with IllegalDataValue error.

Working Implementation (Direct Serial)

// Manual request frame construction
let mut request = vec![0x01, 0x03, 0x01, 0x00, 0x00, 0x03];
let crc = crc16(&request);
request.push((crc >> 8) as u8);
request.push(crc as u8);

// Send request
port.write_all(&request).await?;

// Read response
let mut response = vec![0u8; 256];
let n = port.read(&mut response).await?;
let response = &response[..n];
println!("Device response: {:02X?}", response);
// Response: [01, 03, 06, 31, 3D, 31, 79, 30, FA, 03, F7]

Failing Implementation (tokio-modbus)

let slave = Slave(0x01);
let mut ctx = rtu::attach_slave(port, slave);
let rsp = ctx.read_holding_registers(0x0100, 3).await??;
// Error: IllegalDataValue

Environment

• OS: 15.3.1 (24D70)
• Serial Port: /dev/tty.usbserial-1110
• Serial Parameters:
  • Baud Rate: 4800
  • Data Bits: 8
  • Parity: None
  • Stop Bits: 1
  • Flow Control: None

Additional Information

1. The direct serial communication successfully receives a response from the device
2. The response data format appears to be valid Modbus RTU
3. The same serial port and parameters are used in both implementations
4. The device is responding with 6 bytes of data (as indicated by the 0x06 in the response)

Questions

1. Is there a known issue with address mapping in tokio-modbus?
2. Could the library be misinterpreting the response data format?
3. Are there any specific configuration requirements for handling non-standard response formats?

Reproduction Steps

1. Connect to the serial device with the specified parameters
2. Try reading holding registers using tokio-modbus
3. Compare with direct serial communication results

Any help or guidance would be greatly appreciated!

[uklotzde]

Are your sure that your device is following the Modbus spec?

RTU
When RTU mode is used for character framing, the error-checking field contains a 16-bit value implemented as two eight-bit bytes. The error check value is the result of a Cyclical Redundancy Check calculation performed on the message contents.
The CRC field is appended to the message as the last field in the message. When this is done, the low-order byte of the field is appended first, followed by the high-order byte. The CRC high-order byte is the last byte to be sent in the message.

You encode the CRC in a different byte order.

[uklotzde]

See also #322 for clarification.

[Alarak-Alex]

@uklotzde
Here's my communication data:

1. Program sends to device:
   [0x1 0x3 0x1 0x0 0x0 0x2 0xc5 0xf7]

2. Device response:
   [0x1 0x3 0x4 0x0 0x0 0x0 0x0 0x33 0xfa]

The device is responding correctly (as verified by a serial monitor), but tokio-modbus is not receiving the response.

I've tried:

1. Setting proper serial port parameters (4800 baud, 8N1)
2. Increasing timeout to 20 seconds
3. Using correct register address (0x1000)

This is exactly the same issue you mentioned regarding CRC byte order. The device is following the Modbus RTU specification where the CRC low-order byte is sent first, followed by the high-order byte.

Could you please provide guidance on:

1. How to properly handle the CRC byte order in tokio-modbus?
2. Are there any specific configuration options to handle this case?
3. Would it be possible to add a configuration option to handle different CRC byte orders?

My environment:

• OS: macOS
• Serial Port: /dev/tty.usbserial-230
• Baud Rate: 4800
• Data Bits: 8
• Parity: None
• Stop Bits: 1
• Flow Control: None

[uklotzde]

The CRC code of the response is 0x33FA which translates into bytes 0xFA, 0x33 and not 0x33, 0xFA as in your example response.

https://crccalc.com/?crc=01%2003%2004%2000%2000%2000%2000&method=CRC-16/MODBUS&datatype=hex&outtype=hex