【ST+梯形图混用实战：什么时候用什么，一张表说清楚】

前两天发了一篇 ST 编程的文章《大厂禁 ST？别被误导了，真相没那么简单》，评论区直接炸了。
一派说“ST 才是未来，梯形图早该淘汰了”，另一派说“梯形图用了二十年，ST 那玩意谁看得懂”。两派吵得不可开交，跟当年选西门子还是三菱似的。

我看了留言区，发现：真正的高手，从来不站队。

屋昂王：

现在 PLC 行业有个鄙视链，能写 ST 语言非常看不起写梯形图的，实际上真没有必要。本身编程语言没有高低贵贱之分，能用、会用、巧用就行。再说 PLC 诞生的就是要一种编程简单、传统老电工师傅能维护的编程方法，这才出现了梯形图。这两种语言各有各的优势，没有必要互相诋毁。能把机台动作写出来，不会莫名其妙死机，UPH 优化合理就是个好的程序。再说，现在 PLC 行业没有统一模板，看其他人程序都会吃力，能在短时间内查找修改别人程序、不抱怨，也是个优秀工程师必备的技能。

朱香荣：

说实话，一个项目我两种语言都用。ST 的出现不是为了取代梯形图，逻辑控制、自动流程这里用梯形图就是简单好用啊！数据处理、工艺计算这一块是 ST 的优势，大量的计算用梯形图写死你。电气工程师本来就要持续学习，不接受 ST 那也是不行的，基本上所有的 PLC 都支持两种语言同时使用。

ST 和梯形图不是谁替代谁的关系，是互补关系。

用错场景才是问题，不是语言本身。

以我自己来说。我最早是从汽车电子入行，整条线十几个工位，配方要管几十种产品，还要跟 MES 系统做 TCP 通讯。这种项目你要是全用梯形图写，光配方管理那块就能把你写崩溃。但你要是全用 ST 写，现场调试的时候，电工师傅看着一屏幕的代码，根本不知道设备现在跑到哪一步了。入行的时候基本上都采用的三菱的梯形图，后面发现 GX WORK3 也支持 ST 语言。

最后我的方案是：主流程用梯形图，配方管理和通讯用 ST。主流程就是设备的启停、互锁、气缸动作这些，梯形图画出来一目了然，谁来了都能看懂。配方管理、换型逻辑、TCP 数据收发这些，封装成 ST 功能块，在梯形图里直接调用。调试的时候，电工看梯形图监控设备状态，我改配方逻辑就进 ST 功能块里改，各干各的，谁也不碍着谁。

后来设备交付了，我师傅说客户的反馈特别好——“这个程序我们看得懂。”就这一句话，比什么技术指标都管用。

下面我挨个说，都是项目里踩过的坑。

简单逻辑用梯形图，这没什么好犹豫的。电机启停、互锁保护、限位信号处理，这些逻辑用梯形图画出来，就跟电路图一样，电工师傅扫一眼就知道信号从哪来、到哪去。你非要改成 ST，写一堆IF StartBtn AND NOT StopBtn AND NOT Overload THEN Motor := TRUE; END_IF;，维护的人看着不骂你才怪。记住，程序不是写给你自己看的，是写给后面可能来维护的人看的。

数据处理这块，梯形图是真的不行。比如你要把一批温度数据存到数组里，再做平均值滤波，梯形图怎么做？你得一个一个地址去搬，写几十个 MOVE 指令，改起来还容易出错。ST 里一个 FOR 循环加个累加就搞定了：

AverageTemp :=0;FOR i :=1TO10DO AverageTemp :=AverageTemp + TempArray[i];END_FOR;AverageTemp :=AverageTemp /10;

三行代码，清清楚楚。你说你用梯形图写这个，得画多少个网络？

配方管理和换型，ST 是唯一选择。我做过一个项目，光配方参数就有 200 多个，包括速度、温度、位置、延时等等。不同产品切换的时候，要把对应配方下载到对应变量里。这种事用梯形图写，你得建 200 多个比较指令，再接 200 多个 MOVE，一个功能块里能给你塞上千个网络。用 ST 呢？一个配方数组加一个循环，几十行代码搞定，想加新产品就往数组里加一行。

