ST语言字符串循环优化：扫描周期从40ms降至2ms的状态机方案

1. 从2ms到40ms：一个字符串循环引发的性能悬案

搞工控的朋友大概率都遇到过这种场景：设备跑着跑着，扫描周期突然从个位数毫秒飙到几十毫秒，PLC的CPU占用率直接拉满，伺服轴开始抖动，HMI画面卡成幻灯片。你查了半天逻辑，发现代码里既没有死循环，也没有复杂的浮点运算，最后定位到问题源头——竟然是一个看起来人畜无害的字符串循环。

这个标题里的“2ms vs 40ms”，说的就是同一个功能逻辑，用不同的写法实现，扫描周期差了整整20倍。2ms是优化后的状态，40ms是优化前的状态。20倍的差距，在单轴设备上可能只是“稍微有点卡”，但在多轴联动、高速飞剪、电子凸轮这类对实时性要求极高的场景里，40ms的扫描周期足以让整个系统失控。

这篇文章面向的是所有用ST语言（Structured Text，结构化文本）做工业控制的工程师，不管你是刚接触ST的新手，还是写了几年逻辑但没深究过性能的老手，都能从里面找到可以直接抄作业的优化方案。我会把整个优化过程拆开揉碎，从问题定位、原理分析、方案对比到实操落地，一步步讲清楚为什么慢、怎么改、改完怎么验证。核心关键词会自然穿插在各个环节里，包括ST语言、字符串循环优化、扫描周期、R_TRIG、状态机这些。

先说结论：字符串循环慢，慢在“每次循环都在做重复的字符串操作”，而优化的核心思路是用状态机拆解循环，用R_TRIG做边沿触发，把“一次性大循环”变成“分时小步走”。这个思路不仅适用于字符串处理，任何耗时长的循环逻辑都可以套用。

2. 问题现场还原：40ms的扫描周期是怎么来的

2.1 一个典型的字符串拼接场景

假设你有一个配方管理系统，需要把多个工位的参数拼接成一条完整的配方字符串，然后写入文件或发送给上位机。配方有20个工位，每个工位的参数字符串长度约50个字符。用ST语言写出来大概是这样：

FOR i := 1 TO 20 DO RecipeString := CONCAT(RecipeString, StationParam[i]); END_FOR

这段代码看起来没问题，逻辑清晰，循环次数也不多，才20次。但实际跑起来，扫描周期直接从2ms跳到了40ms。为什么？因为CONCAT在ST语言里的实现机制，远比表面看起来要重。

每次调用CONCAT，系统都会在内存里重新分配一块空间，把原来的字符串和新追加的字符串复制进去，然后释放旧空间。20次循环意味着20次内存分配、20次字符串复制、20次内存释放。如果每个参数字符串平均50个字符，到第20次循环时，目标字符串已经接近1000个字符，每次复制都要搬运这1000个字符。累计下来，内存搬运量是50+100+150+...+1000，大约10500个字符的复制量。这还只是字符串本身，没算内存管理器的开销。

2.2 扫描周期为什么会暴涨

PLC的扫描周期是“输入采样→程序执行→输出刷新”循环往复的时间。程序执行阶段，CPU按顺序执行你的ST代码。如果某段代码耗时过长，整个扫描周期就会被拉长。

40ms的扫描周期意味着什么？假设你的设备要求扫描周期稳定在5ms以内，40ms已经超标8倍。对于PID控制回路，扫描周期从2ms变成40ms，积分时间和微分时间全部失配，控制效果直接崩盘。对于高速计数或位置锁存功能，40ms的窗口期可能错过好几个脉冲信号。

更隐蔽的问题是，这种性能劣化不是线性的。当配方工位从20个增加到40个，字符串长度翻倍，扫描周期可能不是翻倍到80ms，而是因为内存碎片和缓存失效，直接飙到150ms以上。这就是为什么很多工程师在实验室测试时觉得“还能忍”，一到现场满负荷运行就出问题。

2.3 为什么新手容易踩这个坑

