# PDU 的 Modbus 寄存器读出来是乱码？先搞清字节序和浮点格式

头一回接 PDU 的 Modbus 采集，很多人会卡在同一个地方：功能码、地址、波特率全都对，返回数据也有，但解析出来的值是 1.18e-38 这种离谱的数字，或者干脆是个天文数字。

这不是通信问题，是字节序问题。

## 一个真实的现场

去年帮一个集成商调采集，他用 Python 的 `pymodbus` 读电量寄存器，地址 0x2000 开始两个寄存器，拿到的原始值是 `[0x43D4, 0x0A3D]`。他按大端拼成 `0x43D40A3D`，用 `struct.unpack('>f')` 解出来是 424.16，觉得不对——这块表上明明显示 42.4 度左右（那是温度寄存器，被他当电量读了）。

我让他按字序交换再解：`0x0A3D43D4`，`struct.unpack('>f')` 得 42.416。对上了。

## Modbus 里的四种字节排列

Modbus 协议本身只规定了寄存器是 16 位大端，但一个 32 位浮点数占两个寄存器，这两个寄存器谁先谁后、每个寄存器内部字节怎么排，协议没规定死。结果就是四种组合：

| 排列方式 | 寄存器顺序 | 字节顺序 | 典型厂商 |
|---|---|---|---|
| ABCD（大端） | 高字在前 | 高字节在前 | 部分欧美品牌 |
| CDAB（字交换） | 低字在前 | 高字节在前 | 相当常见的 PDU 与电表 |
| BADC（字节交换） | 高字在前 | 低字节在前 | 少见 |
| DCBA（小端） | 低字在前 | 低字节在前 | 少数国产表 |

拿刚才那组数据 `[0x43D4, 0x0A3D]` 举例，四种排法解出来的结果：

| 排列 | 拼接结果 | 解出的浮点值 |
|---|---|---|
| ABCD | 43 D4 0A 3D | 424.16 |
| CDAB | 0A 3D 43 D4 | 42.416 |
| BADC | D4 43 3D 0A | -7.9e+11 |
| DCBA | 3D 0A D4 43 | 0.0342 |

差别非常大。所以拿到一台新设备，先要做的不是写采集逻辑，是确定它用哪种排列。

## 怎么快速判定是哪一种

我的办法是找一个已知值的寄存器。拿电压来试很合适，因为它有明确的物理范围——单相 220 V 上下，三相线电压 380 V 上下。读回来四个字节，把四种排列都试一遍，落在合理区间的那个就是对的。

```python
import struct

def try_all_orders(regs):
    """regs: 两个 16 位寄存器值，返回四种排列的浮点解"""
    hi, lo = regs
    b_hi = hi.to_bytes(2, "big")
    b_lo = lo.to_bytes(2, "big")
    cands = {
        "ABCD": b_hi + b_lo,
        "CDAB": b_lo + b_hi,
        "BADC": b_hi[::-1] + b_lo[::-1],
        "DCBA": b_lo[::-1] + b_hi[::-1],
    }
    return {k: struct.unpack(">f", v)[0] for k, v in cands.items()}

raw = [0x43D4, 0x0A3D]
for k, v in try_all_orders(raw).items():
    print(f"{k}: {v}")
```

跑出来对着看，哪个在几十到几百的量级，哪个就是答案。

## 整型量的缩放系数

除了浮点，PDU 里还有大量用整型表示、带缩放系数的量。比如电压可能存成 `2205`，协议文档里写着「单位 0.1 V」，那就除以 10。

这类量的处理要小心两点：

**其一，留意有符号数。** 功率方向、功率因数在某些实现里会用有符号 16 位表示，读回来是 65535 附近的值时，要转成 `-1` 而不是当成 65535。

```python
def to_int16(v):
    return v - 65536 if v >= 32768 else v
```

**第二，注意量程溢出。** 有的设备电能累计到某个量级会翻转回零，采集端要检测这种跳变，否则报表上会出现负数增量。

| 量类别 | 常见存储方式 | 处理方式 |
|---|---|---|
| 电压、电流 | 32 位浮点，或整型 + 0.1 / 0.01 系数 | 确认系数，别猜 |
| 功率 | 32 位浮点，或有符号整型 | 判断是否为有符号 |
| 电能 | 32 位或 64 位整型，单位 0.1 kWh 或 0.01 kWh | 处理翻转 |
| 开关状态 | 位域（bitmap） | 按位与取值 |
| 告警 | 位域或多寄存器 | 按厂商映射表解析 |

## 寄存器地址的两种编号习惯

这个坑也很常见。文档上写「40001」，实际发送的功能码 03 请求里地址要填 0；文档写「40020」，实际填 19。因为「4xxxx」这个编号体系是从 1 开始数的，而协议里的地址是从 0 开始的。

还有一种是直接给十六进制地址，如 `0x2000`，这种就不用减 1，直接用。

判断方法：如果文档地址是 4 开头且大于 40001，减 40001；如果是 0x 开头的十六进制，直接用；如果文档明确写了「从 0 开始」，也直接用。拿不准的时候，读一个已知值的寄存器试一下就清楚了。

## 一个能直接用的解析小框架

把上面这些整理成一小段可复用的代码：

