【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梯形图做不了或很麻烦算法配方管理、换型ST循环、条件判断更清晰运动控制轴、凸轮ST复杂逻辑必须用 ST通讯协议Modbus、TCPST数据解析天然适合状态机流程控制STCASE 状态变量最清晰简单定时/计数梯形图一目了然复杂报警管理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 编程指南一语言基础篇更多好资源公众号搜索【阿凡工控分享】菜单栏 → 付费合集