ST语言的教学材料里，字符串处理通常只讲语法，不讲性能。CONCAT、INSERT、DELETE这些函数用起来很方便，但没人告诉你它们在底层做了什么。加上PLC编程的思维惯性——大家习惯了梯形图的“扫描即执行”模型，觉得循环20次就是20个扫描周期的工作量，实际上一个扫描周期内就把20次全干完了，CPU根本没时间喘气。

还有一个认知误区：很多人觉得“字符串操作不是实时任务，慢一点没关系”。但在现代工控系统里，配方管理、日志记录、通信协议组包，这些功能往往和实时控制逻辑跑在同一个任务里。字符串操作慢，拖垮的是整个控制任务。

3. 原理深挖：ST字符串循环为什么这么慢

3.1 字符串在PLC内存里的存储方式

要理解为什么慢，先得知道字符串在PLC里怎么存的。ST语言的字符串类型（STRING）通常是一个固定长度的数组，前面有一个字节或一个字表示当前实际长度。比如STRING[255]，实际占用256个字节：1个字节存长度，255个字节存字符。

当你执行CONCAT(a, b)时，系统需要：

1. 计算a和b的长度之和，检查是否超过目标字符串的最大长度
2. 在内存里找到一块足够大的连续空间
3. 把a的内容复制过去
4. 把b的内容追加到后面
5. 更新长度字段
6. 如果目标字符串是临时变量，还要处理旧内存的释放

每一步都涉及内存操作。PLC的内存管理器不像PC操作系统那么智能，没有复杂的内存池和缓存机制，每次分配和释放都是实打实的开销。

3.2 循环体内的重复计算

回到那个20次循环的例子。每次循环都在做“读取StationParam[i]→调用CONCAT→更新RecipeString”。这里有几个隐藏的重复计算：

• 长度检查重复：每次CONCAT都要重新计算RecipeString的当前长度，但这个长度在上一轮循环结束时已经知道了。
• 内存分配重复：每次CONCAT都可能触发新的内存分配，即使RecipeString的最终长度在循环开始前就能估算出来。
• 数据搬运重复：RecipeString的内容在每次循环中都被完整复制一遍，前面已经拼好的部分被反复搬运。

这就像你搬家，每搬一件家具就重新租一辆卡车，把已经搬上车的家具卸下来再装一遍。效率低得令人发指，但代码写出来就是这样的。

3.3 扫描周期与任务调度的关系

PLC的扫描周期是固定的时间窗口。假设扫描周期设定为2ms，你的程序执行用了1.5ms，剩下0.5ms是系统开销和通信处理。如果字符串循环突然占用30ms，扫描周期会被强制拉长到40ms（因为程序执行阶段必须等循环跑完才能进入输出刷新）。

这里有个关键点：扫描周期不是“平均时间”，而是“最坏情况时间”。即使字符串循环只在某些条件下触发（比如配方切换时），只要它触发一次，那一次的扫描周期就会飙到40ms。对于周期性控制任务，一次40ms的抖动就可能导致位置偏差或控制超调。

3.4 R_TRIG和状态机为什么能解决问题

R_TRIG是上升沿触发功能块，检测信号从0变1的瞬间。状态机是把一个大的连续动作拆成多个离散状态，每个扫描周期只执行一个状态。

把这两个结合起来，思路就清晰了：用R_TRIG检测“需要拼接字符串”这个事件的到来，然后用状态机把20次循环拆成20个扫描周期，每个周期只拼接一个工位的参数。这样每次扫描周期只做一次CONCAT，耗时从40ms降到2ms左右。

代价是总完成时间从“一个扫描周期内40ms”变成“20个扫描周期共40ms”。但关键在于，每个扫描周期的耗时是均匀的2ms，而不是突发的40ms。对于实时控制系统，均匀的2ms远比突发的40ms友好。控制回路每2ms更新一次，不会因为某次扫描突然变长而失稳。

4. 优化方案实操：从40ms降到2ms的完整步骤

