Modbus多从站读取问题总结
一、定时器方案的局限（最初的问题）
代码逻辑：
cpp
QTimer* timer = new QTimer(this);
timer->start(500); // 每500ms触发一次
connect(timer, &QTimer::timeout, [this]() {for (int id = 5; id <= 8; id++) { // 一次读4个从站readCoils(id);}
});
问题表现：
text
500ms: 读5,6,7,8 (同时发4个请求)
500ms: 读5,6,7,8 (同时发4个请求)
500ms: 读5,6,7,8 (同时发4个请求)
根本问题：
-
请求并发冲突：从站5还在处理请求，下一个请求就来了
-
资源竞争：4个请求同时发出，从站5被淹没
-
超时误判：从站5响应慢一点就超时，导致"恢复连接"反复出现
-
日志表现：
text
读5(成功) → 读5(超时) → 读5(成功) → 读5(超时)从站5在成功和失败间反复横跳
二、链式方案的局限（改进后的方案）
代码逻辑：
cpp
readCoils(5) → 收到响应 → readCoils(6) → 收到响应 → readCoils(7) → ...
问题表现：
text
【首次】读取炉子5
【链式】读取炉子6 (卡住不动了...)
根本问题：
-
单点故障：整个链依赖每个请求都必须有响应
-
无响应卡死：如果某个从站无响应（如从站6不存在），整个链就断了
-
响应时间累积：4个从站串行，总时间 = 4 × (响应时间 + 间隔)
-
日志表现：
text
读5(成功) → 读6(无响应) → 程序卡死永远不会读到7和8
三、线程方案的优点（最终方案）
代码逻辑：
cpp
// 每个从站独立线程
线程1: 每500ms读从站5 ─────→ 收到响应 ─────→ 处理数据
线程2: 每2000ms读从站6 ───→ 超时 ────────→ 记录错误
线程3: 每2000ms读从站7 ───→ 超时 ────────→ 记录错误
线程4: 每2000ms读从站8 ───→ 超时 ────────→ 记录错误
优点：
1. 完全隔离，互不干扰
cpp
// 从站5用高频，稳定运行
从站5: 成功→成功→成功→成功 (不受其他从站影响)// 从站6-8用低频，快速失败
从站6: 超时→超时→超时→超时 (5次后标记断开)
2. 并发执行，效率高
- 4个从站可以同时读取
- 总响应时间 = 单个最慢从站的响应时间
- 不再是链式的累加时间
3. 容错性强
cpp
// 一个线程卡住不影响其他线程
线程2卡住(从站6无响应) → 线程1继续读从站5 → 线程3继续读从站7
4. 可配置优先级
cpp
// 重要从站用高频
timer5->start(500); // 从站5 500ms// 不重要或不存在的从站用低频
timer6->start(2000); // 从站6 2000ms
5. 资源可控
cpp
// 线程池管理，避免无限创建线程
m_threadPool.setMaxThreadCount(10); // 最多10个并发
四、三种方案对比表
| 对比项 | 定时器方案 | 链式方案 | 线程方案 |
|---|---|---|---|
| 并发性 | 高(同时发多个) | 低(串行) | 高(真正并发) |
| 相互影响 | 严重 | 严重 | 无影响 |
| 容错性 | 低 | 低(单点故障) | 高 |
| 响应时间 | 快但混乱 | 慢(累加) | 快(并行) |
| 资源占用 | 低 | 低 | 中(可控) |
| 代码复杂度 | 低 | 中 | 中高 |
| 适用场景 | 单从站 | 所有从站都可靠 | 混合场景 |
五、最终结论
为什么定时器和链式都不行？
- 定时器方案：请求打架，从站5被淹没
- 链式方案：单点故障，一个无响应就全卡死
为什么线程方案能解决问题？
- 隔离性：每个从站独立线程，互不干扰
- 并发性：可以同时读取多个从站
- 容错性：坏掉的从站不影响好的
- 可控性：可以为重要从站设置更高优先级
最终效果：
text
从站5: 稳定500ms一次，实时监控
从站6: 2000ms一次，5次失败后标记断开
从站7: 2000ms一次，5次失败后标记断开
从站8: 2000ms一次，5次失败后标记断开
互不影响，各司其职！