tokio-modbus icon indicating copy to clipboard operation
tokio-modbus copied to clipboard

read_holding_registers not return correct result ?

Open glennpierce opened this issue 2 years ago • 2 comments

Hi I am having trouble reading multiple registers in this case.

I am reading 6 registers with the following

let result = client.read_holding_registers(2048, 6).await;

This returns

Ok([10, 61663, 1, 54857, 0, 0])

These are meant to be long values

If I use another implementation (modbus-cli (python commandline)))

I get

modbus 10.140.0.167 -s 15 h@2048/I -v
→ < 29 dc 00 00 00 06 0f 03 08 00 00 02 >
← < 29 dc 00 00 00 07 0f 03 04 00 0a f0 e0 > 13 bytes
← [10, 61664]

and

modbus 10.140.0.167 -s 15 h@2052/I -v
Parsed 0 registers definitions from 1 files
→ < 60 e8 00 00 00 06 0f 03 08 04 00 02 >
← < 60 e8 00 00 00 07 0f 03 04 00 01 d6 49 > 13 bytes
← [1, 54857]

Given this should read_holding_registers not return

Ok([10, 61663, 0, 0, 1, 54857])

glennpierce avatar Jan 12 '23 13:01 glennpierce

Actually the third party call does return like

modbus -v 10.140.0.167 -s 15 h@2048/2I
Parsed 0 registers definitions from 1 files
→ < 97 3b 00 00 00 06 0f 03 08 00 00 04 >
← < 97 3b 00 00 00 0b 0f 03 08 00 0a f1 29 00 01 d6 56 > 17 bytes
← [10, 61737, 1, 54870]

so I think I misunderstood the return format. why are the registers

2050 and 2051 removed. Is it device dependant if those registers can't be read.

glennpierce avatar Jan 12 '23 15:01 glennpierce

The representation of 32-bit values is not standardized. The result of client.read_holding_registers(2048, 6) should equal that of modbus 10.140.0.167 -s 15 h@2048/6H according to their docs.

uklotzde avatar Feb 28 '23 12:02 uklotzde