ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Modbus RTU调试总失败?用串口工具抓包,五分钟定位问题

Modbus RTU调试总失败?用串口工具抓包,五分钟定位问题 在CSDN上搜“Modbus调试”能看到大量求助帖。通信不通、数据不对、时好时坏——问题描述五花八门但真正有效的排查手段只有一个抓包看数据。不看数据包就猜问题等于闭着眼睛修车。这篇文章以Modbus RTU为例说清楚怎么用串口工具抓包、看什么、怎么定位问题。一、先搞清楚一条Modbus RTU报文长什么样抓包之前得先知道正常的数据长什么样。一条Modbus RTU请求报文结构是这样的从站地址1字节 功能码1字节 数据N字节 CRC校验2字节以“读取从站1的保持寄存器起始地址0读1个寄存器”为例报文是01 03 00 00 00 01 84 0A01从站地址03功能码读保持寄存器00 00起始地址00 01读取数量84 0ACRC校验从站正常回复的报文是01 03 02 XX XX CRC01从站地址03功能码02数据字节数XX XX寄存器值CRC校验码如果从站回复的是异常报文功能码最高位会置103变成83后面跟一个异常码。比如 01 83 02 XX XX表示“读取保持寄存器”这个操作失败了异常码02代表“非法数据地址”。二、抓包工具用什么最常用的工具是串口调试助手和Modbus Poll。串口调试助手适合看原始字节流。设置好串口号、波特率、数据位、停止位、校验位打开串口就能看到总线上收发的所有数据。优点是简单直接能看到每一个字节。缺点是需要自己解析报文含义。Modbus Poll适合做Modbus专用调试。配置好从站地址、功能码、起始地址、寄存器数量它会自动发送请求并显示回复。优点是直观能看到解析后的数值。缺点是看不到原始报文不适合排查底层通信问题。实际排查时两个工具配合用先用串口助手看原始字节确认数据有没有发出去、有没有回复。再用Modbus Poll验证解析后的数值是否正确。三、三种典型故障的抓包分析故障一发出去没回复串口助手上只看到发送的报文没有收到任何回复。可能原因A/B线接反了、从站地址不对、从站设备没上电、波特率不匹配。先从最简单的开始查——确认设备上电了地址是对的A/B线没接反。如果发送的报文在串口助手上显示为乱码说明波特率或数据格式配置有误。故障二回复了但全是乱码发送的报文正常收到的回复是一堆乱码。可能原因波特率不匹配、数据位/停止位/校验位配置不一致、A/B线接反。波特率不匹配是最常见的比如主机用9600发从站用19200收收到的数据就是乱码。逐个试几个常用波特率看哪个能收到正常回复。故障三回复了但CRC校验错误收到的报文格式看起来正常但CRC校验通不过。可能原因通信干扰导致数据位翻转、线缆过长信号衰减、终端电阻没接。先用低速测试比如9600bps如果低速正常高速出错说明是速率问题。如果低速也出错检查终端电阻和屏蔽层接地。四、一个容易被忽略的细节帧间隔Modbus RTU靠“帧间隔”来区分不同的报文。标准规定帧间隔至少是3.5个字符时间。如果两条报文之间间隔太短接收方会把它们当成一条报文解析必然出错。在串口助手上看如果发送的报文和接收的报文之间几乎没有间隔或者接收方把两条回复合并成了一条显示说明帧间隔不够。这种情况通常出现在高速轮询时主机发完一条指令后等待时间太短从站还在回复上一条主机又发了下一条。解决方法在网关或主机的配置中增大“帧间隔”或“指令超时时间”。给从站足够的响应时间不要卡着理论值去配。五、抓包排查的完整流程遇到Modbus RTU通信问题按这个流程走第一步用串口助手确认主机发出的报文是否正确。对照协议格式检查从站地址、功能码、起始地址、数量、CRC。第二步确认从站有没有回复。如果没有回复查物理层——供电、接线、地址、波特率。如果有回复进入下一步。第三步对比回复报文和预期格式。功能码是否正常最高位没被置1、数据字节数是否正确、数据值是否合理、CRC是否通过。第四步如果回复正常但读到的数值不对检查寄存器地址、数据类型和字节序的配置。第五步如果通信时好时坏查终端电阻、屏蔽层接地、线缆长度和波特率。你调Modbus的时候抓包抓到过什么离谱的数据评论区聊聊。
返回列表