建立连接读取数据一段时间后提示modbus: response transaction id '20' does not match request '21' about go-modbus HOT 14 OPEN

看样子应该是TCP Retransmission导致的，一旦错位，就修改不过来了，就会一直错下去

from go-modbus.

😂很久不弄modbus了，我找个时间看一下，如果能谁能修改，麻烦提个PR上来

from go-modbus.

瀚海PLC温度数据 []int16{35, 1894, 13, 14, 15, 16, 0, 0}
这是主线程获取的 [35 1894 13 14 15 16 0 0]
modbusTCPMaster =>2021/07/18 01:35:40 [D]: sending [00 2d 00 00 00 06 01 03 00 00 00 08]
modbusTCPMaster =>2021/07/18 01:35:40 [D]: received [00 2d 00 00 00 13 01 03 10 00 26 08 6d 00 0d 00 0e 00 0f 00 10 00 00 00 00]
瀚海PLC温度数据 []int16{38, 2157, 13, 14, 15, 16, 0, 0}
这是主线程获取的 [38 2157 13 14 15 16 0 0]
modbusTCPMaster =>2021/07/18 01:35:42 [D]: sending [00 2e 00 00 00 06 01 03 00 00 00 08]
modbusTCPMaster =>2021/07/18 01:35:42 [D]: received [00 2e 00 00 00 13 01 03 10 00 28 08 5a 00 0d 00 0e 00 0f 00 10 00 00 00 00]
瀚海PLC温度数据 []int16{40, 2138, 13, 14, 15, 16, 0, 0}
这是主线程获取的 [40 2138 13 14 15 16 0 0]

正常数据是这个样子的。

from go-modbus.

@dongyuepeng modbus: response transaction id '20' does not match request '21' ,这个理论上不会发生... transaction id是客户端传什么 ,服务端回什么 .

然后第二个问题,有啥问题?? 打印日志是16进制的

from go-modbus.

每次正常通讯十几二十分钟以后就会开始提示这些：
modbus: response transaction id '20' does not match request '21'
modbus: response transaction id '21' does not match request '22'
modbus: response transaction id '22' does not match request '23'

from go-modbus.

@dongyuepeng 麻烦提供下串口参数,发送间隔,并发请求是多少.

from go-modbus.

也有遇到这个问题，运行一会儿就出现；

from go-modbus.

😂很久不弄modbus了，我找个时间看一下，如果能谁能修改，麻烦提个PR上来
感觉像默认超时太短了，Trans ID 7510的请求和回复间隔超过了2s，默认超时时间为1s，io.ReadFull的长度为0

from go-modbus.

joy很久不弄modbus了，我找个时间看一下，如果能谁能修改，麻烦提个PR上来
感觉像默认超时太短了，Trans ID 7510的请求和回复间隔超过了2s，默认超时时间为1s，io.ReadFull的长度为0

这没根本解决问题呀. 如果只是修改超时时间,没必要改代码, 有个WithTCPTimeout可以修改这个超时时间

from go-modbus.

一样有遇到这个问题。
测试通常发请求问一个位置模拟器约花100ms，但难以预估这个timeout到底设置多少会合理? 如果短时间内发大量请求，timeout时间也不宜太长，可能会造成请求累积，太短又怕错砍掉请求并可能遇上上述问题?

from go-modbus.

理论上我这个设计对于modbus TCP是有问题的. modbus的TCP不同于RTU,ASCII那样必定一主一从. TCP是可以并发的请求,而且还有网络延迟,通过TID来识别某个请求, 需要完全解决这个问题, 可以引入chan, 并起一个goroutine来专门处于收到的回复. 而每个请求需要挂载等回复,超时做丢弃. 可以保证解决这个问题.

from go-modbus.

@thinkgos
请教使用同一连线的做法也可以并发请求吗?测试是会依序进行，异常timeout设置不宜建立过长。使用不同连线则可行，须建立较多连线数。

from go-modbus.

@ymmemo

同一连接并发请求, 测试并不是依序进行. 异常timeout只对每一个请求
做法如下:
1: 创建TCP客户端实例, 启动一个读监听.
2: 发起请求, 生成一个挂载请求放在该TPC客户端实例全局中,设置异常超时时间, 该请求进行wait(使用用chan), 超过异常时间则返回,并删除挂载的请求
3: 读监听实时读数据, 在TCP客户端实例检查相应TID, 唤醒对应的wait的请求. 如果相应TID不存在,丢弃该回复.
4: TCP客户端实例销毁, 销毁读监听.

以上是我想的方案, 这是同步的,异步的话,设置回调函数就更简单了. actor模型

from go-modbus.

遇到同样的问题。

一秒去问一个位置，超时设置在三秒，
正常一秒一次读取，运行一分钟后，遇到一次超时，，
会遇到一樣錯誤 Ex: modbus: response transaction id '4' 与 request '5' 不匹配

现在只能尽量把超时时间拉长。

from go-modbus.