调试为什么需要两侧工具
Modbus 是主从问答：一边发请求，一边应答，任何一方的超时、功能码支持范围、寄存器映射都可能出问题。把问题一口咬定在设备或软件上，往往白跑现场。正确做法是先用从站仿真程序占住一方，把另一方的行为单独验证；有真实设备时再用主站轮询工具逐点读数，最后用抓包看清交互时序与异常码。
基本信息
| 从站仿真 | 模拟设备侧寄存器，验证主站采集逻辑 |
|---|---|
| 主站轮询 | 主动读真实设备，验证映射与响应速度 |
| 虚拟串口 | 在电脑上造一对互联串口，无需真实硬件测 RTU |
| 报文抓包 | 解析功能码、异常码与帧间隔，区分协议与线路问题 |
| 脚本化 | 用库直接发请求，便于批量回归与压测 |
典型使用场景
- 上位机程序开发阶段：用仿真从站造出各种异常响应，验证软件的容错
- 现场接入新设备前，先用轮询工具确认寄存器表与手册一致
- 排查偶发超时：抓包看是应答慢、丢帧，还是软件轮询间隔过短
- 验证 RTU 参数：用虚拟串口对反复调整波特率与校验位组合
- 压力测试：脚本批量读多个从站，观察从站处理能力与总线负载上限
- 回归验证：把仿真从站固化为固定地址表，程序改动后跑一遍比对
工具类型与用途
| 类型 | 代表方案 | 主要用途 |
|---|---|---|
| 从站仿真 | pymodbus 脚本、Modbus 从站模拟器 | 造数据与异常，验证主站 |
| 主站轮询 | mbpoll、组态软件自带的通道诊断 | 读真实设备，核对手册映射 |
| 报文分析 | Wireshark 的 Modbus 解析器 | 看功能码、异常码、时序与重试 |
| 虚拟串口 | com0com 一类的串口对驱动 | 两台软件在无硬件下对接 RTU |
| 自研脚本 | Python + 协议库 | 批量回归、压测、生成测试数据 |
用脚本造从站与压测
用脚本造从站与压测
# 从站：把 0 号保持寄存器固定返回 1234
from pymodbus.server import StartTcpServer
from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext
ctx = ModbusSlaveContext(hr=[1234]) # 保持寄存器初始值
StartTcpServer(context=ModbusServerContext(slaves=ctx, single=True), address=('0.0.0.0', 502))
# 主站压测：连续读写并统计超时次数
# mbpoll -m tcp -a 1 -t 4 -r 1 -c 10 -p 502 -P 1 192.168.1.10RTU 的帧间隔很关键：请求之间必须留出足够的静默时间，抓包时看时间戳就能发现软件把请求发得太密，导致从站还没处理完就被打断。
对真实设备做写测试前必须确认该地址是否影响生产，尤其是线圈与设定值寄存器；先在仿真从站上把写逻辑跑通，再对现场设备操作。