两个十六位数合成三十二位浮点时，字节顺序和字顺序都可能影响结果。
本文使用树莓派 3、Linux 与模拟 Modbus 从站或离线字节。网关首先负责协议与数据质量转换，不把每次收到字节都当成有效工程量。地址、字节顺序、采样周期与设备身份都应由明确协议定义。
1. 从现象推到机制
Modbus 寄存器本身是十六位数据，跨寄存器的浮点布局由设备约定。ABCD、CDAB 等排列必须依据手册或已知量验证。得到一个看似正常的数值不够，多个点才有助排除错误排列。
图中的四个节点分别表示原始寄存器、字节排列、数值解码、多点核对。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先用已知 IEEE 754 样本离线解码，再对照模拟设备。每一步打印字节，不对真实设备反复写测试值。
1
2
3
4
import struct
raw = bytes.fromhex("3f800000")
value = struct.unpack(">f", raw)[0]
# 此排列演示结果为 1.0，不代表任意设备都使用此顺序
先用模拟设备或离线报文验证，硬件侧按接口手册接入。轮询失败保留异常和最后有效时间，写寄存器不属于默认测试范围，不向未知真实设备发送控制指令。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 交换两个十六位字 | 浮点解释可能完全改变 |
| 某点恰好得到合理值 | 仍需多点检验 |
| 手册定义有符号整数 | 不能按浮点猜测解码 |
对照 1：交换两个十六位字
浮点解释可能完全改变。观察时记录四个原始字节与排列。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：某点恰好得到合理值
仍需多点检验。观察时记录已知输入下的连续对应。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：手册定义有符号整数
不能按浮点猜测解码。观察时记录字段类型与比例关系。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
解析还要检查 NaN、无穷和有效范围。异常数值应保留质量标记，不能直接截断成业务可接受范围。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“手册定义有符号整数”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
