开发调试 · 更新于 2026-11-05 · 9 分钟阅读

Modbus RTU、TCP 与寄存器怎么读

拿到十六进制报文后，先确定 RTU/TCP 和请求/响应，再解释功能码、长度和寄存器值。本站只分析已有数据，不连接设备、不产生设备控制操作。

打开 Modbus 数据解析

操作步骤

  1. 1. 从已有抓包或日志读取数据

    使用你有权分析的报文副本，先核对是否包含完整 Modbus 帧。串口日志可能还带时间戳或方向标记；不要将这些文字当作十六进制字节输入。工具不连接设备，也不根据解析结果发送报文。

  2. 2. 明确协议与报文方向

    RTU 末尾包含 CRC，TCP 使用 MBAP 头和长度字段，不按 RTU CRC 校验。请求与响应的数据布局也不同；完整报文模式需按来源选择方向，不能让同一段数据反复换模式直到结果“看起来正确”。

  3. 3. 用工具内置示例认识字段

    点击输入区示例，查看站号或 Unit ID、功能码、事务编号、长度与校验结果。以读取寄存器为例，请求描述起始地址与数量，响应主要返回字节数和数据；单独的响应通常不能告诉你完整请求起始地址。

  4. 4. 结合手册解释地址与寄存器

    报文中的地址按零基地址展示。设备手册可能用 40001 等业务编号，这不是可以原样填进报文字段的通用规则。16 位值可有有符号和无符号解释；32 位值还需要明确组合方式与字节顺序。

  5. 5. 用已知值核对 Float32

    在寄存器数据模式输入 3F 80 00 00，ABCD 顺序的 Float32 为 1。换成其他顺序会改变解释。这个示例仅用于理解字节顺序，不说明任何真实设备的寄存器映射；业务倍率、单位和异常值仍以设备文档为准。

  6. 6. 导出时保留解析上下文

    可导出完整 JSON、16 位寄存器 CSV 或 32 位组合 CSV。保留协议、方向、字节顺序和源日志，避免只留下一个脱离上下文的数值。寄存器数量为奇数时，最后一个值无法组成 32 位配对。

实例与预期结果

离线解析已有的读寄存器请求

只粘贴已有报文，不连接设备；地址和数量仅作为协议学习样例。

  • 完整报文
  • Modbus RTU
  • 方向：请求

示例输入 / 准备

01 03 00 00 00 0A C5 CD

预期结果 / 核对项

站号: 1
功能码: 03
零基起始地址: 0
寄存器数量: 10
CRC: 匹配

C5 CD 是该样例的 CRC 字节。CRC 通过不代表业务地址或来源可信。

寄存器 Float32 的已知值

确认输入是寄存器数据，不是完整 RTU/TCP 帧。

  • 寄存器数据模式
  • 32 位字节顺序：ABCD

示例输入 / 准备

3F 80 00 00

预期结果 / 核对项

Float32: 1

不同字节顺序会改变解释；设备倍率和单位不包含在这四个字节中，必须结合设备手册。

遇到问题怎么办

CRC 不匹配或长度异常

可能原因：可能少字节、混入日志时间戳，或 RTU/TCP 及方向选错。

处理方法：按原始日志核对完整帧，选择正确协议和方向；不要修改字节凑出通过结果。

数值很大或很小

可能原因：可能是数据类型、端序、倍率或映射地址不一致。

处理方法：先用手册与已知值核对，只将结果作为离线解释，不据此直接操作设备。

风险与限制

  • 支持的功能码及长度限制以当前工具为准，不支持的功能或私有协议不能强行套用。
  • CRC 通过只代表帧校验匹配，不证明数据来源可信或业务语义正确。
  • 工具展示写入类报文字段只是在解读既有内容，不会执行写入。

常见问题

为什么 TCP 报文没有 RTU CRC？

Modbus TCP 使用不同的封装和长度结构。将 TCP 数据当 RTU 输入会误解头部与校验位置，应先确认协议。

寄存器里出现很大的整数是不是设备坏了？

不一定。可能是有符号解释、Float32、字节顺序、倍率或读取地址不匹配。先用设备手册和已知样本核对，不能只凭数值大小判断设备故障。

能在网站上直接连接设备测试吗？

不能。当前模块只离线解析已有报文或寄存器数据，不连接、不控制、不读写真实设备。

相关阅读