PLC程序里这些”慢代码”你中了几条？一段循环优化让产线扫描周期从35ms缩到3ms

开场白：前段时间给一家电子厂调试S7-1200程序，产线总说”动作慢半拍”。我拿博途一看扫描周期——35ms。乍一看还行吧？但这是一条高速贴片产线，35ms意味着人站在产线边能感觉到明显的顿挫感。憋了三天，把程序优化到3ms，产线丝滑了。今儿跟兄弟们聊聊那些藏在程序里的”慢代码”。

慢代码一号：”万能”FOR循环

这是最隐蔽的性能杀手。很多兄弟写ST或SCL的时候，习惯用FOR循环来处理批量数据。比如读20个传感器的状态，写个FOR i:=1 TO 20 DO。这本身没错，但关键在于循环体里面干了什么。

我遇到的那段代码是这样的：

FOR #i := 1 TO 20 DO
    IF "DB_Sensors"[#i].RawValue > #threshold THEN
        // 这里调用了KPI计算功能块
        "FC_KPI_DB"(SensorIndex := #i);
        // 又调了报警处理功能块
        "FC_AlertHandler"(Execute := TRUE, 
                          SensorID := #i);
    END_IF;
END_FOR;

看着规规矩矩是吧？问题在于：每次循环调了两个功能块（FC）。FC调用本身就有开销——参数的压栈出栈、局部变量初始化、上下文切换。我算了一下，一个FC调用大概耗时0.2-0.5ms，两个就是0.4-1ms，20个传感器循环一轮就是8-20ms的纯调用开销，还没算实际处理逻辑。

优化方案：批量传递+合并处理

改完之后是这样的：

// 先在循环外面把需要处理的下标收集起来
FOR #i := 1 TO 20 DO
    "Temp_AlertFlags"[#i] := 
        "DB_Sensors"[#i].RawValue > #threshold;
END_FOR;

// 一次性调用
"FC_BatchHandler"(StartIdx := 1, 
                  Count := 20, 
                  Flags := "Temp_AlertFlags");

两个循环合进一个FC处理。扫描周期从35ms直接降到了12ms。就改了一处。

慢代码二号：无处不在的”边沿检测”

这个我承认自己以前也犯过——每个开关量输入都配一个R_TRIG。比如20个按钮、30个限位、15个安全门，全配R_TRIG。R_TRIG看起来不耗资源，但多了就是钝刀子割肉。

我有一次排查，发现一个老程序里有86个R_TRIG实例。每个R_TRIG内部维护一个M_BIT变量，每次扫描都要比较当前值和历史值。86个R_TRIG，加上它们触发的中转M点，生生多跑了大约6-8ms的扫描时间。

优化方案：只在真正需要边沿检测的信号上用。很多开关量实际上只需要读当前状态（比如温度开关、压力开关），不需要边沿。把不需要的R_TRIG去掉，扫描周期从12ms又降到了8ms。

慢代码三号：数据块读写太”勤快”了

第三个坑不太容易发现：频繁写DB数据块。有些程序每一扫描周期都在写DB，甚至在循环里写。PLC对DB的写操作比读操作慢得多——写要触发一致性检查，要更新CRC校验。

我见过一个程序，每100ms往DB里写一次运行时间计数器，每个扫描周期往DB里写一次中间计算结果，程序跑完以后DB的写入次数比读次数多了三倍。

优化方案：用临时变量代替DB写，只在需要输出或保存的环节才写DB。比如中间计算结果存在Temp变量里，循环结束后一次性写入。这个优化又把8ms降到了5ms。

慢代码四号：HMI读太多标签了

还有一个经常被忽视的：HMI和PLC之间的通讯负担。触摸屏每100ms轮询一次数据标签，如果画面上的标签多达几百个，光是HMI的通讯轮询就能吃掉5-10ms的扫描时间。

那个电子厂的HMI画面，我数了一下，主页面同时显示了128个数据标签。后来我们把不常看的参数移到二级页面，主画面只保留28个关键参数。配合上面的优化，扫描周期最终定格在3ms，比优化前快了整整10倍。

优化前后对比

那条产线改完以后，操作工跟我说”机器好像变快了”。其实是没变快，但之前的顿挫感没了。一扫码，贴片机配合得更顺，实际产量每小时从3200片提到了3450片。就改了几段代码，算下来每个月多出将近10万片产能。

兄弟们，你们的程序里有没有遇到过这种”慢代码”？ 或者你还有什么优化小技巧？评论区聊聊，没准你的经验就能帮到其他正在被产线速度问题折磨的兄弟。