Wait for correct response id

[decadenza]

Due to noise/interference on the serial line (separate problem), I was having errors like:

error="modbus: response slave id '69' does not match request '1'"
error="modbus: response slave id '48' does not match request '1'"

And so on.

My system has only one slave with id 1.
I came across this issue on a different repository.

As I understand it, Modbus protocol specifies that master should manage the "unexpected slave" and wait for the correct one for the specified timeout setting.

Checking the code I realised that the client was not waiting for the correct timeout before throwing the error.

With this simple change my error rate has reduced, and when it happens the correct "timeout" error is given.

[decadenza]

Added error value err = fmt.Errorf("modbus: response timeout")

[frzifus]

Does it make sense to limit the amount of retries and to introduce a break between the retries?

[decadenza]

@frzifus Yes, that is what I was doing as a sub-optimal measure. But I think it would be preferable to actually follow the specifications. The problem arises when the traffic is high. Any thoughts?

[hnicolaysen]

Hi @decadenza!

Please excuse the late reply here, I hope you're still around!
First of all, thank you for your contribution!

I really like your suggestion here, but I have a question left:
The automaton above shows a retry for the response reception. In your requested change, you also propose to re-send the request if the first response was not matching. Is this intended?

[decadenza]

Hi.
The re-send is intentional, but only until maxTime, calculated from the tcpTimeout parameter.

As an alternative, the user has to fire a re-attempt, but it looks more logical to use the timeout parameter that is already part of the library. What do you think?