ModbusRTU主从通信时序图解：通俗解释数据交互过程

ModbusRTU通信时序全解析：从一帧数据的诞生到落地

在工业现场，你是否遇到过这样的场景？

一台PLC怎么也读不到温湿度传感器的数据，通讯灯闪烁却始终无响应；
轮询十几个从站时，总有某个设备偶尔超时，重启后又恢复正常；
换了个波特率，整个网络就“瘫痪”了……

这些问题背后，往往不是硬件故障，而是对ModbusRTU通信时序机制理解不够深入。今天我们就抛开抽象术语，用一张张“时间线”，带你走进串行总线上的真实世界——看主站如何发号施令，从站怎样见机行事，以及那一段看似沉默的“空白期”为何至关重要。

为什么是主从？先搞清谁说了算

ModbusRTU 不是一个“人人可发言”的聊天室，而是一场严格的点名问答。

想象一个教室：
- 老师（主站）掌握话语权，只有他能提问；
- 学生（从站）编号1~247，只能被点名后回答；
- 没人允许抢答，否则就会“撞车”。

这种结构叫主从架构（Master-Slave），也是 ModbusRTU 的铁律：

✅ 总线上只能有一个主站
✅ 可有多个从站（地址1~247）
✅ 所有通信由主站发起，从站被动响应

这就避免了多设备同时发送导致的信号冲突，特别适合RS-485这类半双工总线。

所以当你发现某台设备不回话，第一反应不该是“它坏了”，而要问：“主站有没有正确呼叫它的地址？”

数据是怎么打包的？拆开一帧看看

ModbusRTU 使用RTU编码，也就是直接把数据按字节传输，不像ASCII那样把每个字节转成两个字符。这就像快递员送包裹：RTU是整箱发货，ASCII则是拆成零件一件件寄——显然前者更快更省带宽。

比如数值0x1A：
- RTU中占1个字节
- ASCII中要发'1'和'A'两个字符，翻倍！

但为了保证数据完整，每帧末尾都会加一个“防伪标签”——CRC16校验码。接收方收到后重新计算CRC，若与标签不符，说明途中出错，整帧丢弃。

主站发什么？以“读保持寄存器”为例

假设主站想读地址为1的设备、起始地址0x0000、共2个寄存器，发出的请求帧如下：

这一串共8字节，连续发出，中间不能停顿。

从站怎么回？带上答案和身份标识

如果一切正常，从站#1会返回：

总共8字节响应。注意：如果出错（如地址不对、寄存器不存在），功能码会变成0x83（即0x03 | 0x80），并附上错误码。

时间才是关键：通信时序图告诉你什么时候该做什么

真正决定通信成败的，往往不是数据内容，而是时间节奏。

下面是典型的一次 ModbusRTU 交互全过程的时间轴：

时间 → ─────────────────────────────────────────────── [ 空闲 ≥ T3.5 ] ↓ [ 主站发送请求 ] 01 | 03 | 00 | 00 | 00 | 02 | XX | XX └────────────────────────────────┘ ↑ [ 至少 T3.5 ] ↓ [ 从站处理 ] ↓ [ 从站发送响应 ] 01 | 03 | 04 | 00 | 64 | 00 | 00 | XX | XX └──────────────────────────────────────┘ ↑ [ 新帧开始 ]

别小看这几毫秒的间隔，它们决定了系统能不能稳定运行。

四个关键时间节点，缺一不可

1. 发之前：必须等够 T3.5

T3.5 是什么？

它是“传输3.5个字符所需的时间”。由于串行通信是连续流，没有起始/结束标志，协议规定：

当线路空闲时间 ≥ T3.5 时，认为上一帧已经结束，接下来的是新帧。

这个机制叫做帧边界识别，靠的就是“足够长的沉默”。

举个例子，在9600波特率下：
- 每个字符11位（1起始 + 8数据 + 1停止 + 可选校验）
- 传一位约需 104.17μs
- 传3.5个字符 ≈3.65ms

所以主站在发新请求前，必须确保总线至少安静了3.65ms。否则从站可能误判这是上一帧的延续，直接丢弃。

⚠️ 实践提示：很多MCU串口DMA发送完成后立刻启动接收，容易忽略T3.5等待，导致帧头丢失！

2. 发之中：一口气发完，不准喘气

一旦开始发送，所有字节必须连续输出，中间不能有任何延迟。

如果你在代码里写了个for循环逐字节发送，并且每字节之间sleep(1)，那整个帧就被切碎了，从站无法识别。

正确的做法是：
- 使用UART DMA一次性发送完整帧
- 或者用中断驱动连续发送，禁止中途被打断

3. 收之间：留足处理时间

主站发完后，不能马上判断“没回应=失败”。因为从站需要时间做这几件事：
- 接收并校验请求帧
- 解析地址和功能码
- 查找对应寄存器
- 组织响应数据
- 计算CRC
- 等待总线空闲 ≥ T3.5 后才能发回

