4. 超时与重试机制：响应超时设置、重试策略、轮询周期优化

各位工程师，咱们接着聊。Modbus 通信里，超时和重试这俩东西，说白了就是「等多久」和「等不到怎么办」。我见过太多项目，设备明明没问题，就因为超时设得太死，整个系统频繁报错。嗯，今天我把这块掰开揉碎了讲清楚。

4.1 响应超时设置：别让设备「憋死」

响应超时，就是从你发出请求，到收到响应，你愿意等的最长时间。我个人的习惯是：先测后设。别拍脑袋定个 100ms，那大概率要出问题。

为什么会这样？因为 Modbus 走串口时，波特率、从站数量、线路长度都会影响响应时间。举个例子，9600 波特率下，一个 8 字节的帧，光传输就要 8ms 左右。再加上从站 CPU 处理时间，你设 20ms 可能刚好够，但稍微有点干扰就超时了。

我的建议：

• 串口 Modbus： 建议 200ms - 500ms。别低于 100ms，除非你用的是高速从站。
• Modbus TCP： 建议 100ms - 300ms。网络延迟小，但也要考虑交换机转发时间。
• 无线 Modbus： 建议 500ms - 2000ms。无线丢包重传，时间不可控。

4.2 重试策略：不是无脑重试

超时了怎么办？重试呗。但怎么重试，这里头有讲究。我见过有人设了 10 次重试，结果从站直接死机——因为从站还在处理上一次的请求，新的又来了。

重试策略我一般分三种：

策略类型	说明	适用场景
固定间隔重试	每次等待相同时间后重试	网络稳定的环境
递增间隔重试	第一次等 100ms，第二次 200ms，第三次 400ms	无线或干扰大的环境
立即重试	超时后马上再发一次	仅用于 Modbus TCP 丢包场景

我个人最常用的是递增间隔重试。为什么？你想想看，如果第一次超时是因为从站忙，你马上再发一次，它可能还是忙。等一会儿再发，它可能就处理完了。

重试次数建议：

• 串口：2-3 次。再多就影响轮询周期了。
• TCP：3-5 次。网络偶尔丢包，多试几次没问题。
• 无线：3-5 次。但间隔要拉长，别把从站「打爆」了。

4.3 轮询周期优化：别让总线「堵车」

轮询周期，就是你把所有从站扫一遍的时间。这个时间怎么算？说白了就是：（请求时间 + 响应时间 + 间隔时间）× 从站数量。

我见过一个项目，现场有 50 个从站，每个轮询周期要 10 秒。操作员按个按钮，要等 10 秒才有反应。这谁受得了？

优化方法：

1. 分组轮询： 把重要的从站放一组，不重要的放另一组。重要组轮询快一点，比如 500ms 一次；不重要组慢一点，比如 5 秒一次。
2. 事件触发： 别傻乎乎地一直轮询。有些数据变化很慢，比如温度，你每秒读一次纯属浪费。改成变化触发，或者 10 秒读一次就够了。
3. 批量读取： 能用功能码 03 读多个寄存器，就别用功能码 01 一个一个读。一次读 10 个寄存器，比读 10 次快得多。

4.4 知识体系图：超时与重试的核心逻辑

下面这张图，是我自己总结的。你看一眼，就能明白整个机制怎么串起来的。

4.5 轮询周期计算公式

最后，我给大家一个实用的公式。你直接套用就行。

轮询周期 = (请求帧时间 + 响应帧时间 + 超时时间) × 从站数量 × (1 + 重试概率)

其中：
请求帧时间 = 帧长度(字节) × 10 / 波特率
响应帧时间 = 帧长度(字节) × 10 / 波特率
重试概率 = 重试次数 × 超时概率（一般取 0.1 - 0.3）

好了，超时与重试这块就讲到这里。记住一句话：别让设备等太久，也别让总线太拥挤。找到那个平衡点，你的 Modbus 系统就能稳稳地跑起来。

---

公众号:蓝海资料掘金营，微信deep3321