Modbus RTU串口通信实战：从接线到数据解析全攻略

先说结论：这次项目里我把 Modbus RTU 串口通信从接线到上位机数据解析完整走了一遍，踩了不少坑，也把协议层、调试工具、代码实现的细节梳理清楚了。这篇文章就当作一份项目日常小结，把我实际用到的知识、排查过的故障、以及最终能直接抄作业的配置方式都写出来，给同样在搞仪表采集、PLC 通信、单片机串口对接的朋友做个参考。

先说清楚这篇文章适合谁看：如果你要做上位机读取传感器、电表、温控仪等 Modbus RTU 从站设备的数据；如果你在单片机上要自己实现一个 Modbus RTU 从站或者主站；如果你已经在调 Modbus，但经常被 CRC 错误、高低字节颠倒、地址偏移这些问题搞得头大，那这篇内容基本就是按你遇到的场景写的。文章不绕弯子，直接从实际项目出发，按“协议结构、调试工具、代码实现、排障记录”四个板块展开，能省掉你大量翻手册和试错的时间。

1. 项目概述与 Modbus RTU 协议结构拆解

1.1 为什么工业现场都在用 Modbus RTU

Modbus RTU 诞生于上世纪 70 年代末，到现在依然是工业自动化、楼宇自控、能源管理领域应用最广的串行通信协议之一。它能在这么多年里活下来，核心原因就三个：简单、开放、可靠。

简单体现在报文格式非常紧凑，一帧数据就十几个字节，对单片机的 Flash 和 RAM 占用极低。开放体现在协议规范公开，Modbus 官方文档免费下载，任何厂商都能实现，不需要授权费。可靠体现在它的主从问答机制很严格，一主多从，每次通信都由主机发起，从机被动响应，不会出现多设备同时往总线上发数据的冲突问题。

我用一个生活化类比帮你理解主从机制：Modbus 网络就像教室里的课堂提问，老师（主机）点某个学生的名字（从站地址），被点到的学生才允许站起来回答问题（返回数据），其他学生保持安静，不能随便插话。这种机制天然避免了总线冲突，非常适合 RS485 半双工通信这种“一对多、共享一条线”的物理拓扑。

1.2 物理层与链路层：RS485、AB线、终接电阻

Modbus RTU 最常见的物理载体是 RS485，这是大家在项目里最容易忽略的坑区。RS485 是一种差分信号传输标准，用一对双绞线传输电压差来表示逻辑 0 和 1。A 线（通常接 D-）和 B 线（通常接 D+）之间的电压差在 +2V 到 +6V 表示逻辑 1，在 -2V 到 -6V 表示逻辑 0。

接线时有几个要点按重要性排序：

• 必须用双绞屏蔽线，屏蔽层单端接地，不能两端同时接地，否则会形成地环路电流烧毁收发器。
• 总线两端需要各接一个 120Ω 终端电阻，用于吸收反射信号。总线长度超过 100 米或者波特率调到 57600 以上不掉线的项目我都试过，不终端电阻大概率会出现时通时不通的诡异现象。
• 每个设备的 A/B 线必须从总线上“串”过去，不能单独拉很长的分支线，分支长度尽量控制在 20 厘米以内，否则分支处也会形成信号反射。
• 共地问题经常被忽视：多个 485 设备如果供电电源不共地，A/B 线的电平参考点就不一致，严重时通信直接失败甚至损坏接口芯片。项目里最好把 485 设备的 GND 全部汇总接到同一个电源地上。

波特率建议先从 9600 开始调。9600 是工业现场最通用的默认值，兼容性最好，抗干扰能力也强。等到通信稳定之后，再根据实际情况逐步提高波特率，比如调到 19200 或 38400，但每调高一档都必须重新验证长时间运行稳定性，不能只看短时间测试通过就上线。

1.3 协议帧结构：地址码、功能码、数据段与 CRC 校验

Modbus RTU 在串行链路上传输的数据帧严格遵循下面的结构，每一帧由以下四个部分组成：

帧与帧之间还有严格的时间间隔要求：一帧内部各字节之间的时间间隔不能超过 1.5 个字符时间，两帧之间的间隔必须大于等于 3.5 个字符时间。这个要求在实际工程项目里非常重要，后面讲代码实现时我会专门展开说。

从站地址决定了总线挂载的设备上限，一个 RS485 总线上最多能挂 247 个从站设备，也就是说在一条 485 线上，每个设备必须编一个独特地址，不能重复。项目里如果遇到设备不响应，先查地址是不是写错了，这个概率超过 50%。

