RTU over TCP error: response data size '5' does not match count '4'

[branimirborisov]

I'm trying to read a RTU device routed over TCP using both the library (via InfluxDB Telegraf) and the modbus-cli tool. In both cases trying to read the device results in the following error:

modbus: response data size '5' does not match count '4'

Cli command is:

./modbus-cli.amd64 -address tcp://{HOST}:{PORT} -register 40807 -quantity 2 -slaveID 1

When switching to RTUoverTCP I get the following timeout error:

read tcp 172.24.0.3:52840->{HOST}:{PORT}: i/o timeout

Device is SIEMENS SICAM P with Modbus RTU translated over TCP.

Note: When using another tool, for example modpoll register value is parsed correctly, e.g.:

modpoll -p ${MODBUS_PORT} -a 1 -f -t 4:float -r 40807 ${MODBUS_HOST} 

results in:

[40807]: 213209248.000000
...

Is there some additional parameter I'm missing that needs to be specified to parse correctly the value or is it some issue with the library implementation and the device compatibility?

Thanks!

[branimirborisov]

Hi, Which query actually do you refer to? What do you mean by using a different port? Thanks! На нд, 22.05.2022 г. в 11:57 ч. andig ***@***.***> написа:

…

You RTU query uses a different port. Why? — Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUSLFM5KVPVSQXX6ASJJOTVLHZF5ANCNFSM5WS7C5QA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[srebhan]

The origin of the error is here:

modbus/client.go

Line 125 in c4a3d04

err = fmt.Errorf("modbus: response data size '%v' does not match count '%v'", length, count)

It seems like the device is sending more data then expected. You might want to soften the constrains in L124 to

	if count <= length {

and do

	if count <= length {
		err = fmt.Errorf("modbus: response data size '%v' does not match count '%v'", length, count)
		return
	}
	results = response.Data[1:count+1]

[andig]

That sounds like bad advise to me- you'd never know which parts of the response are the correct ones.

From the description it is not entirely clear if the device needs be addressed using Modbus RTU or TCP. Let's assume RTU. The first error is clear then- addressed as TCP the device might respond with anything, having misunderstood the request. As it doesn't match the expected TCP structure that will error.

It's unclear though, why the second request returns i/o timeout which is before Modbus (any kind of it) is even spoken.

[branimirborisov]

@andig The device should be address via TCP. Its actually RTU device using a TCP converter. So at the end we should address it as TCP device.

Also as I have described when using another tool - modpoll and addressing the device as TCP I'm able to read the data. So I would also suggest to look into the TCP implementation and see if we can also cover this case.

What if we follow the suggested approach from @srebhan and skip the check or if its actually needed for some cases to introduce a option/flag that will allow us to toggle it on/off? This way it can be enabled by default, but I would be able to turn it off and use it with the particular device?

[andig]

Just to be sure because this can be tricky. Are you really sure that you have an RTU to TCP protocol converter? Not just an RS485 to Ethernet adapter (which would expose RTU over TCP)?

It still doesn‘t figure that in the RTU case you‘ve tried the port couldn‘t be connected to either.

In any case, if application wants x bytes, y bytes response should be an error (opened #53 based on such an experience).

[frzifus]

Regarding the precise response length, I agree with @andig. But before we start tweaking the software, lets collect some more details.

@branimirborisov could you compile and test a modbus-cli based on the latest master commit (0daecbb)? Just to make sure that this problem still exists.

if its still an issue, could you run the modbus-cli command again and append -log-frame to collect more details about the transmitted data?

Usage of ./modbus-cli:
  -log-frame
    	prints received and send modbus frame to stdout

Next we should try the same with modpoll to compare sent and received data. Since I have never used modpoll, I do not know how to record them. But maybe -v is worth a try.

usage : mbpoll [ options ] device|host [ writevalues... ] [ options ]

ModBus Master Simulator. It allows to read and write in ModBus slave registers
                         connected by serial (RTU only) or TCP.
  -v            Verbose mode.  Causes mbpoll to print debugging messages about
                its progress.  This is helpful in debugging connection...

Update:
If modpoll -v does not provide any details, we could record[0] them via tcpdump.

---

0: https://www.plcnext-community.net/makersblog/network-record-with-tcpdump/

[branimirborisov]

@frzifus i'm trying to build the modbus-cli form the latest version in master branch, but I'm getting following error:

cmd/modbus-cli/main.go:285:11: cannot use "github.com/grid-x/serial".RS485Config literal (type "github.com/grid-x/serial".RS485Config) as type "github.com/grid-x/modbus/vendor/github.com/grid-x/serial".RS485Config in assignment

Maybe I'm doing something wrong? Can you provide some instructions on how to build the cli from master? I'm on Ubuntu 18.04 with go 1.10.4?

[andig]

Your go is ancient. Upgrade to a version from this century ;)

[branimirborisov]

@andig @frzifus Running the modbus-cli from master with the -log-frame option results in:

./main -address tcp://{HOST}:{PORT} -register 40807 -quantity 2 -slaveID 1 -log-frame
modbus: send 00 01 00 00 00 06 01 03 9f 67 00 02
modbus: recv 00 01 00 00 00 08 01 03 04 4d 6b ca 16 4b
modbus: response data size '5' does not match count '4'

Any suggestions? Thank you!

[andig]

So what's the mbpoll output in comparison?

[branimirborisov]

So what's the mbpoll output in comparison?

-- Polling slave... (Ctrl-C to stop)
[40807]: 247596832.000000
-- Polling slave... (Ctrl-C to stop)
[40807]: 247597152.000000
-- Polling slave... (Ctrl-C to stop)
[40807]: 247597152.000000
-- Polling slave... (Ctrl-C to stop)
[40807]: 247597152.000000
-- Polling slave... (Ctrl-C to stop)
[40807]: 247597472.000000
-- Polling slave... (Ctrl-C to stop)

[srebhan]

Which corresponds to the first four bytes in the response as IEEE float.

[branimirborisov]

@andig @frzifus Any feedback regarding the issue, do you plan on adopting some changes in the library at this point or not? I need some info to decide weather we proceed with the Telegraf plugin on our side or try to find another solution to read the device?

[frzifus]

Would be nice to get a more detailed view of your mbpoll request first. have you tried to capture the TCP packets which include modbus send and recv payload?