Modbus TCP Gateway 对离线 Slave ID 返回 0，如何可靠检测？

无效地址探测只能作为辅助判断

读取无效寄存器并等待 02 Illegal Data Address，可以用来验证特定设备和网关的行为，但不能作为通用、可靠的离线检测方法。

如果网关把“目标设备未响应”转换成与正常读取完全相同的成功报文，客户端就无法仅凭这份报文区分真实的 0 和补出来的 0。更换客户端库、增加重试或调整超时，都无法恢复网关已经丢弃的信息。

可靠的检测至少需要一项可信依据：网关明确报告下游通信失败，提供每个 Slave ID 的通信状态，或者由设备提供可验证来源和新鲜度的数据。缺少这些条件时，应用应将读数标记为“未知”或“数据无效”，不能当作正常状态使用。

排查时应先通过抓包确认：网关确实返回了成功的全零响应，还是 EasyModbus 将异常响应解析成了零。后续修复取决于这个结果。

为什么读取无效地址不能证明设备在线

9999 不一定是无效寄存器

Modbus 寄存器起始地址字段的范围是 0x0000 至 0xFFFF，因此 9999 本身是合法的协议地址。设备是否实现了这个地址，要查寄存器表，还要核对手册中的地址与 API 使用的零基偏移是否一致。

02 Illegal Data Address 表示请求的地址或地址组合不被接受，不能据此判断设备是否健康。Modbus 应用协议规范

即使当前设备对该地址返回 02，更换型号、修改映射或升级固件后，也需要重新验证。

异常响应可能由网关生成

有些网关会自行检查地址映射，即使 RTU 设备已经断开，也可能直接返回 02。

只有确认请求实际到达目标设备，且异常响应来自该设备，才能据此判断“设备当时能够响应”。这仍然不能证明传感器的测量功能正常，也不能证明前一次读到的 0 是新鲜数据。

无效地址读取成功同样不能直接证明设备离线。也可能是该地址实际有效、网关将它映射到了其他位置，或网关返回了缓存数据。

只在读到 0 时探测会漏检

问题中还出现了“返回上一个在线 Slave ID 的数据”的情况。这份数据可能是 1，也可能是其他正常范围内的值。

通信有效性检查应独立于业务值执行，不能只放在 registers[0] == 0 分支下。

第一步：抓包确认网关返回了什么

使用 Wireshark 查看 TCP 流时，可以先设置过滤条件：

tcp.port == 502

分别记录设备在线、设备断开，以及查询不存在的 Slave ID 时的请求与响应。

例如，事务号为 0x0001、Unit ID 为 5，请求读取一个保持寄存器时，成功返回 0 的响应可以是：

00 01 00 00 00 05 05 03 02 00 00

网关报告目标设备未响应时，异常响应可以是：

00 01 00 00 00 03 05 83 0B

其中，0x83 是功能码 0x03 对应的异常功能码，0x0B 表示 Gateway Target Device Failed to Respond。0x0A 表示网关无法分配通信路径，与 0x0B 的含义不同。Modbus 异常响应定义

检查时还应核对：

• Transaction Identifier 是否匹配当前请求。
• Unit Identifier 是否对应目标 Slave ID。
• 功能码、MBAP 长度和数据字节数是否正确。
• 是否存在前一次请求的迟到响应。

事务号用于匹配请求与响应，Unit Identifier 用于网关后的设备路由。两者匹配，只能说明报文对应当前事务，不能保证网关内部没有复制旧数据。Modbus TCP/IP 实现指南

检查 EasyModbus 的解析行为

EasyModbus 上游仓库中的一份 ReadHoldingRegisters 实现，只对 0x83 异常响应中的 01、02、03、04 做了显式处理，随后读取寄存器数据，没有完整处理其他异常码。遇到 83 0B 时，它可能继续从预先清零的缓冲区取数，最终得到 0。

同一份实现还通过单次 NetworkStream.Read 接收响应。TCP 是字节流，单次读取不保证能拿到完整的 Modbus ADU，因此还要检查客户端是否接收了完整报文，以及是否验证了长度。EasyModbus ModbusClient.cs 源码

实际安装的版本是否存在这些问题，需要结合所用的包、对应源码和抓包结果判断：

第二步：让网关保留下游通信失败的信息