2. 功能码、寄存器模型与数据编码规则

2.1 Modbus 寄存器模型与功能码对照

Modbus 协议把设备的数据模型分为四个区域，每个区域支持不同的读写操作。理解这张表是看懂所有 Modbus 项目的基础，我把它整理成最常用的对照表：

日常项目中见的最多的是 03H（读保持寄存器）和 06H/10H（写保持寄存器）。大多数智能仪表、温控器、变频器的运行参数（电流、电压、频率、温度）都映射在保持寄存器区域，通过 03H 功能码读取。

功能码选择有个细节值得留意：很多设备厂商把一些只读的测量值也放在保持寄存器区域，而输入寄存器区域反而是空的，或者只放少量原始量。我拿到一款新的 Modbus 设备时，习惯性做法是先用 03H 和 04H 分别从同一地址读一遍，对比返回值差异，这样能快速判断厂商到底把数据映射到哪个区域了。

2.2 寄存器地址偏移问题：协议地址与报文地址的区别

这是项目中坑最多的一个点，必须单独拿出来讲。

Modbus 协议规范里，保持寄存器的地址是 40001 到 49999，输入寄存器是 30001 到 39999，线圈是 00001 到 09999。但实际在报文的数据段里，寄存器地址字段通常只有 16 位，也就是 0 到 65535，而且用的是从 0 开始的偏移地址。

举个例子：设备手册上写“电流值保存在保持寄存器地址 40003”，那么这个“40003”是完整寄存器编号，转换成报文里的实际地址时要减去 40001，得到偏移地址 2（注意：0 对应 40001，1 对应 40002，2 对应 40003）。如果你直接把 40003 填到报文的寄存器地址字段里，那就是地址偏移错误，从站会返回非法数据地址异常码（02H）。

还有一部分厂商手册直接写十六进制地址，比如“电流值寄存器地址 0x0002”，这通常就是报文里直接使用的偏移地址，不用再转换。不同手册、不同软件的表达方式完全不同，所以在写程序、用调试工具之前，先看清楚手册里的地址表到底是以哪种方式给的。Modbus Poll 软件里的地址填写框和功能码选择组合起来也容易混淆，我后面实操部分会详细演示。

2.3 数据编码与字节序问题

Modbus 保持寄存器是 16 位（2 字节）一个单位，但项目里的数据往往不止 16 位。比如电表的电能累计值、流量计的累积流量，经常是 32 位浮点数或者 32 位无符号整数。大数拆成两个 16 位寄存器存放时，就有了字节序和字序的问题。

常见的数据排列方式有四种：

• 大端字序大端字节序：高字在前，高字节在前，类似网络字节序
• 大端字序小端字节序：高字在前，低字节在前
• 小端字序大端字节序：低字在前，高字节在前
• 小端字序小端字节序：低字在前，低字节在前

实际项目中，国内厂商最常用的组合是把 32 位整数或浮点数按“低字在前”的方式存放，也就是小端字序，比如一个浮点数的高 16 位放在地址加 1 的寄存器里，低 16 位放在地址加 0 的寄存器里。但每个厂商都可能不一样，没有统一标准。

遇到这种问题，最快的方式是看手册里有没有提供数据格式说明，没有的话就直接用工具实测：写入一个已知值（比如频率 50.00Hz），然后用 Modbus Poll 按不同字节序组合解读，看哪个组合能显示正常数字。我通常直接在调试工具里切换“AB CD”和“CD AB”两种顺序观察，比在代码里反复试错效率高得多。

3. 项目实操：从总线接线到上位机数据上屏全流程

3.1 硬件准备与接线验证

我这边的项目场景是：需要用 PC 上位机采集 3 台支持 Modbus RTU 协议的智能电表的数据（电压、电流、功率、电能等参数），电表之间用 RS485 手拉手串联，最后通过 USB 转 485 模块接入电脑 USB 口。

具体硬件清单如下，基本都是市面上通用的型号：

接线完成后，先用万用表确认 A/B 线没有短路或反接。485 总线空载时，A/B 之间的电压差应该在 5V 左右（取决于驱动芯片型号，通常 2V 到 7V 都算正常），如果测出来电压接近 0，说明总线处于不确定状态，大概率是接线有问题或者设备没上电。

