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

在工业物联网现场，Modbus通信不通是最高频的故障。排查半天，怀疑设备坏了、怀疑线接错了，其实最快的办法只有一个：抓包看数据。

不看数据包就猜问题，等于闭着眼睛修车。这篇文章以Modbus RTU为例，说清楚怎么用串口工具抓包、看什么、怎么定位问题。

一、先搞清楚一条Modbus RTU报文长什么样

抓包之前，得先知道正常的数据长什么样。

一条Modbus RTU请求报文，结构是：从站地址（1字节）+ 功能码（1字节）+ 数据（N字节）+ CRC校验（2字节）。

以“读取从站1的保持寄存器，起始地址0，读1个寄存器”为例，报文是：01 03 00 00 00 01 84 0A。

• 01：从站地址
• 03：功能码（读保持寄存器）
• 00 00：起始地址
• 00 01：读取数量
• 84 0A：CRC校验

如果从站正常回复，报文是：01 03 02 XX XX CRC。如果从站回复的是异常报文，功能码最高位会置1（03变成83），后面跟一个异常码。比如 01 83 02 XX XX，表示“读取保持寄存器”操作失败，异常码02代表“非法数据地址”。

二、抓包工具用什么

最常用的是串口调试助手和Modbus Poll。

串口调试助手适合看原始字节流。设置好串口号、波特率、数据位、停止位、校验位，打开串口，就能看到总线上收发的所有数据。优点是简单直接，缺点是需自己解析报文含义。

Modbus Poll适合做Modbus专用调试。配置好从站地址、功能码、起始地址、寄存器数量，它会自动发送请求并显示回复。优点是直观，缺点是看不到原始报文，不适合排查底层通信问题。

实际排查时，两个工具配合用：先用串口助手看原始字节，确认数据有没有发出去、有没有回复。再用Modbus Poll验证解析后的数值是否正确。

三、三种典型故障的抓包分析

故障一：发出去没回复。 串口助手上只看到发送的报文，没有收到任何回复。可能原因：A/B线接反了、从站地址不对、从站设备没上电、波特率不匹配。

故障二：回复了但全是乱码。 发送的报文正常，收到的回复是一堆乱码。可能原因：波特率不匹配、数据位/停止位/校验位配置不一致。

故障三：回复了但CRC校验错误。 收到的报文格式看起来正常，但CRC校验通不过。可能原因：通信干扰导致数据位翻转、线缆过长信号衰减、终端电阻没接。先用低速测试（如9600bps），如果低速正常高速出错，说明是速率问题。

四、抓包排查的完整流程

遇到Modbus RTU通信问题，按这个流程走：

第一步，用串口助手确认主机发出的报文是否正确（对照协议格式检查从站地址、功能码、起始地址、数量、CRC）。

第二步，确认从站有没有回复。没回复就查物理层（供电、接线、地址、波特率）。有回复就进入下一步。

第三步，对比回复报文和预期格式（功能码是否正常、数据字节数是否正确、数据值是否合理、CRC是否通过）。

第四步，如果回复正常但读到的数值不对，检查寄存器地址、数据类型和字节序的配置。

你调Modbus的时候，抓包抓到过什么离谱的数据？评论区聊聊。