运动控制必须用 ST，这个没什么争议。不管你用的是MC_Power、MC_MoveAbsolute还是MC_MoveVelocity，这些功能块的参数配置、状态判断、错误处理，用梯形图去接，网络图会变得密密麻麻，根本看不清逻辑。而且运动控制经常要做插补计算、位置跟踪这些，梯形图很难做。我后续会在 ST 编程指南实战案例里详细讲了运动控制怎么写，这里先不展开。

通讯协议也是 ST 的强项。Modbus RTU、Modbus TCP、Profinet 这些，核心工作就是数据包的拼装和解析。你要把寄存器地址、数据长度、校验码这些按协议格式拼成一个字节序列发出去，再把收到的字节序列拆解成实际数据。这种事梯形图能做吗？技术上能，但写出来就是灾难。ST 里用数组和指针操作，天然适合干这个。

状态机用 ST 写，是工控编程的基本功。设备的自动流程——待机、初始化、运行、暂停、报警、急停——每个状态下面要做不同的事，状态之间有跳转条件。用梯形图写状态机，你得用一堆比较指令和置位复位线圈，逻辑分散在各个网络里，很难看出整体流程。用 ST 的 CASE 语句写，整个状态机结构一目了然：

CASE MachineState OF0: // 待机 IF StartCmd THEN MachineState :=10;END_IF;10: // 初始化 HomeAllAxes();IF AllAxesHomed THEN MachineState :=20;END_IF;20: // 运行 RunProcess();IF ProcessDone THEN MachineState :=0;END_IF;END_CASE;

你看，每个状态做什么、什么条件跳到下一个状态，一眼就能看明白。

简单的定时和计数，还是梯形图方便。TON、TOF、CTU 这些指令，梯形图里拖出来接上线就能用，在线监控的时候还能直接看到定时器的当前值和状态。用 ST 写当然也可以，但调试的时候没梯形图那么直观。简单的东西就别复杂化。

复杂报警管理，建议用 ST。如果你的报警就是“温度超高就停机”，梯形图一个比较加一个线圈就够了。但实际项目中，报警管理往往很复杂——报警要有优先级、要有确认机制、要记录报警时间、要区分首次报警和持续报警、要跟 HMI 联动。这种多条件、多层级的判断，用 ST 写逻辑更清晰，也更好维护。

混用的三条原则

说了这么多场景，最后总结三条混用原则，是我这些年摸索出来的。

原则一：能让人看懂的用梯形图，让人看不懂的用 ST。

写程序之前先想想：这个设备交付以后，谁来维护？如果维护的人是电工师傅，那主流程一定要用梯形图，因为这是他们最熟悉的语言。如果维护的人是你自己或者另一个程序员，那 ST 的比例可以大一些。别为了炫技全写 ST，最后客户打电话说“你们这个程序我们看不懂”，那你口碑就砸了。

原则二：数据密集用 ST，逻辑直观用梯形图。

判断标准很简单：你的代码里有没有大量的数组、结构体、字符串操作？有没有复杂的循环和条件嵌套？如果有，用 ST。如果主要是开关量逻辑、顺控、互锁这些，用梯形图。数据越复杂，ST 的优势越明显；逻辑越简单，梯形图的优势越突出。

原则三：同一个项目里，主流程用梯形图，算法模块用 ST。

这是架构层面的混用。主流程就是设备的整体运行逻辑，用梯形图搭建框架，在需要的地方调用 ST 功能块。ST 功能块负责具体的算法实现——配方管理、通讯处理、运动控制、数据滤波等等。这样梯形图是骨架，ST 是肌肉，各司其职。调试的时候，看梯形图就知道设备整体状态，进 ST 功能块就能改具体算法。

最后说两句

混用的前提是两种语言都得会。你只会梯形图，那遇到配方管理就只能硬着头皮用梯形图堆；你只会 ST，那简单的启停逻辑也非要用 ST 写，维护的人看着头疼。

两种语言都掌握，才能在合适的场景选合适的工具，这才是真正的工程思维。

当然还要补充一点的是，如果你已经不是单打独斗的工程师，是已经有丰富开发经验的中高工，或者电气主管，在这个问题上可能更要慎重一点。从目前我观察到的趋势来看，新人对 ST 的接受程度更高，混用编程需要的门槛很高，比较难实现团队的标准化。

想系统学 ST 编程的，可以看看我的付费合集：ST 编程指南（一）：语言基础篇

更多好资源，公众号搜索【阿凡工控分享】，菜单栏 → 付费合集