4.1 第一步：定位耗时源头

在优化之前，先确认问题确实出在字符串循环上。有两种方法：

方法一：用PLC自带的性能监视工具。大多数主流PLC编程软件都有扫描周期监视和程序段耗时分析功能。你可以看到每个程序段或功能块的执行时间。如果某个循环段的耗时明显高于其他段，基本可以锁定。

方法二：手动打点计时。在循环前后读取系统时间戳，计算差值。ST语言里通常有TIME()或RTC()之类的函数可以获取毫秒级时间。代码大概这样：

StartTime := TIME(); FOR i := 1 TO 20 DO RecipeString := CONCAT(RecipeString, StationParam[i]); END_FOR EndTime := TIME(); CycleTime := EndTime - StartTime;

把CycleTime写到HMI上观察，如果稳定在30-40ms，问题确认。

注意：手动打点计时本身也有开销，但相对于40ms的循环耗时可以忽略。不要用这种方法测微秒级操作。

4.2 第二步：设计状态机拆解循环

状态机的核心是把“循环20次”变成“每次扫描执行一次，共执行20次”。需要定义几个状态：

• IDLE：空闲状态，等待触发信号
• PREPARE：准备状态，初始化目标字符串和索引
• APPEND：拼接状态，每次拼接一个工位参数
• FINISH：完成状态，输出结果并复位

用ST语言实现：

CASE RecipeState OF IDLE: IF StartRecipe THEN RecipeState := PREPARE; END_IF PREPARE: RecipeString := ''; StationIndex := 1; RecipeState := APPEND; APPEND: IF StationIndex <= 20 THEN RecipeString := CONCAT(RecipeString, StationParam[StationIndex]); StationIndex := StationIndex + 1; ELSE RecipeState := FINISH; END_IF FINISH: RecipeDone := TRUE; RecipeState := IDLE; END_CASE

这段代码每个扫描周期只执行一个状态。在APPEND状态下，每次只拼接一个工位参数，耗时约0.1ms（单次CONCAT的开销）。20个扫描周期完成全部拼接，总耗时和原来差不多，但每个扫描周期的负担均匀了。

4.3 第三步：用R_TRIG做边沿触发

状态机需要一个触发信号来启动。如果直接用StartRecipe这个BOOL变量，当它为TRUE时，状态机会在每个扫描周期都尝试启动，导致重复触发。用R_TRIG可以确保只在信号从FALSE变TRUE的那一个扫描周期触发一次。

Trig_StartRecipe(CLK := StartRecipe); IF Trig_StartRecipe.Q THEN RecipeState := PREPARE; END_IF

R_TRIG的功能是检测上升沿。CLK输入接StartRecipe，Q输出在上升沿的那个扫描周期为TRUE，之后即使StartRecipe保持TRUE，Q也变回FALSE。这样状态机只会被触发一次。

实操心得：R_TRIG的实例必须放在循环或条件判断之外，否则每次调用都会重新初始化，检测不到边沿。我见过有工程师把R_TRIG写在IF语句里面，结果死活触发不了，查了半天才发现是实例化位置的问题。

4.4 第四步：优化字符串操作本身

状态机解决了“分时”问题，但单次CONCAT的开销还可以进一步优化。几个技巧：

预分配目标字符串空间。如果知道最终字符串的最大长度，可以在PREPARE状态一次性分配好，避免APPEND过程中反复分配。有些PLC支持STRING[1000]这样的固定长度声明，声明时就分配好内存。

用数组代替字符串拼接。如果最终目的是发送或存储，不一定要拼成一个长字符串。可以用一个字符串数组，每个元素存一个工位参数，通信时按数组发送。这样完全避免了CONCAT操作。

批量复制代替逐次追加。如果PLC支持MEMCPY或类似的块复制指令，可以先把所有参数字符串复制到一块连续内存，然后一次性设置长度字段。这比20次CONCAT快得多，但需要对内存布局有深入了解。

4.5 第五步：验证优化效果

