3、Modbus通信测试实战：使用Modbus Poll/Slave工具进行点对点测试、常见故障排查（超时、CRC校验错误、地址不匹配）、抓包分析（Wireshark过滤Modbus TCP报文）
好，咱们进入实战环节。前面讲了那么多理论，说实话，不亲手敲几下键盘、抓几个包，那些知识都是飘着的。这一章，我带你用最趁手的工具——Modbus Poll和Modbus Slave，把通信链路彻底打通。
我个人习惯，调试之前先把工具准备好。Modbus Poll当主站，Modbus Slave当从站。这两个工具，说白了就是一对好基友。一个发命令，一个回响应。你想想看，如果连点对点都调不通，那后面接真实设备肯定抓瞎。
3.1 点对点测试：主站与从站握手
先打开Modbus Slave。我一般这么配：
- 选择协议：RTU Over TCP（或者直接选TCP/IP，看你的场景）
- 设置从站地址：比如1
- 功能码：03（读保持寄存器）
- 起始地址：0
- 寄存器数量：10
然后点OK。你会看到一片空白的数据区。别慌，手动填几个值进去，比如地址0填100，地址1填200。这样待会儿主站读回来，你能一眼看出对不对。
再打开Modbus Poll。配置主站：
- 从站地址：1（必须和Slave一致）
- 功能码：03
- 起始地址：0
- 寄存器数量：10
- 波特率/端口：根据你的连接方式选。如果是TCP，填IP和端口（默认502）
点击连接。如果一切正常，你会看到数据刷刷刷地显示出来。地址0显示100，地址1显示200。嗯，这就通了。
核心要点：主站和从站的参数必须完全匹配。地址、功能码、起始地址、数量，一个都不能错。我见过太多人栽在地址不匹配上。
3.2 常见故障排查：超时、CRC校验错误、地址不匹配
调试过程中，不出点问题反而不正常。我把自己踩过的坑给你列出来。
3.2.1 超时（Timeout）
现象：主站发完请求，等半天没响应，最后报超时。
原因分析：
- 物理连接不通。网线没插好，或者串口线接错了。
- 从站没开机，或者程序没跑起来。
- 波特率不匹配。RTU模式下，主站设9600，从站设19200，那肯定超时。
- 响应时间设置太短。Modbus Poll里有个“Response Timeout”参数，默认1000ms。如果从站处理慢，可以适当调大。
我的习惯：遇到超时，先ping一下IP地址。如果ping不通，别查协议了，先查网线。如果ping得通，再看端口502通不通。用telnet测一下，一测一个准。
3.2.2 CRC校验错误
现象：主站收到响应，但报CRC错误。数据看起来是乱的。
原因分析：
- 串口通信时，数据位、停止位、校验位设置不一致。比如主站设8N1，从站设8E1，CRC必错。
- 线路干扰。长距离通信或者现场有强电磁干扰，数据在传输过程中被篡改了。
- 从站程序有bug。CRC计算逻辑写错了。
避坑指南：我曾经在一个光伏项目上，CRC错误反复出现。查了两天，最后发现是串口线太长，信号衰减严重。换成屏蔽双绞线，问题解决。所以，别小看物理层。
3.2.3 地址不匹配
现象：主站发请求，从站没反应。或者主站收到了响应，但数据是别的设备的。
原因分析：
- 主站配置的从站地址，和从站实际地址不一致。
- 总线上挂了多个从站，地址冲突了。两个设备都设成地址1，那主站就懵了。
怎么排查？很简单。Modbus Slave里有个“Display”菜单，打开“Communication”窗口。你能看到主站发过来的请求报文。如果请求里的地址是1，但你从站设的是2，那肯定不理你。
3.3 抓包分析：Wireshark过滤Modbus TCP报文
有时候，工具界面显示正常，但你就是觉得哪里不对。这时候，抓包是终极手段。Wireshark，干这活的神器。
启动Wireshark，选择你的网卡。开始抓包。然后让Modbus Poll发几个请求。停止抓包。
怎么过滤？在过滤栏输入：
modbusWireshark会自动识别Modbus TCP协议。如果你只想看某个IP的流量：
modbus and ip.addr == 192.168.1.100点开一个报文，你会看到：
- Transaction Identifier（事务标识符）：用来匹配请求和响应。
- Protocol Identifier（协议标识符）：Modbus协议固定为0。
- Length（长度）：后面数据的字节数。
- Unit Identifier（单元标识符）：其实就是从站地址。
- Function Code（功能码）：比如03。
- Data（数据）：具体的寄存器地址和数值。
实战技巧：我经常用Wireshark来验证CRC计算对不对。虽然Modbus TCP本身不带CRC（那是RTU的事），但如果你在TCP上跑RTU封装，CRC字段就在数据末尾。Wireshark会帮你标出来，红色表示校验错误。一眼就能看出问题。
举个例子。有一次，现场反馈说数据偶尔跳变。我抓了半小时的包，发现每隔几分钟就有一个CRC错误的报文。顺着这个线索，找到了一个接触不良的端子。嗯，抓包就是这么有用。
3.4 本章知识体系
下面这张图，把Modbus通信测试的核心逻辑串起来了。从工具配置到故障排查，再到抓包验证，每一步都有对应的手段。
好了，这一章的内容就到这儿。工具会用，故障会查，包会抓，Modbus通信这块你基本就稳了。下一章咱们聊聊更复杂的场景——多从站轮询和性能优化。
公众号:蓝海资料掘金营，微信deep3321