Modbus 0x18 FIFO 回包的两个计数，怎样避免把队列长度读错

0x18（十进制 24）FIFO 正常响应的 Byte Count 和 FIFO Count 都是两字节。Byte Count 包含 FIFO Count 自己的两字节，再加每项两字节的数据，因此三个值对应 Byte Count=8，而不是 6。

适用版本与输入范围

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

不要沿用单字节 byte count 模板

常见读取寄存器响应的 byte count 只有一字节，FIFO 却使用两字节。合成响应 18 00 08 00 03 00 07 00 08 00 09 中，0008 是后续总字节数，0003 才是队列项数。若通用解析器只消费一个 byte count 字节，会把 08 与后面的 00 拼成一个错误计数，整段随即错位。功能码决定结构，不能凭“都是读数”而共享同一套固定偏移。

用空队列验证计数起点

空队列没有数据项，但响应仍需要两个字节的 FIFO Count，所以 Byte Count 应为二而不是零。附件的空队列 PDU 是 18 00 02 00 00，报告 values=[]、fifo_count=0、byte_count=2。这个输入特别适合发现把“有效值字节数”和“整个响应数据区长度”混为一谈的错误；只测三个非零值时，开发者可能用宽松切片读完数据，却没有真正验证计数。

数量和实际长度必须双向相等

标准允许 FIFO Count 最多为 31。程序先检查这个上限，再确认 byte_count=2+2*fifo_count，最后确认收到的完整 PDU 长度为 3+byte_count。显式负例声明三个值，却只留下两个，虽然实际字节与其错误的 Byte Count 相符，仍会因两个计数之间矛盾被拒绝。不能以其中任意一个字段作为唯一真相，更不能将缺少的一项补成零进入历史数据。

队列元素的业务解释另行定义

FIFO 值是十六位数据字，并不自带采样时间、通道号或工程单位。示例输出 7、8、9，仅用于验证结构和顺序，不能推断它们是温度、事件码还是样本序号。读取操作对设备队列是否产生额外业务影响、队列地址含义及刷新行为均需查具体设备文档。脚本没有连接设备，也没有以读取频率估算漏采率；它只证明这些给定字节满足或违反了明示的响应结构。

下载与复跑

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

本次实际运行通过 3 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。byte_count含两字节FIFO Count；values仅是无单位原始数据字，未带时间语义。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

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

一级依据

• §6.18 Read FIFO Queue

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