这个过程通常需要几毫秒到几十毫秒，取决于从站CPU性能和任务负载。

因此，主站应在发送后启动一个响应超时定时器，建议设置为：

1.5 ~ 2 个字符时间 + 预估处理延时

例如在9600波特率下，等待50~100ms是比较安全的选择。

4. 响应之后：又是新的 T3.5 开始

从站发完响应后，也会进入监听状态。当下一次主站要轮询下一个设备时，依然要先等 T3.5，再发新请求。

整个通信就像打乒乓球：你来我往，节奏分明，谁乱了拍子谁输。

实战案例：一个温控系统的轮询过程

来看一个真实的工业场景：

[ PC 上位机 (主站) ] │ ↓ RS-485 总线（A/B双绞线） [ 温度变送器 #1 ] —— 地址 0x01 [ PID 控制器 #2 ] —— 地址 0x02 [ 电动阀门 #3 ] —— 地址 0x03

主站轮询流程如下：

1. 等待 T3.5
2. 发送：01 03 00 00 00 02 CRC→ 读温度值
3. 等待响应 ≤ 100ms
   - 收到：01 03 04 00 64 00 00 CRC→ 温度100℃
4. 等待 T3.5
5. 发送：02 03 00 01 00 01 CRC→ 读PID设定值
6. 等待响应 ≤ 100ms
   - 收到：02 03 02 00 32 CRC→ 设定值50
7. 等待 T3.5
8. 发送：03 10 00 01 00 01 02 32 00 CRC→ 写阀门开度50%
9. ……

每一步都严格遵循“发→等→收→等”的节奏。

工程师必须知道的5个设计要点

1. 波特率统一，参数一致

所有设备必须配置相同的：
- 波特率（推荐9600或19200用于长距离）
- 数据位：8
- 停止位：1
- 校验位：无 / 奇 / 偶（需统一）

📌 推荐默认配置：9600, 8, N, 1—— 兼容性最强

2. 轮询策略要聪明，别“一视同仁”

不要对所有从站使用相同频率轮询。合理做法：
- 高频采集：温度、压力等实时变量，每100ms读一次
- 低频轮询：状态信息、报警标志，每1~5秒读一次
- 批量读取：尽量用功能码0x03一次读多个寄存器，减少通信次数

这样既能保障实时性，又能减轻总线负担。

3. T3.5 怎么实现？定时器来帮忙

在STM32等嵌入式系统中，常用硬件定时器检测T3.5：

#define CHAR_TIME_US(baud) (1000000UL * 11 / (baud)) // 每字符微秒数 #define T3_5_US(baud) ((CHAR_TIME_US(baud) * 35 + 9) / 10) // 四舍五入 void modbus_start_send(uint8_t *frame, int len, uint32_t baud) { // 等待上一次通信完成（已过T3.5） while (!t35_elapsed); // 发送当前帧（使用DMA或中断） HAL_UART_Transmit_DMA(&huart2, frame, len); // 启动T3.5定时器，用于下次帧边界判断 uint32_t timeout = T3_5_US(baud); __HAL_TIM_SET_COUNTER(&htim, 0); __HAL_TIM_SET_AUTORELOAD(&htim, timeout); HAL_TIM_Base_Start_IT(&htim); }

当定时器超时，表示可以开始新帧接收。

4. 异常处理不能少

建立健壮的通信机制：
- 超时重试：最多2~3次
- 错误日志：记录失败时间和设备地址
- CRC失败：静默丢弃，不反馈
- 地址冲突检测：避免两个设备设成同一地址

5. 别忘了终端电阻！

RS-485总线两端必须接120Ω终端电阻，特别是在：
- 通信距离 > 100米
- 波特率 > 19200
- 环境干扰强（如电机旁）

否则信号反射会造成波形畸变，导致误码甚至通信中断。

✅ 正确做法：只在最远两端设备上接入120Ω电阻，中间节点不接。

写在最后：简单，才是最大的优势

尽管现在有 EtherNet/IP、Profinet、MQTT over TLS 等炫酷协议，但 ModbusRTU 依然是工厂车间里的“老黄牛”。

它没有复杂的协议栈，不需要操作系统，单片机裸机就能跑；
它不挑线缆，普通双绞线就能走几百米；
它生态庞大，随便买个仪表都支持。

更重要的是，只要你理解了那一段“T3.5”的沉默，你就掌握了打开工业通信大门的钥匙。

下次当你面对闪烁的通讯灯束手无策时，不妨回到这张时序图：

是否等够了 T3.5？
是否连续发送？
是否给了足够的响应时间？

答案往往就在这些细节里。

如果你正在调试 Modbus 通信，欢迎在评论区分享你的“踩坑”经历，我们一起排雷。