GitHub 项目地址https://github.com/lidecong133/YModbusModbus 现场问题最怕一句话“通讯不通。”这句话太大了。IP 不通叫不通站号错叫不通地址差 1 也叫不通读出来浮点数不对也有人说不通。我更习惯把问题拆开看。下面这些案例都是做 Modbus 调试时很常见的情况。TCP连不上现象很直接主站连接192.168.1.10:502失败。这时还不用讨论功能码和寄存器地址。先看这些设备 IP 是否真的是192.168.1.10电脑和设备是不是同一网段能不能 ping 通端口是不是502设备是否启用了 Modbus TCP设备是否限制只允许一个连接Windows 防火墙或现场网络是否拦截我一般会先用 CLI 做一个最小读取ymodbusread-holding-registers--host 192.168.1.10--port 502--unit-id 1--address 0--quantity 1如果 CLI 也连不上基本就不要先怀疑你的业务程序。链路没通后面的地址和字节序都没意义。TCP连上了但读取超时这个比完全连不上更容易误导人。TCP 连接成功只说明你连到了那个 IP 和端口。它不保证目标设备真的会响应你的 Modbus 请求。尤其是 TCP 转 RTU 网关。你连上的是网关真正干活的是网关后面的 RTU 从站。如果 UnitId 不对或者网关后面的串口参数不对就可能一直超时。我会先查UnitId 是否对应网关后面的设备站号网关后面的 RTU 设备是否在线网关串口参数是否和设备一致功能码是否支持地址是否有效超时是否太短可以扫一个小范围 UnitIdymodbus scan-units--host 192.168.1.10--port 502--start-unit-id 1--end-unit-id 8--function03--address 0--quantity 1不要一上来扫 1 到 247。现场设备慢时这个操作会拖很久还会让人误以为工具卡住。RTU完全没响应RTU 没响应第一反应不要是改代码。先看物理层和串口参数。COM 口是不是选对USB 转 RS485 有没有驱动问题波特率是否一致数据位是否一致校验位是否一致停止位是否一致SlaveId 是否正确A/B 线是否接反总线上是不是有两个主站设备是否需要单独供电或使能通讯RS485 的 A/B 标识不同厂家还不完全统一。遇到完全没响应确认参数没问题后A/B 对调试一下并不丢人现场经常就卡在这里。如果你手里有 USB 转 RS485 和从站工具也可以反过来做个小测试用 YModbus.SlaveApp 开一个 RTU 从站看你的主站能不能读到。这样能把真实设备问题和主站程序问题分开。返回非法数据地址设备返回Illegal Data Address说明它收到了请求只是不接受这个地址。这不是网络不通。常见原因地址差 1功能码选错数量太大跨过有效区域该型号没有这段寄存器手册里的地址是显示地址不是协议地址比如手册写40001 当前值。我会先试03、地址0、数量1。如果手册写“地址 1 当前值”就要判断它到底是协议地址 1还是从 1 开始的人类编号。最稳的做法是找一个设备屏幕上能看到的值。比如屏幕显示温度23.5你就围绕手册里那个温度地址小范围试不要整段扫。数值离谱设备屏幕显示23.5程序读出来16856或4.1E-41。这通常不是通讯失败。设备已经回数据了只是你解释错了。按这个顺序查它到底是整数缩放还是 float如果是整数缩放倍率是多少如果是 float占两个寄存器还是四个寄存器字序是高字在前还是低字在前单个寄存器内部字节序是否特殊很多设备会把23.5存成235然后手册写倍率0.1。这时候用 float 解析只会越看越乱。如果确实是 float再用RegisterConverter试不同 word order / byte order。调通以后把格式写进地址表。不要靠记忆。写入成功但设备没动作这是现场很常见的误会。Modbus 写成功只说明设备接受了这个写请求。它不一定代表设备业务动作已经执行。比如参数写入后还要写保存命令设备必须处于远程模式设备必须停机才能改参数写入值超出业务范围设备内部忽略需要同时写多个寄存器某个使能位没打开我的习惯是写完立即读回。如果读回值没变说明写入没有真正落到设备。如果读回值变了但设备没动作那就看设备业务条件模式、使能、保存、启动位、联锁条件。比如变频器频率写进去了不代表电机就会转。还可能需要运行命令、方向命令、远程控制模式。主站说发了从站说没收到主站工具和从站工具一起用时可以按报文方向对照。主站TX主站发请求RX主站收响应从站RX从站收请求TX从站发响应正常应该是主站 TX 对上从站 RX从站 TX 对上主站 RX。如果主站有 TX从站没有 RX查 IP、端口、串口线、防火墙。如果从站有 RX但没有 TX查 UnitId、异常仿真、跳过响应设置。如果从站有 TX主站没有 RX查主站超时、返回方向链路、响应格式。报文对照能把很多口水仗变成事实。偶尔成功偶尔失败这种问题最磨人。常见原因轮询周期太短一次读取数量太大设备响应慢RS485 总线干扰网关转发不稳定多个主站同时访问USB 转串口质量差处理时不要一上来就疯狂加重试。先把轮询周期放大比如从 100 ms 改到 1000 ms。再把一次读取数量减小比如从 100 个寄存器改成 10 个。然后打开报文看失败时到底有没有响应。如果只是偶发抖动可以加少量重试。如果每次都要靠重试才能成功那根因还在链路或设备响应上。一套比较稳的排查顺序我一般按这个顺序TCP 先查 IP/端口RTU 先查串口/接线查 UnitId / SlaveId查功能码查地址是否差 1查数量是否太大看异常码看原始报文通讯成功后再看数据类型、字节序、比例系数写入成功但设备没动作再查设备业务条件顺序很重要。如果链路都没通就去改字节序是浪费时间。如果设备已经返回异常码还在怀疑网线也会绕远。Modbus 调试不是靠猜是把每一层证据拿出来看。