Modbus 0x17 同时读写时，怎样分清两段数量与执行先后

0x17（十进制 23）请求携带独立的读地址、读数量、写地址和写数量。规范要求先执行写操作再读，因此读写范围重叠时应按更新后的寄存器模型解释；不能把两段数量合成一段。

适用版本与输入范围

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

按四个双字节字段拆请求

附件从地址 1 读两项，同时从地址 2 写三项，PDU 的字段顺序依次是读地址、读数量、写地址、写数量、写字节数和写数据。读数量允许 1 到 125，写数量允许 1 到 121，不能把两者都设成普通批量写的 123。程序先完整拆出四个字段，再核对写负载是否等于写数量乘二，防止游标提前进入数据区造成字段混淆。

用重叠范围观察执行先后

初始合成存储区为 10、20、30、40、50、60。写操作把地址 2 到 4 改成 99、100、101，随后读取地址 1 到 2，结果必须是 20、99。如果错误地先读再写，就会得到 20、30。这个案例的读写范围刻意相交，使执行顺序可以被断言验证；两个互不相交的范围即使算法顺序反了也可能返回同样结果，无法发现实现问题。

响应读取量不等于写入量

真正的正常响应携带读取的数据，它的 byte count 应由读数量推导，而不是复用请求里写数据的字节数。本附件重点在请求解析与本地寄存器模型，将 read_values 作为规范顺序的演算结果，不伪装成实际网络回包。写数据长度显式负例把三项写入只配四个字节，程序在修改模型前就拒绝，避免半更新后才发现请求不完整。

不延伸为整个业务的事务保证

先写后读规定的是这个功能的寄存器访问顺序，不意味着外部执行器在同一时刻完成，也不意味着几个寄存器对应的应用动作具备跨设备事务性。工程上仍须查设备如何映射地址、是否支持该功能、寄存器是否允许访问。附件 memory 只是六项列表，越界检查也只是防止误读该演示模型，不能当作真实设备完整地址空间。适合用它验证客户端编解码，再独立安排现场联调。

下载与复跑

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

本次实际运行通过 2 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。read_values来自先写后读的本地模型；after仅为合成寄存器列表，不是设备回读。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

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

一级依据

• §6.17 Read/Write Multiple Registers

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