```python
import struct
from dataclasses import dataclass

@dataclass
class RegDef:
    name: str
    addr: int
    dtype: str          # f32 / u16 / i16 / u32
    scale: float = 1.0
    order: str = "CDAB" # 浮点字节序
    unit: str = ""

def parse(regs: list, d: RegDef):
    if d.dtype == "f32":
        hi, lo = regs[0], regs[1]
        b_hi, b_lo = hi.to_bytes(2, "big"), lo.to_bytes(2, "big")
        m = {
            "ABCD": b_hi + b_lo,
            "CDAB": b_lo + b_hi,
            "BADC": b_hi[::-1] + b_lo[::-1],
            "DCBA": b_lo[::-1] + b_hi[::-1],
        }
        return struct.unpack(">f", m[d.order])[0] * d.scale
    if d.dtype == "u32":
        return ((regs[0] << 16) | regs[1]) * d.scale
    if d.dtype == "i16":
        v = regs[0]
        return (v - 65536 if v >= 32768 else v) * d.scale
    return regs[0] * d.scale

# 用法示例
V_L1 = RegDef("电压L1", 0x2000, "f32", order="CDAB", unit="V")
I_L1 = RegDef("电流L1", 0x2002, "f32", order="CDAB", unit="A")
```

每个寄存器定义一次，后面全部走统一的解析入口。字节序只在一个地方配置，不会因为改了一处忘了另一处。

## 调试的时候先抓原始报文

我调试这类问题的顺序是这样的：先用串口工具或者 `modpoll` 之类的命令行工具抓一帧原始报文，确认通信层通了、返回的字节是什么；然后再进代码层确认解析。跳过前面几步直接看代码，很容易把通信问题和解析问题混在一起查，浪费时间。

抓到的报文大概是这个样子：

```
TX: 01 03 20 00 00 02 C0 1A
RX: 01 03 04 0A 3D 43 D4 6B 2C
```

RX 里 `04` 是字节数，后面 `0A 3D 43 D4` 就是那两个寄存器按传输顺序排列的字节。看到这个，字节序的判断就不需要猜了——传输顺序是 `0A 3D` 在前，说明是字交换（CDAB）。

## 顺带说下精度

采集端做得再仔细，源头读数不准也没意义。我们在宁波做的这批机柜 PDU，计量精度出厂是压在±1% 这一档上，每台在出厂前用标准源比对一遍，记录跟着编号走。现场如果发现读数和钳表对不上，先查钳表本身的误差——普通钳表差个 2% 到 3% 很正常。

厂子是 2014 年办起来的，产品拿的是 CCC、CE（LVD 与 EMC 两部分）和 GS 三张证，体系走 ISO 9001。非标这块接得比较多，图纸 30 分钟出，报价 1 小时内给，方便集成商在方案阶段就把参数定下来。双电源切换实测压在 7 毫秒以内，切换本身不会造成采集中断。

有位在车间做了二十五年的老师傅，他调这种通信问题的方式很有意思：不看代码，先拿万用表量 RS485 的 A、B 两线之间的电压，正常静态应该在 1 V 到 5 V 之间。量完他说一句「线没问题，去看你程序吧」，基本都准。物理层先确认，再往上查，这个顺序省了很多事。

## 收个尾

寄存器读出来是乱码，八成不是协议没通，而是四个字节的排列没搞对。先找一个已知物理量的寄存器，把四种排列都试一遍，确定字节序；再按厂商文档确认每个量的缩放系数和符号；收尾时把这些固化成配置，别散落在代码各处。这三步走完，采集这层基本就不会再出玄学问题了。

**FAQ**

**为什么同一台设备不同寄存器可能用不同字节序？**
理论上不会，但确实见过部分厂商在不同版本固件里混用。稳妥的做法是按寄存器逐个验证，而不是假定全表一致。遇到解析异常时，把该寄存器单独拿出来跑一遍四种排列。

**读回来是 65535 附近的值，就说明错了吗？**
未必，先看协议文档该量是否为有符号数。有符号 16 位的 -1 就是 65535。也可能是设备返回的异常码或无效标记，需要对照厂商的错误码表确认。

**地址到底要不要减 1？**
看文档的编号体系。「4xxxx」这种从 1 开始的编号要减 40001；直接给十六进制地址（如 0x2000）的直接用；文档注明「从 0 开始」的也直接用。拿不准时读一个已知值验证。

**64 位电能值怎么读？**
占四个寄存器，同样存在排列问题，组合更多。建议按厂商给的示例报文反推排列，或者先读低 32 位确认趋势，再处理完整的 64 位拼接与翻转检测。

头一回接 PDU 的 Modbus 采集，很多人会卡在同一个地方：功能码、地址、波特率全都对，返回数据也有，但解析出来的值是 1.18e-38 这种离谱的数字，或者干脆是个天文数字。

PDU 的 Modbus 寄存器读出来是乱码？先搞清字节序和浮点格式

产品经理

大数据

PDU的Modbus寄存器读出乱码，通常是32位浮点数的字节序排列问题，而非通信故障。设备厂商对高字/低字及字节顺序定义不一，常见有ABCD、CDAB、BADC、DCBA四种组合。通过读取已知电压值，用四种排列方式试解，落在合理物理范围内的即为正确格式。同时需注意整型量的缩放系数、有符号数转换及寄存器地址编号习惯。

命令行工具

代码解释

Python

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

PDU 的 Modbus 寄存器读出来是乱码？先搞清字节序和浮点格式-腾讯云开发者社区-腾讯云

PDU 的 Modbus 寄存器读出来是乱码？先搞清字节序和浮点格式

PDU 的 Modbus 寄存器读出来是乱码？先搞清字节序和浮点格式

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