把 USB 模块插上电脑后，设备管理器里确认串口号和 CH340 驱动是否正常安装，这一步经常被忽略，驱动不对后面什么工具都连不上。然后在设备管理器里把串口的波特率等参数设置为与电表一致，默认 9600-8-N-1。

3.2 用 Modbus Poll 快速验证从站通信

Modbus Poll 是调试 Modbus 主站功能最常用的工具，网上能找到试用版，功能完全够用。它最大的价值是能让你在写任何代码之前，先确认“从站设备到底能不能通信、地址对不对、数据格式怎么解析”。

打开 Modbus Poll 之后，操作流程是这样的：

1. 点击菜单栏 Connection -> Connect，弹出连接设置窗口。
2. 选择串口模式（Serial Port），填写串口号 COM3、波特率 9600、数据位 8、校验位 None、停止位 1。
3. 设置从站地址 Slave ID 为 1，功能码 Function 选 03 Read Holding Registers。
4. 起始地址填 0，寄存器数量填 10，然后点 OK。

如果一切正常，界面会以表格形式显示从站返回的寄存器数值。看到这些数据就说明物理链路和协议链路全通了，接下来要做的工作只是把这些数据搬到你自己的上位机程序里。

这里要特别提醒一下：Modbus Poll 里虽然要求填从站地址（Slave ID），但起始地址字段填的是报文偏移地址，不是完整寄存器编号。比如你想读 40003（完整编号），起始地址就填 2，功能码选 03H。填成 40003 的话，从站会直接返回非法地址异常。

调试通之后，再逐步测试不同的功能码和寄存器范围，把设备手册里的寄存器表全部验证一遍，标记出哪些地址能用、哪些数据格式是什么样的。这个过程虽然看起来繁琐，但能大大降低后续代码开发的调试成本。

3.3 用 Modbus Slave 模拟从站测试代码

开发上位机的时候，设备不一定总在现场，这时可以用 Modbus Slave 软件在电脑上模拟一个从站设备。它和 Modbus Poll 是同一家公司出的，一个是主站模拟器，一个是从站模拟器，搭配起来非常顺手。

Modbus Slave 里设置好从站地址、功能码、寄存器地址范围，就可以把这台电脑当成一个虚拟设备。上位机程序通过串口连上这个虚拟设备，就能在你自己的电脑上完整测试采集逻辑。

我在项目里用这套组合做了完整的流程测试：Modbus Slave 模拟电表返回数据和异常码，Modbus Poll 模拟上位机发送请求，两者同时对着同一个虚拟串口对测试。接线方式是用虚拟串口软件把两个虚拟串口配对，程序从 COM4 发出请求，Slave 在 COM5 上响应。这种方式在公司没有真实设备的情况下，就能把整个协议栈、超时重试、数据解析逻辑提前验证一遍，上线时问题会少很多。

3.4 上位机数据解析编码：高低字节的实战处理

从 Modbus 报文里读到的原始寄存器值是 16 位无符号整数，但真实物理量可能是有符号数、浮点数、32 位整数，或者带倍率缩放。数据解析的关键就是把原始寄存器值换算成真实物理量。

最简单的场景是 16 位无符号整数加倍率。比如电表手册写“电压寄存器值乘以 0.1 就是实际电压值”，原始读回的寄存器值是 2315，实际电压就是 231.5V。

16 位有符号数稍微麻烦一点，常见的是温度数据。温度可能为负，所以寄存器以补码形式存放有符号数。比如原始值是 0xFF38，按无符号理解就是 65336，但按有符号数理解就是 -200，乘以倍率后是 -20.0 摄氏度。代码里要做一步数据类型转换，Java/C 里把无符号 short 强转成有符号 short 再乘系数就行。

32 位数据是真正的坑。假设一个 32 位无符号整数存放在两个连续的 16 位寄存器里，寄存器地址分别为 0 和 1，地址 0 存放低 16 位、地址 1 存放高 16 位。如果我把它拆成两个 16 位整数分别乘系数，那得到的结果完全是错的。正确做法是先把两个寄存器值拼成一个 32 位整数，再换算：

# Python 示例：寄存器 0 是低 16 位，寄存器 1 是高 16 位 lo = regs[0] # 低 16 位 hi = regs[1] # 高 16 位 value32 = (hi << 16) | lo

如果高 16 位寄存器里有符号位，还要判断正负：

if value32 >= 0x80000000: value32 -= 0x100000000 # 转为负数

解析浮点数时就涉及到 IEEE 754 单精度浮点的内存布局。Python 里可以用 struct 模块：