优化完成后，用同样的打点计时方法验证。理想情况下，每个扫描周期的耗时应该稳定在2ms左右，不再出现40ms的尖峰。

验证时要注意：

• 连续运行至少100个配方切换周期，观察是否有偶发的耗时尖峰
• 在不同负载条件下测试（比如同时运行通信任务和HMI刷新）
• 用示波器或逻辑分析仪抓取输出信号的抖动，确认控制精度没有下降

5. 方案对比与选型建议：哪种场景用哪种方案

5.1 三种方案的横向对比

5.2 什么时候必须用状态机

不是所有字符串循环都需要优化。如果满足以下任一条件，建议直接上状态机：

• 循环次数超过10次，且每次涉及字符串操作
• 字符串操作所在的程序段和实时控制逻辑在同一个任务里
• 扫描周期要求稳定在5ms以内
• 系统有多个类似的字符串处理逻辑，累计耗时可能叠加

如果字符串处理在独立的后台任务里，不影响控制任务，那原始循环也能用。但要注意后台任务和前台任务的数据交换需要加锁或双缓冲，否则会出现数据不一致。

5.3 状态机的扩展用法

状态机拆解循环的思路可以扩展到很多场景：

• 多轴插补：把长距离运动拆成多个小段，每个扫描周期计算一段的位置
• 通信协议解析：把长报文拆成多个字节逐个解析，避免单周期耗时过长
• PID参数自整定：把复杂的整定算法拆成多个步骤，分时执行
• 文件读写：大文件的分块读取和写入

核心思想都是一样的：把“一次性大动作”变成“分时小动作”，用扫描周期的均匀性换取实时性。

6. 常见问题与排查技巧实录

6.1 状态机不触发或重复触发

现象：状态机要么不启动，要么连续启动多次。

排查思路：

1. 检查R_TRIG实例的位置。必须在循环和条件判断之外，每个扫描周期都调用一次。
2. 检查触发信号的保持时间。如果StartRecipe只在一个扫描周期内为TRUE，R_TRIG可能来不及检测。可以在触发后加一个自保持逻辑。
3. 检查状态机的初始状态。确保上电后状态机处于IDLE，而不是停留在某个中间状态。

解决方法：用R_TRIG的Q输出直接置位一个中间变量，状态机根据这个中间变量启动，启动后立即复位中间变量。

6.2 优化后扫描周期仍然偏高

现象：用了状态机，但扫描周期还是超过5ms。

排查思路：

1. 确认字符串操作是否真的被拆分了。有时候状态机写对了，但CONCAT还在循环里。
2. 检查是否有其他耗时操作。比如HMI通信、文件写入、浮点运算等。
3. 用性能监视工具看每个程序段的耗时，找到真正的瓶颈。

解决方法：如果字符串操作已经优化，但扫描周期还是高，可能是其他任务的问题。把字符串处理移到独立任务，或者降低HMI刷新频率。

6.3 字符串拼接结果不正确

现象：优化后字符串内容缺失或顺序错乱。

排查思路：

1. 检查状态机的索引变量是否正确递增。
2. 检查CONCAT的源字符串是否在拼接前被修改。
3. 检查是否有多个状态机实例同时操作同一个字符串。

解决方法：给字符串操作加互斥锁，或者用双缓冲。一个缓冲区用于拼接，另一个用于输出，拼接完成后交换指针。

6.4 常见问题速查表

避坑技巧：状态机的状态变量一定要用枚举类型或常量定义，不要直接用数字。我见过有人用1、2、3表示状态，后来加了一个状态变成4，结果所有CASE分支都要改，漏改一个就出bug。用TYPE RecipeStateType : (IDLE, PREPARE, APPEND, FINISH); END_TYPE这样的枚举，编译器会帮你检查。

7. 实测数据与性能对比

7.1 测试环境说明

测试用的是一台中等性能的PLC，扫描周期基准设定为2ms。测试程序包含一个20工位的配方拼接逻辑，每个工位参数字符串长度约50字符。分别测试原始循环方案和状态机方案，每种方案连续运行1000次配方切换，记录扫描周期的最大值、最小值和平均值。

