简要回答

两个 Modbus 保持寄存器包含 32 位，但这些位本身不标识自己的数据类型。同一对寄存器可能是一个无符号整数、有符号整数、IEEE-754 浮点数，或两个无关的 16 位值。此转换器展示一对十六进制寄存器的三种常见 32 位解释，并允许你反转寄存器顺序。

看起来合理的结果只是一个假设。设备寄存器映射表对数据类型、字序、字节序、缩放、单位、哨兵值和可写范围拥有最终解释权。

输入与字序

每个 16 位寄存器以四位十六进制数字输入。接受并自动去除可选的 0x 前缀。例如，十进制 16,712 的十六进制为 4148，而零为 0000。

寄存器 1 在前、2 在后将第一个字拼接在第二个字之前：R1 R2。寄存器 2 在前、1 在后交换两个 16 位字：R2 R1。工具不会交换单个寄存器内的字节，因为 Modbus 以大端字节序传输每个 16 位寄存器。一些厂商文档不一致地使用 ABCD、CDAB、“大端”或“小端”等非正式标签；请在集成笔记中保留实际的字节序列。

转换方法

排列字序后，转换器将八位十六进制数字解析为一个 32 位位模式。然后用三种方式读取同一模式：

  • **无符号整数：**取值范围 0 至 4,294,967,295。
  • **有符号整数：**二进制补码，取值范围 −2,147,483,648 至 2,147,483,647。
  • **IEEE-754 单精度浮点数：**一位符号位、八位指数位和二十三位尾数位。

不应用任何缩放或偏移。如果寄存器映射表指定了 值 × 0.1、值 ÷ 100 或工程偏移，请在确认正确的原始整数值后再应用该规则。

示例分析

寄存器 1 输入 4148，寄存器 2 输入 0000，保持“寄存器 1 在前、2 在后”。原始序列为 0x41480000。作为无符号或有符号 32 位整数读取，值为 1,095,237,632。作为 IEEE-754 浮点数读取，值为 12.5。

该浮点数通常是有效的解释，但不能作为证明。请与已知工况或厂商示例进行确认。如果设备当前应读数 12.5 °C 且寄存器映射表声明该字序为浮点数，则证据一致。如果映射表声明为缩放系数 0.01 的整数，则相同的位模式含义完全不同。

切换为“寄存器 2 在前、1 在后”得到 0x00004148，这说明为什么错误的字序假设会产生技术上有效但毫无意义的数值。

寻址与其他限制

此工具不读取设备、不验证 Modbus 功能码、不解析地址记法。文档可能将第一个保持寄存器标记为 40001，而协议请求使用偏移量 0；该寻址约定与值转换是分开的。

转换器处理由两个寄存器组成的一个 32 位值。它不解码 16 位值、64 位整数或双精度浮点数、字符串、packed 位、BCD、厂商特定日期格式、NaN 处理策略或混合字节和字序的排列。它也不应用单位、缩放、范围检查、报警含义或写入安全保护。未经设备特定验证流程，切勿将转换值用作写命令。

隐私与分享

寄存器值和所选字序在本地处理，并在转换后写入当前 URL，使位模式可以分享给同事。如果寄存器值本身属于机密，请勿使用生产数据。不请求任何设备地址、网络连接或凭据。

复制命令和 JSON、CSV、Markdown 导出均在浏览器中生成。IoT 01 不会接收任何输入的寄存器值或结果。

常见问题

为什么浮点数看起来荒谬而整数看起来合理？

映射表可能指定了整数、不同的字序或缩放系数。仅凭合理性无法在其中做出选择——请检查寄存器定义并与已知值对比。

Modbus 是否定义了 32 位字序？

应用协议定义了 16 位寄存器，但没有为每个多寄存器厂商值提供统一的解释方式。设备文档必须指定如何由字组成更大的值。

可以粘贴十进制寄存器值吗？

不能。请先将每个无符号 16 位寄存器转换为四位十六进制数字。该字段刻意使原始字节模式显式化。

相关指南

参阅将 Modbus 设备接入 MQTT了解地址规范化、缩放、质量、时间戳以及围绕寄存器数据的安全消息边界。