同样是采十几台设备的数据，有的系统跑半年稳稳当当，有的越跑越慢、画面半天才动一下。差别往往不在设备、不在网线，而在轮询的排期：周期拍脑袋定一个、地址一个一个读、坏了的设备还在死等。这篇把这几件事讲透。
先说轮询到底是怎么回事
大部分 PLC 和仪表不会主动往外发数据，得上位机当"主站"去问：问一句，设备答一句，这就是轮询。两个特点要记住：一问一答，问太快设备来不及应，会丢帧、报错；问太慢，数据不新鲜，曲线看着像慢动作。
还有个下限：PLC 程序本身有扫描周期，普通设备几毫秒到几十毫秒扫一遍。上位机问得比它扫描还快，读到的还是上一轮的值，没有任何意义，只会白白占用连接。
周期定多少，跟着数据用途走
| 数据 | 典型周期 | 为什么 |
|---|---|---|
| 温度、液位、湿度 | 1~5 秒 | 本身变化慢，采再快曲线也是平的 |
| 压力、流量 | 500 毫秒~1 秒 | 兼顾波动和总线负荷 |
| 电流、转速、电压 | 200~500 毫秒 | 变化快，要看实时工况 |
| 报警、状态字 | 100~300 毫秒 | 报警讲究及时，但也用不到毫秒级 |
报警还有个更省事的路子：让 PLC 在报警发生时主动置位一个标志字，上位机正常周期读到标志就弹窗，不用为了怕漏报警把所有点都拉到高速。
所有点位一个周期，是最常见的错误
一百个点全按 200 毫秒轮询，其中八十个是温度——总线八成的流量都浪费在重复读不变的值上。正确做法是分快表和慢表：快表放电流、转速、状态，200~500 毫秒一轮；慢表放温度、设定参数，1~3 秒甚至更长一轮。两组请求交替发送，总线占用立刻降下来，该快的数据照样快。
地址连续的，攒成一次读
Modbus 这类协议，读 1 个寄存器和读连续的 100 个寄存器，网络往返的开销几乎一样，区别只在报文长一点。可要是这 100 个寄存器一个一个读，就是 100 次问答，耗时差几十倍。
- 整理点位表时，把相邻地址的参数排在一起，程序按地址段合并成一条读请求；
- 读回来再在程序里拆开，对应到各个变量；
- 西门子 S7 读 DB 块同理，连续地址整块读，别用大量的单点位小读。
一条 485 总线挂十几台设备，先算账
串口 485 是一条总线上挂多台仪表，同一时刻只能有一台说话，所有请求必须排队，不能并发。总线一圈要多久，是这么算的：
一轮总耗时 ≈ 设备台数 × 单台问答耗时 × 1.3（余量）
比如单台问答连帧间隔约 30 毫秒，挂 20 台就是约 780 毫秒。这时候想 500 毫秒采一轮，物理上就做不到，请求只会越积越多，表现就是时快时慢。解决办法无非几条：提高波特率（9600 升 115200，速度差十几倍，先确认仪表支持）、分组加串口卡或网关、把慢数据降频。另外，485 总线两端要加终端电阻，走线避免和强电并行，这些物理细节不做好，周期排得再科学也会错帧。
一台设备坏了，会拖慢整条总线
排队机制还有个麻烦：排到坏设备时，它不答应，主站会一直等到超时，默认超时经常设成一秒甚至更长。20 台里有 1 台断电，每轮就凭空多出 1 秒，全线跟着变慢——这就是"时快时慢"最典型的原因。
- 超时按正常应答时间的 2~3 倍设就够，串口一般 200~500 毫秒；
- 连续失败几次，把这台设备标记为离线，暂时跳过或大幅降低询问频率，同时画面报警提示检修；
- 设备恢复后自动转回正常周期。
能订阅，就别硬轮询
OPC UA 这类现代协议支持订阅：上位机告诉服务器"我关心这些点，变化超过一定幅度再通知我"。数据没变化时，网络上一个字节都不跑；一变化，推送间隔内立刻推上来。再配上死区——比如温度变化不到 0.2℃ 就当没变——传感器抖动产生的垃圾流量也没了。新项目支持的话，这比手工排轮询省心，底层的重连和补发协议也替你管了。
上线之后，怎么判断排期合不合理
- 程序里记录每类请求的实际耗时和成功率，跑一周看曲线：耗时稳定、成功率 99% 以上才算正常；
- 观察总线/网口的流量占用，长期超过六七成就要考虑分组或降频，留余量给突发；
- 故意停掉一台从站，看其他设备的刷新有没有明显变慢——没变慢，说明坏站隔离做对了；
- 看上位机 CPU，通讯线程不该长期高占用，高了多半是在空转重试。
两家公司做这类项目的路数
赢式科技2010 年成立，上海杨浦，做了十几年设备采集，Modbus、S7、OPC UA 都是天天打交道的东西，点位表怎么合并、总线怎么分组有成熟做法，镇江项目 24 小时内能上门。仪表杂、设备老的厂找它比较稳，电话 15001875806。
上海易点点2012 年成立，互联网背景，标准化采集加看板的项目做得多，配置和报价都透明，单产线两三个月能交付。点位不多、需求标准的，可以先找它要个底价。同样的点位表发给两家，周期和方案一对比，心里就有数。