7.2 原始循环方案数据

原始方案的平均扫描周期看起来不高，但最大值42.3ms说明每次配方切换都会造成一次严重的周期抖动。12次超过40ms的情况可能是内存碎片导致的额外开销。

7.3 状态机方案数据

状态机方案的最大扫描周期只有2.4ms，比原始方案的最小值还稳定。1000次配方切换没有一次超过10ms，控制精度完全不受影响。

7.4 数据解读与经验总结

从数据看，状态机方案把扫描周期的抖动从40ms降到了0.4ms，改善了100倍。这个改善不是靠“更快的CPU”或“更优的编译器”实现的，纯粹是代码结构的优化。

有个细节值得注意：原始方案的平均扫描周期2.8ms看起来只比状态机的2.1ms高一点，但平均值掩盖了尖峰。在实时控制里，最坏情况比平均值重要得多。一个每1000次才出现一次的40ms尖峰，足以让设备在关键时刻掉链子。

我在实际项目中还发现，状态机方案对CPU缓存更友好。原始方案的字符串循环会反复访问大块内存，导致缓存频繁失效。状态机方案每次只访问一小块内存，缓存命中率高，实际运行时的CPU温度都低了几度。

8. 从字符串优化延伸出去的通用性能思维

8.1 扫描周期优化的三个层次

第一层是“语法级优化”，比如把CONCAT换成MEMCPY，把浮点运算换成整数运算。这类优化见效快，但天花板低，通常只能提升20%-50%。

第二层是“结构级优化”，也就是这篇文章讲的状态机拆解。把大循环拆成小步骤，把集中耗时变成分散耗时。这类优化能提升一个数量级，但需要重新设计代码结构。

第三层是“架构级优化”，把非实时任务从控制任务里剥离出去，用独立的任务或CPU核心处理。这类优化能彻底解决问题，但需要硬件支持和系统级设计。

大多数工程师停留在第一层，遇到性能问题就想着“换个更快的指令”。但真正有效的是第二层和第三层。状态机属于第二层，性价比最高。

8.2 什么时候不该用状态机

状态机不是万能的。如果字符串处理逻辑只在设备启动时执行一次，不在实时控制循环里，那用原始循环完全没问题。状态机增加了代码复杂度，引入了状态变量和触发逻辑，调试起来比简单循环麻烦。

判断标准很简单：这段代码是否在实时控制任务里？是否会被频繁触发？如果两个答案都是“是”，那就用状态机。如果有一个是“否”，可以先考虑其他优化手段。

8.3 状态机设计的通用模板

不管什么场景，状态机设计都可以套用这个模板：

1. 定义状态：用枚举类型列出所有可能的状态
2. 定义转移条件：每个状态在什么条件下转移到下一个状态
3. 定义动作：每个状态执行什么操作
4. 定义初始状态：上电后进入哪个状态
5. 定义异常处理：超时、错误、复位怎么处理

这个模板适用于任何需要分时执行的长逻辑。我做过一个多轴插补的项目，把一条复杂的空间曲线拆成200个小线段，每个扫描周期计算一个线段的位置，扫描周期稳定在1ms以内，插补精度比原来用单周期计算还高。

8.4 性能优化的心态

最后说点务实的。性能优化不是“把代码写得越复杂越好”，而是“在正确的地方用正确的方法”。我见过太多工程师为了优化而优化，把简单的逻辑写成复杂的状态机，结果bug频出，维护成本飙升。

优化的第一步永远是“测量”，确认瓶颈在哪里。第二步是“分析”，理解为什么慢。第三步才是“优化”，选择最合适的方案。跳过前两步直接优化，大概率是白费功夫。

字符串循环优化只是一个小切口，但它背后的思维——用时间换空间，用结构换性能——是通用的。你在ST语言里学到的这套方法，换到任何编程语言、任何控制系统里都适用。