import struct # regs[0] 是低 16 位，regs[1] 是高 16 位 raw = struct.pack('<HH', regs[0], regs[1]) # 小端字序 value = struct.unpack('<f', raw)[0]

注意struct.pack('<HH', ...)里的<表示按小端字节序打包，H表示 16 位无符号整数。如果设备的字序是大端（高字在前），就要把 regs[0] 和 regs[1] 互换，字节序也要相应调整。写代码前先确认设备的字节序规则，或者用之前说的调试工具实测确认。

高低位转换是 Modbus 开发中被问得最多的问题，我这里再给一个通用处理思路：无论设备手册怎么描述，你先在 Modbus Poll 里读一组已知值，然后用 Python 或 C 写个小工具，把这 4 种排列组合（大小端字序 × 大小端字节序）全部解一遍，看看哪个结果和真实值匹配。这个方法比我在这篇文里给你列十个表格都管用，一次实测胜过十次猜测。

4. 代码实现要点：轮询、帧解析与 CRC 校验

4.1 主站轮询策略设计

Modbus RTU 主站和多个从站通信时，要有一个合理的轮询调度策略。最简单的是顺序轮询：先请求从站 1，等它响应（或超时），然后再请求从站 2，依次循环。但这里有一个核心性能问题需要权衡：每个从站的等待超时时间直接决定了轮询一圈的周期。

如果总线上有 10 个从站，每个从站超时设置 200ms，那么一轮轮询最坏情况下要 2 秒。对于实时性要求高的场景，这个周期可能偏长。优化方向有两个：

• 缩短超时时间：如果设备响应速度快（通常几十毫秒内就会响应），超时可以压到 50-100ms。
• 对响应慢的从站单独设更长的超时时间，不能一刀切。

我把轮询过程做成一个状态机，每个从站维护一个超时计数器，数据更新成功就记录时间戳，超过指定周期（比如 1 秒或 5 秒）没更新就标记为离线。

另外，写操作和读操作不要混在同一个轮询周期里。写操作（比如设定值下发）频率要低一些，建议在读操作全部完成后再处理写操作队列。这样如果写操作把某些从站搞挂了（比如地址配置错误），不至于影响整体的数据采集循环。

4.2 单片机/上位机的帧接收状态机

帧接收是 Modbus RTU 代码实现的核心难点，尤其是单片机串口中断里接收不定长数据帧时，如果没有状态机，很容易被拆包、粘包问题搞崩。

我常用的做法是：在串口中断里逐字节接收，配合一个定时器（或系统 tick）来判断帧间间隔。具体状态机逻辑如下：

• 状态 IDLE：收到第一个字节，保存到缓冲区，启动帧超时定时器，切换到 RECEIVING 状态。
• 状态 RECEIVING：每收到一个字节，都刷新帧超时定时器（重置为 0），并存入缓冲区。如果缓冲区满，直接丢弃整个帧并回到 IDLE。
• 超时判断：当帧超时定时器超过 3.5 个字符时间（可由波特率计算）时，认为一帧数据接收完毕，解析缓冲区并回到 IDLE。

3.5 个字符时间的计算方式：

3.5 字符时间 = 3.5 × 11 / 波特率

以 9600 波特率为例，一个字节包含 1 个起始位、8 个数据位、1 个停止位（无校验时），共 11 位，所以：

3.5 × 11 / 9600 ≈ 4.0ms

如果配置了偶校验或奇校验，每个字节多 1 位，共 12 位，那时间就是：

3.5 × 12 / 9600 ≈ 4.375ms

定时器中断周期取 1ms，那么帧超时判断阈值设为 5ms 比较合理（9600 波特率时）。波特率越高，阈值越小，但尽量不要低于 2ms，避免串口处理抖动导致误判。

状态机代码示例（伪代码，适用于单片机场景）：

#define RX_BUF_SIZE 256 uint8_t rx_buf[RX_BUF_SIZE]; uint8_t rx_len = 0; uint8_t rx_state = RX_IDLE; uint16_t frame_timer = 0; void uart_rx_isr(uint8_t byte) { if (rx_state == RX_IDLE) { rx_len = 0; rx_buf[rx_len++] = byte; rx_state = RX_RECEIVING; frame_timer = 0; } else if (rx_state == RX_RECEIVING) { if (rx_len >= RX_BUF_SIZE) { rx_state = RX_IDLE; // 缓冲区溢出，放弃本帧 rx_len = 0; return; } rx_buf[rx_len++] = byte; frame_timer = 0; } } // 1ms 定时器中断里调用 void timer_1ms_isr(void) { if (rx_state == RX_RECEIVING) { frame_timer++; if (frame_timer >= FRAME_TIMEOUT_MS) { // 一帧接收完毕，交给协议解析层 modbus_parse_frame(rx_buf, rx_len); rx_state = RX_IDLE; rx_len = 0; } } }

