Modbus 0x10 回包没有寄存器值，怎样验证批量写请求与应答

0x10（十进制 16）的正常应答只有起始地址与写入数量，不含各寄存器值。应核对请求中的数量、两倍字节数和实际负载，再核对五字节应答范围；想确认业务值需要另外回读。

适用版本与输入范围

依据 Modbus Application Protocol V1.1b3（2012-04-26），按下方具体功能章节解释PDU。输入已经剥离RTU地址、CRC或TCP封装，不把封装检查与数据字段解析混为一体。 本文所有输入均为原创合成数据，未接真实设备。

让三种计数保持一致

合成请求从地址 0030 写三个寄存器，数量 0003、byte count 06、实际数据六字节必须同时成立。每个寄存器在 PDU 内固定两字节，高字节在前，所以 0064、00C8、012C 分别形成 100、200、300。这里并不尝试把多个寄存器拼成浮点数，三项都是独立的十六位无符号原始字。客户端在构造请求时就能完成这些检查，无须访问实际设备。

不要把读的数量上限搬过来

0x10 的标准写入数量是 1 到 123，而 0x03 常见最大读取量是 125；两者差异来自请求字段所占空间。核验程序先检查数量，再验证 byte count 恰好等于数量乘二，最后验证整个 PDU 长度。显式负例把字节数改成五，程序不会尝试给最后一个寄存器补零，因为补零会改变写入值，也会把发送端缺字节伪装成正常请求。

应答回显范围而非原值

正常回包 10 00 30 00 03 里，0030 是地址、0003 是数量，没有 byte count 字段，也没有 0064 等原始值。报告保留 registers 作为请求意图，将 feedback_values 设为 null，刻意阻止后续表格把请求值复制成设备反馈。另一条负例回应数量二而请求数量三，即使起始地址相同仍被拒绝，说明客户端不能只凭功能码判断这次响应有效。

把协议完成与业务完成分栏

某个设备可能将寄存器视为目标参数、触发动作或暂存区，这些含义由设备手册定义。一次批量写的正常响应并不自动承诺机械动作同步完成，也不替代业务事务保证。工程交付应分别记录结构核验、写请求范围与后续状态证据；需要回读时还应选正确的数据点和时刻。本程序不连接电源时序器或PLC，既不重发命令，也不判定设备是否真正支持整个写入范围。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 3 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。registers 来自请求；feedback_values=null 表示未提供回读，不是设备返回空值。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到Modbus 寄存器映射基础核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• §6.12 Write Multiple Registers

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。