4. Modbus TCP远程I/O读写超时：用轮询周期与超时参数匹配分析
问题定位思路：把“超时”拆成三个可测的量
Modbus TCP 远程 I/O 的读写超时，本质是主站等待从站响应的时限被突破。要判断根因，不能只看“超时了”，而要把三个量放在同一时间轴上比较：轮询周期 Tpoll（主站两次发起同一从站请求的间隔）、从站响应时间 Tresp（请求发出到响应到达）、超时时间 Tto 与重试次数 Nretry。当 Tresp 偶发接近或超过 Tto，就会报超时；而 Tpoll 过小会让从站请求排队，进一步拉长 Tresp。
下面这张图把一次轮询窗口内的时序关系、参数约束和三种典型根因的判据放在一起，便于对照现场采集的数据做判断。
现场采集：用轮询日志算出 T_resp 分布
判断根因的第一步不是改参数，而是拿到 T_resp 的真实分布。多数 Modbus 主站（PLC、SCADA 网关、边缘采集器）都提供通信诊断计数或可导出的轮询日志。若没有现成日志，可在主站侧对每次请求打时间戳，记录“请求发出时刻”和“响应到达时刻”，两者之差即 T_resp。下面是一段用于离线分析的 Python 示例，输入是从日志导出的 T_resp 序列（单位 ms），输出 P50/P95/P99 与超时占比，用于和 T_to 对照。
import statistics
# 示例数据：从主站轮询日志导出的单从站 T_resp 序列（ms），仅作演示
t_resp = [95, 102, 98, 110, 105, 99, 101, 108, 96, 103,
104, 100, 97, 112, 106, 99, 102, 109, 95, 101,
118, 125, 130, 122, 128, 135, 140, 132, 126, 121,
145, 150, 138, 142, 148, 155, 160, 152, 147, 143,
170, 175, 168, 180, 172, 165, 178, 182, 176, 169]
t_to = 200 # 主站当前超时设置（ms）
t_poll = 150 # 主站当前轮询周期（ms）
n_retry = 2 # 重试次数
def percentile(data, p):
s = sorted(data)
k = (len(s) - 1) * p / 100
f = int(k)
c = min(f + 1, len(s) - 1)
return s[f] + (s[c] - s[f]) * (k - f)
p50 = percentile(t_resp, 50)
p95 = percentile(t_resp, 95)
p99 = percentile(t_resp, 99)
timeout_cnt = sum(1 for x in t_resp if x >= t_to)
timeout_rate = timeout_cnt / len(t_resp) * 100
print(f"样本数: {len(t_resp)}")
print(f"P50={p50:.1f}ms P95={p95:.1f}ms P99={p99:.1f}ms")
print(f"超时次数: {timeout_cnt} 超时率: {timeout_rate:.1f}%")
print(f"T_to={t_to}ms T_poll={t_poll}ms N_retry={n_retry}")
# 参数匹配检查
if p99 >= t_to:
print("结论: T_to 小于 P99，参数偏紧，优先调整 T_to")
elif t_poll < p95:
print("结论: T_poll 小于 P95，请求过密，从站可能排队")
else:
print("结论: 参数基本匹配，超时更可能来自网络抖动或从站偶发卡顿")
按示例数据运行，P99 约为 180 ms，T_to=200 ms 时超时率约 0%，但若现场 T_to 设为 150 ms，则超时率会明显上升——这正是“参数设置不当”的典型特征：T_resp 分布本身稳定，只是阈值卡在了分布尾部。反之，若 T_resp 的 P99 随请求密度上升（例如把 T_poll 从 150 ms 降到 80 ms 后 P99 从 180 ms 涨到 260 ms），则指向从站处理能力不足或请求排队。
三类根因的区分方法
| 根因 | T_resp 分布特征 | 关键验证动作 | 处理方向 |
|---|---|---|---|
| 网络时延 | 整体偏低但偶发尖峰，抖动大；抓包可见 TCP 重传、乱序或 ACK 延迟 | 交换机端口镜像抓包，统计重传率与 RTT 抖动 | 排查链路质量、交换机拥塞、无线/环网路径 |
| 从站处理能力 | T_resp 随并发请求数或 T_poll 减小而线性上升，P99 明显抬高 | 降低 T_poll 或减少同从站请求数，观察 P99 是否回落 | 增大 T_poll、拆分从站负载、检查从站 CPU/任务周期 |
| 主站参数不当 | T_resp 分布稳定，但 T_to 落在 P95~P99 之间，超时呈规律性 | 对比 T_to 与 P99，单独调大 T_to 后超时消失 | 按 T_to ≥ P99×1.5 重设，并核对 N_retry 与刷新周期 |
复测与验证
调整参数后，用同一采集脚本连续记录 ≥200 次轮询，确认三点：① 超时率降为 0 或低于可接受阈值；② P99 未因 T_poll 变化而显著上升；③ 抓包中无持续重传。若调大 T_to 后超时消失但 P99 仍高，应继续排查从站负载与网络路径，而不是停留在参数层面。