这里要注意：帧间超时定时器必须在每次收到新字节时清零，否则一个正常帧内部稍微有一点延迟，就会被误判成帧边界，导致解析失败。

4.3 CRC16 校验实现与常见误区

Modbus RTU 使用 CRC16 校验，多项式是 0x8005（x^16 + x^15 + x^2 + 1），初始值为 0xFFFF，计算结果低字节在前发送。CRC 计算的典型实现如下：

uint16_t modbus_crc16(const uint8_t *data, uint16_t length) { uint16_t crc = 0xFFFF; for (uint16_t i = 0; i < length; i++) { crc ^= data[i]; for (uint8_t j = 0; j < 8; j++) { if (crc & 0x0001) { crc = (crc >> 1) ^ 0xA001; // 反思多项式 0x8005 -> 0xA001 } else { crc >>= 1; } } } return crc; }

常见误区有两个：

• 有人说多项式是 0xA001，没错那是反转后的多项式。原始多项式 0x8005 在左移算法里用，0xA001 在右移算法里用，两种写法都对，别混淆就行。
• 发送时 CRC 低字节在前，高字节在后，也就是先发送 crc & 0xFF，再发送 crc >> 8。如果你搞反了，从站会返回 CRC 错误异常码（03H）。

验证 CRC 计算是否正确有个快速方法：用计算好的 CRC 去校验整帧数据（包括原数据 + CRC），得到的余数一定是 0。开发时可以做个断言测试：

uint8_t test_frame[] = {0x01, 0x03, 0x00, 0x00, 0x00, 0x0A, 0xC5, 0xCD}; uint16_t crc = modbus_crc16(test_frame, 6); // crc 应该等于 0xCDC5，低字节 0xC5 在前，高字节 0xCD 在后

4.4 异常码处理：从站返回的故障信号

当请求的地址不存在、功能码不受支持、数据值非法时，从站会返回异常响应帧。异常帧的结构是：从站地址 + 功能码（最高位置 1，即原功能码 + 0x80）+ 异常码 + CRC。例如发送功能码 03H 请求一个超出范围的地址，从站返回 83H，后面跟一个异常码。

在实际代码里，处理异常码的默认策略是：如果是 01H、02H、03H 这类与请求内容相关的错误，说明配置有问题，不要把请求反复重发；如果是 04H、06H 这类临时性错误，可以延迟一段时间后重试 2-3 次，仍失败再报警。

5. 常见问题与故障排查方法整理

5.1 通信完全无响应排查思路

这是我最常被问到的问题：“串口工具发了报文，但设备没有任何回复。”下面按排查顺序列出我实用过的步骤，按这个顺序排查效率最高：

1. 先用万用表量 A、B 线之间的电压。正常情况下应该能看到 2V-7V 的直流电压差，如果量出来是 0V，说明收发器没工作或者总线没接对。
2. 检查串口参数是否与设备完全一致，包括波特率、数据位、校验位、停止位。很多设备出厂默认是偶校验，如果你用无校验去请求，必然收不到响应。
3. 检查从站地址对不对。用 Modbus Poll 分别尝试从站地址 1 到 10 各发一帧请求，看是否有响应。
4. 换一个 USB 转 485 模块测试。USB 转 485 模块质量参差不齐，CH340 和 CP2102 方案兼容性相对好一些。如果手头有示波器，可以直接看 A/B 线上有没有波形，没有波形就是模块或者驱动问题。
5. 最后检查 120Ω 终端电阻。如果总线上只有一台设备，终端电阻可接可不接（设备内部不少会自带上拉/下拉电阻），但两台以上时还是接上稳妥。

5.2 数据读出来了但数值明显不对

数据能读出来说明链路没问题，但数值不对，大概率是解析问题。按下面的优先级排查：

• 字节序/字序不对：用 Modbus Poll 切字节序，或者拿 Python 把四种组合全试一遍。
• 倍率/缩放因子没应用：设备手册里通常有“分辨率”或“倍率”字段，比如 0.1、0.01，别漏了这步换算。
• 有符号数被当成无符号数：如果数值特别大（比如 65535 附近）或者应该为负数但显示成了很大的正数，就要转成有符号类型。
• 地址偏移量填错：比如把 40003 直接填到地址字段，导致读的是另一个寄存器。

5.3 CRC 错误率高的现场排查

如果通信偶尔成功偶尔报 CRC 错误，或者上位机收到的帧频繁 CRC 校验失败，可以从这几个方向找原因：

• 波特率太高，长线传输信号质量差。把波特率降回 9600 或者 19200 试试。
• 屏蔽层没有接地或者接地不良。485 通信属于高速差分信号，屏蔽层不接地等于没有屏蔽。
• 用了劣质 USB 转 485 模块，或者模块本身没有隔离，在电机启动、继电器吸合等场景下容易受干扰。
• 总线分支线过长，反射信号叠加上去破坏了数据帧。
• 线路距离过长且没有终端电阻，信号反射严重。

5.4 帧接收粘包与拆包处理技巧

粘包和拆包本质上是帧边界识别问题，处理思路我已经在状态机部分讲过，这里再补充一个实用技巧：

在调试阶段，可以先用串口抓包工具（比如 SSCOM、友善串口助手）直接观察总线上原始字节流，确认设备返回的帧之间间隔是否稳定。如果设备响应速度和预期不符，先用抓包确认，再改代码。不要在代码里盲目调超时阈值，那样容易按下葫芦浮起瓢。

另外，如果是自己实现主站，请求发送后要有一个接收窗口。也就是说，发完请求后立刻进入接收模式，等够超时时间还没收到数据，再从接收转为发送下一帧，避免收发切换太快导致总线冲突。

6. 工具链与效率提升建议

6.1 三件套工具：Modbus Poll、Modbus Slave、串口调试助手

调试 Modbus RTU 项目，我日常必开三个软件：

• Modbus Poll：模拟主站，测试从站设备，验证寄存器地址和数据格式。
• Modbus Slave：模拟从站，配合测试自己写的上位机采集程序。
• 串口调试助手：直接看原始字节流，排查协议层面的问题。

Modbus Poll 除了基本的寄存器读取之外，还可以设置轮询周期（Polling Delay）、超时时间（Response Timeout）、多寄存器连续读取等参数。调试复杂设备时，我会先把需要读的寄存器全部配置到一个工程文件里，然后保存成 .mbpoll 文件，下次打开直接加载，不用重新一个个配置。

Modbus Slave 的 ID 是支持同时模拟多个从站的，最多可以开多个 Slave ID 窗口，每个窗口模拟一个设备。这个功能在测试多台设备轮询时非常好用，不用真准备三四台设备，电脑上就能模拟整个总线。

6.2 虚拟串口对：没有硬件也能联调

有些项目需要同时调试主站和从站逻辑，又没有真实硬件。安装 VSPD（Virtual Serial Port Driver 或者其他虚拟串口工具），创建一对互相连接的虚拟串口 COM4 和 COM5，然后在 COM4 上跑主站程序、COM5 上跑从站模拟器，就能完整体验一次 Modbus RTU 通信的流程。

这个方案在出差、没有设备、或者现场设备不能随便乱动的情况下特别有用。我在项目初期对协议理解不深的时候，就是用这对虚拟串口把整个主从交互逻辑调通，再拿到现场联调真实设备，联调时间从两天缩短到半天。

6.3 日志记录与数据存档

正式项目里，上位机程序一定要有完善的调试日志功能，把每次收发报文的十六进制数据、解析结果、错误信息都记录到本地文件。这样现场出现问题时，不用盯着屏幕猜，直接翻日志就能定位。

日志级别建议分三层：DEBUG 级别记录所有收发原始报文；INFO 级别记录数据轮询结果和状态变化；ERROR 级别记录通信异常和设备离线等错误信息。线上跑的时候，日志文件要按日期切分、定期清理，不然长时间运行会把存储空间占满。

最后再分享一点个人的体会：Modbus RTU 这套协议能存在这么多年、应用这么广，就是因为它足够简单、足够实用。实际项目中遇到的大部分问题，不是协议本身有多难，而是细节处理不到位——地址偏移填错、字节序没确认、帧超时设置不当、物理层接线不规范，这些问题占了故障的 90% 以上。先把基础焊牢，工具用熟，代码逻辑清晰，再复杂的 Modbus 项目也就是几步串联的事。希望这篇小结能帮你少走一些弯路。