Skip to content
This repository has been archived by the owner on Mar 4, 2023. It is now read-only.

建立连接读取数据一段时间后提示modbus: response transaction id '20' does not match request '21' #12

Open
dongyuepeng opened this issue Jul 17, 2021 · 14 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@dongyuepeng
Copy link

modbusTCPMaster =>2021/07/18 00:47:40 [D]: sending [00 15 00 00 00 06 01 03 00 00 00 08]
modbusTCPMaster =>2021/07/18 00:47:40 [D]: received [00 14 00 00 00 13 01 03 10 00 23 09 4e 00 0d 00 0e 00 0f 00 10 00 00 00 00]
modbus: response transaction id '20' does not match request '21'
请问这个是什么原因造成的?

@dongyuepeng
Copy link
Author

image
瀚海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]

正常数据是这个样子的。

@thinkgos
Copy link
Member

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

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

@thinkgos thinkgos added the help wanted Extra attention is needed label Jul 18, 2021
@dongyuepeng
Copy link
Author

每次正常通讯十几二十分钟以后就会开始提示这些:
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'

@thinkgos
Copy link
Member

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

@fsyxhua
Copy link

fsyxhua commented Oct 9, 2021

也有遇到这个问题,运行一会儿就出现;
微信截图_20211009173924

@fsyxhua
Copy link

fsyxhua commented Oct 9, 2021

看样子应该是TCP Retransmission导致的,一旦错位,就修改不过来了,就会一直错下去
微信截图_20211009192014

@thinkgos
Copy link
Member

thinkgos commented Oct 9, 2021

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

@fsyxhua
Copy link

fsyxhua commented Oct 10, 2021

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

@thinkgos
Copy link
Member

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

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

@ymmemo
Copy link

ymmemo commented Oct 15, 2021

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

@thinkgos
Copy link
Member

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

@ymmemo
Copy link

ymmemo commented Oct 15, 2021

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

@thinkgos
Copy link
Member

thinkgos commented Oct 15, 2021

@ymmemo

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

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

@do-peace
Copy link

do-peace commented Oct 23, 2021

遇到同样的问题。

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

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

5 participants