确认问题来自网关后，查看手册中的工作模式和超时处理设置。先弄清它是按请求转发的协议网关，还是自行轮询 RTU、对外提供缓存寄存器的采集网关。

如果型号支持，优先采用以下配置：

• 下游无响应时返回 0x0B。
• 关闭超时补零，以及采集失败后仍以成功状态返回旧值的功能。
• 读取每个 Slave ID 的通信状态、最后成功采集时间或数据质量。
• 为缓存数据设置有效期，过期后明确标记为无效。

具体能否这样配置，要以产品提供的功能为准。

客户端的响应超时应覆盖网关的串口等待、重试和排队时间。但只要网关及时返回成功报文，客户端就不会因 RTU 设备离线而超时。调整 ConnectionTimeout 无法识别成功响应中的虚假数据。

如果网关没有下游状态接口，又始终将通信失败作为正常数据返回，就需要升级固件、更换网关，或改用能直接观察 RTU 通信结果的连接方式。

第三步：有条件时验证设备身份和数据新鲜度

设备提供相关寄存器时，可以增加以下检查。每种检查能解决的问题不同：

固定型号编号通常无法区分同型号设备，业务值长时间不变也不能作为离线证据。对于正常值可能一直为 0 的点位，应观察独立更新的心跳或采样计数器。

新鲜度阈值应根据设备更新周期、网关采集周期和通信延迟确定。应用收到 TCP 响应的时间，只能说明何时收到了网关数据。

如果设备允许设计专用诊断区，可以使用由设备处理的请求序号或挑战响应。必须确认该区域没有控制副作用，并验证网关不会仅通过写入缓存就完成读回。不要随意向业务寄存器写值来测试设备是否在线。

C# 示例：修正无效地址探测的判断

原代码中的异常类型也需要核对。在前述 EasyModbus 源码中，功能码 0x03 收到异常码 02 时，抛出的是 StartingAddressInvalidException，不能直接假定 ModbusException 能捕获它。EasyModbus 异常映射实现

如果仍需保留无效地址探测，可以让它只报告本次观察到的结果：

using System;
using System.IO;
using System.Net.Sockets;
using EasyModbus;
using EasyModbus.Exceptions;

public enum ProbeResult
{
    IllegalAddressResponse,
    UnexpectedSuccess,
    CommunicationFailed
}

public static class SensorProbe
{
    // 调用方应已连接，并保证同一客户端上的请求串行执行。
    // confirmedInvalidAddress 必须按设备手册确认。
    public static ProbeResult ProbeInvalidAddress(
        ModbusClient client,
        byte slaveId,
        int confirmedInvalidAddress)
    {
        client.UnitIdentifier = slaveId;

        try
        {
            client.ReadHoldingRegisters(confirmedInvalidAddress, 1);
            return ProbeResult.UnexpectedSuccess;
        }
        catch (StartingAddressInvalidException)
        {
            return ProbeResult.IllegalAddressResponse;
        }
        catch (TimeoutException)
        {
            return ProbeResult.CommunicationFailed;
        }
        catch (IOException)
        {
            return ProbeResult.CommunicationFailed;
        }
        catch (SocketException)
        {
            return ProbeResult.CommunicationFailed;
        }
    }
}

这些结果都不足以直接判断 Alive 或 Offline：

• IllegalAddressResponse：收到了地址异常，仍需确认异常来源。
• UnexpectedSuccess：读取成功，与预期不符，应检查地址和网关行为。
• CommunicationFailed：本次通信失败，原因可能是网络、串口链路或目标设备无响应。

未列出的异常由上层继续记录和分类，避免将参数错误、设备错误等一律记为 Network Failure。不同 EasyModbus 版本的异常类型和映射可能不同，需要按实际版本调整。

轮询结果应同时保存数值和质量

应用层至少应区分以下状态：

可以保留最后一次可信读数用于显示，同时保存它的采集时间和过期状态。不能因为网关又返回了一次成功报文，就刷新该读数的有效期。连续失败次数和恢复条件可用于抑制短暂抖动，阈值应根据现场时序确定。

共享 ModbusClient 时，从设置 UnitIdentifier 到完成读取的整个过程都必须串行执行。多个线程同时切换 Slave ID，会让数据归属更难排查。

只有验证了来源和新鲜度，才能将读到的 0 作为“传感器正常”的依据。网关信息不足时，应保留“未知”状态，无效地址探测无法补足这些信息。

备注：内容仅供参考。