（十三） YModbus从站模拟工具使用

GitHub 项目地址：https://github.com/lidecong133/YModbus

工具下载：YModbusTools v1.0.0
CSDN 下载：YModbus 从站模拟工具下载
运行环境：.NET 8.0，桌面工具建议安装 Microsoft .NET 8 Desktop Runtime

主站工具是拿来读设备的。

从站工具是反过来，拿来扮演设备的。

YModbus.SlaveApp的价值不只是“本机开一个假设备”。它更适合用来做主站程序测试、异常复现、报文观察。很多真实设备不方便乱写、不方便断电、不方便模拟异常，从站工具就可以把这些场景造出来。

下载和运行环境

主站工具和从站工具统一从 GitHub Release 下载：

YModbusTools v1.0.0 下载

这个版本提供 Windows x64 的YModbus.MasterApp和YModbus.SlaveAppzip 包，不是安装器。下载后解压运行即可。

从站模拟工具也可以从这里下载：

YModbus 从站模拟工具下载

运行前请先安装 .NET 8.0 运行环境。因为这是桌面工具，如果打开程序时提示缺少运行时，优先安装 Microsoft .NET 8 Desktop Runtime。

下载后建议先在本机做一次 TCP 回环测试。不要一上来就接真实设备，先确认工具本身能正常启动、监听、响应请求。

先造一个最简单的设备

本机测试可以这样做：

1. 打开 YModbus.SlaveApp
2. 选择 Modbus TCP/IP
3. 监听地址填127.0.0.1
4. 端口填1502
5. UnitId 填1
6. 保持寄存器0填1234
7. 保持寄存器1填5678
8. 点击启动

然后用主站工具或 CLI 读：

ymodbusread-holding-registers--host 127.0.0.1--port 1502--unit-id 1--address 0--quantity 2

能读到1234和5678，说明这套本机主从联调环境已经通了。

以后你测试主站程序，就不用每次都找真实设备。

Ignore Unit ID别一直开着

从站工具有 Ignore Unit ID 这类设置。

早期调试可以用。比如你只想确认主站有没有发请求，暂时不想纠结站号，打开它能省点事。

但正式测试时最好关掉。

真实设备通常不会忽略站号。你一直开着 Ignore Unit ID，主站 UnitId 配错也能读到值，等换成真实设备就会暴露问题。

我一般只在“先看有没有请求进来”这个阶段打开，确认链路通了以后就按真实站号测试。

数据区可以当成一张设备状态表

从站工具里有四类数据区：

• 线圈
• 离散输入
• 保持寄存器
• 输入寄存器

你可以把它当成一张设备状态表。

比如模拟一台简单温控设备：

主站读输入寄存器0，解析成23.5。

主站写保持寄存器1，修改目标温度。

主站读线圈或离散输入，看状态变化。

这样一个很小的模拟，就能把主站界面、地址表、数据显示、写入流程都跑一遍。

测主站写入，先看从站数据有没有变

很多主站程序写入后只提示“成功”，但成功到底是什么成功？

从站工具能帮你确认。

比如主站发06，写保持寄存器100 = 500。

从站工具里地址100应该变成500。

如果没变，按顺序看：

• 主站有没有真的发写请求
• 从站报文窗口有没有 RX
• UnitId 是否匹配
• 写的是不是保持寄存器
• 地址是不是100
• 从站是否处于启动状态

这比只看主站弹窗靠谱。

异常仿真要多用

真实项目里，主站程序不能只处理成功响应。

从站工具可以模拟异常，比如：

• 非法功能
• 非法数据地址
• 非法数据值
• 设备故障
• 设备忙

我建议开发主站时至少测两个场景：

一个是非法数据地址。

主站应该提示类似“设备返回非法数据地址，检查功能码、起始地址和数量”，而不是只写“读取失败”。

另一个是设备忙。

主站可以提示稍后重试，或者根据策略做有限重试。

这些提示会直接影响现场人员排查效率。

慢响应和不响应也要测

现场设备不一定每次都秒回。

网关后面挂多个 RTU 从站时，响应慢很常见。

从站工具可以设置响应延迟，比如 1000 ms。然后看主站超时设置是否合理。

如果主站超时 500 ms，从站延迟 1000 ms，那它一定失败。这不是设备错，是主站等得太短。

跳过响应也很有用。它可以模拟设备不回包，看主站会不会卡死、会不会继续下一轮轮询、会不会把错误计数显示出来。

报文窗口是主站测试的证据

从站工具的报文窗口里，RX 表示收到主站请求，TX 表示返回响应。

调主站时，我最喜欢看从站侧报文。

因为主站程序有时候以为自己发的是地址0，实际报文里可能是地址1。

它以为自己发的是 UnitId2，实际报文里可能还是1。

从站侧一看就知道。

如果从站没有 RX，那请求根本没到。继续查 IP、端口、串口线。

如果从站有 RX 但没有 TX，看 UnitId、异常设置、跳过响应设置。

如果从站有 TX 但主站没收到，再查主站超时和链路返回方向。

工作区适合复现问题

如果你遇到一个现场问题，比如某个主站程序遇到异常码就崩，或者某组寄存器值解析错了，可以把从站数据和仿真设置保存成工作区。

下次打开工作区，场景就回来了。

这比口头描述“当时好像某个寄存器是 65535”可靠很多。

CSV / JSON 导入导出也适合批量造数据。比如你想模拟 100 个寄存器的参数表，不必一个个手填。

一个小例子

假设你要测试主站对报警状态的处理。

可以在从站工具里这样设置：

• Discrete Input0 = false，表示无报警
• Holding Register0 = 235，表示当前温度 23.5
• 主站正常读取，界面显示绿色

然后手动把 Discrete Input0改成true。

主站下一轮轮询应该显示报警。

再把从站设置成返回Illegal Data Address。

主站应该显示通讯异常，而不是继续显示旧数据装作没事。

这种小场景很普通，但能测出很多上位机程序的细节问题。

到这里

从站工具最大的价值，是让你主动制造场景。

真实设备只能给你它当前的状态。

从站工具可以给你正常、异常、慢响应、不响应、写入变化、地址错误这些场景。

主站程序能扛住这些场景，到了现场才更稳。