Modbus 读 13 个线圈为什么回两字节：怎样还原低位优先的状态表

13 个线圈需要两个数据字节。第一路位于第一个数据字节的最低位，最后一个字节只取请求数量以内的位，剩余高位应补零；不能按通常的二进制书写顺序从左往右分配通道。

适用版本与输入范围

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

先把请求数量带进响应解析

响应只有字节数，没有再次携带线圈数量。附件把 quantity=13 与 PDU 01 02 4D 13 配成一条输入：01 是功能码，02 是两字节负载，后面的 4D 和 13 才是状态。若只拿回包而没有请求上下文，解析器无法区分第二字节最后三个零到底是有效关闭状态还是填充位。因此工程日志应保留请求数量、起始地址和对应响应，而不是只截图一串十六进制。

按字节内低位向高位展开

对第 i 路使用字节下标 i//8 与位下标 i%8。4D 的低位序列是 1、0、1、1、0、0、1、0，13 的低五位是 1、1、0、0、1。程序输出的 states 只含这十三项，padding_bits=3 解释被排除的三位。这里的顺序说的是一个字节内部如何放置离散状态，与跨寄存器浮点数的字序不是同一个问题，不能套用交换两个寄存器的修复办法。

把长度与尾位分成两道检查

所需字节数为向上取整 quantity/8，而完整响应长度应为功能码一字节、byte count 一字节加负载。先检查 byte count，再检查实际收到的数据长度，最后才展开位。显式负例 01 02 4D 93 长度正确，但末字节最高位被置一；它位于十三路之外，程序报“尾填充位非零”。另一条截短负例则在结构检查阶段拒绝，两种问题不能都显示为设备关闭。

状态表与实体通道仍需另行对照

离线报告证明这些字节怎样转换成位序列，并不证明第零项对应现场的第一只继电器。把 states 下标与厂商点表中的协议地址绑定，再另外核对继电器常开、常闭或输入反相约定。连续十三路的合成状态特意有多种组合，避免全零、全一掩盖顺序错误。若真实回包不符合尾位要求，应保存原始字节与型号版本，不能悄悄截断之后宣称设备报文完全合规。

下载与复跑

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

本次实际运行通过 4 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。states 是请求顺序内的状态，不是物理继电器编号；padding_bits 是被排除的高位数。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

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

一级依据

• §6.1 Read Coils

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