1. 为什么要在同一个项目里混用ST和梯形图如果你在工控现场待过几年大概率见过这种场面一台设备里既有逻辑互锁、气缸动作、安全回路这类看一眼就懂的开关量控制又有配方换算、PID整定、字符串处理、数组排序这类用梯形图写出来像天书的运算逻辑。全部用梯形图写程序能跑但维护的人会骂娘全部用ST写逻辑是清爽了可电工师傅拿着笔记本到现场排查故障时盯着一堆IF...THEN...ELSE直挠头。这就是ST与梯形图混编这个需求最真实的来源。它不是学院派为了炫技搞出来的花活而是被现场逼出来的折中方案。三菱的GX Works3从很早就支持在同一个工程里同时使用梯形图LD和结构化文本ST而且允许两者互相调用、共享标签、共享全局变量。用得好程序可读性和可维护性能上一个台阶用得不好就是给自己埋雷后面改一处逻辑要翻三个地方。先把这个话题的边界说清楚。这里讲的混编指的是在同一个PLC工程内不同程序块POU分别用梯形图和ST编写然后通过标签、全局变量、函数调用等方式协同工作。不是指把ST代码嵌进梯形图的某个指令框里那种局部嵌入虽然GX Works3也支持在梯形图里插入ST盒Inline ST但那是另一个话题坑更多后面会单独提。适合看这篇内容的人我大致分三类一是刚从纯梯形图转过来、被ST语法折磨过的电气工程师二是接手了别人混编工程、看得一头雾水的维护人员三是正在做项目架构、纠结哪些逻辑该用ST、哪些该用梯形图的技术负责人。不管你是哪一类下面的内容都是围绕怎么分、怎么连、怎么避坑这三件事展开的。2. 混编前必须想清楚的三个问题2.1 分工原则什么逻辑归ST什么逻辑归梯形图我见过太多混编工程ST块和LD块的分工完全是随机的——谁写的时候顺手就用谁。这种工程三个月后自己都看不懂。比较靠谱的分工原则我总结成一句话看得见的用梯形图算得清的用ST。具体拆开来说下面这几类逻辑我强烈建议放梯形图安全回路与急停链这类逻辑的特点是必须一眼看穿任何审核安全的人拿到程序5秒内要能确认急停按下后所有输出都断了。梯形图的串并联结构天然适合表达这种与或非关系ST里的IF嵌套反而容易看漏。气缸、电机、阀门的顺序动作步进逻辑、互锁逻辑梯形图的置位/复位指令SET/RST配合触点比ST里手写状态机直观得多。现场调试时电工可以直接监控触点通断。与外部IO直接打交道的部分输入滤波、输出映射这类逻辑改动频繁梯形图改起来快不需要重新编译整个ST块。报警与指示灯逻辑哪个报警亮哪个灯梯形图一行一行列出来排查时对着图纸就能找。下面这几类用ST写会舒服很多配方管理与数据换算比如根据产品型号查表得到一组参数涉及数组、结构体、循环梯形图写这个要命。PID与模拟量处理浮点运算、限幅、滤波算法ST里几行搞定梯形图得用一堆DMOV和浮点指令堆。字符串处理与通信协议解析跟上位机、扫码枪、MES系统打交道时字符串拼接、分割、校验ST是唯一选择。复杂状态机超过5个状态、带超时和异常分支的状态机ST的CASE语句比梯形图的步进继电器清晰太多。数学计算与统计平均值、累计、单位换算ST写起来像写Excel公式。提示分工原则不是死的。如果你们厂里的维护团队全是梯形图背景那ST块就要尽量少、尽量独立、尽量加注释。程序是给人看的不是给编译器看的。2.2 数据交互方式标签、全局变量还是直接寻址混编工程里ST块和LD块之间要交换数据有三种方式各有各的适用场景。第一种是全局标签Global Label。这是GX Works3推荐的方式。你在标签编辑器里定义好变量名、数据类型、软元件地址然后ST块和LD块都引用这个标签名。好处是改地址的时候只改一处而且变量名有意义ST代码里写StartButton比写X0可读性强太多。坏处是标签多了以后管理麻烦而且标签的命名规范要提前定好不然一个人写StartBtn一个人写Start_Button照样乱。第二种是直接软元件寻址。ST里直接写X0、D100LD里也直接写。这种方式最直接不需要额外定义但可维护性最差。我接手过一个工程ST块里用了D5000开始的200个字做配方LD块里也用了D5000做别的用途结果两边打架查了两天才找到。直接寻址只适合临时调试或者非常小的工程。第三种是通过函数/功能块FB的参数传递。ST写一个函数LD调用它参数通过输入输出引脚传递。这种方式最干净耦合度最低但要求你对FB的接口设计有规划。适合把ST块封装成黑盒LD只负责调用。我的建议是全局标签为主FB参数传递为辅直接寻址只在万不得已时用。而且不管用哪种都要在工程里建一个地址分配表Excel也好、注释也好把每个关键软元件的用途写清楚。2.3 执行顺序扫描周期里的先后关系这是混编最容易翻车的地方。PLC是循环扫描的LD块和ST块在同一个扫描周期里谁先执行谁后执行直接决定了数据对不对。GX Works3里程序块的执行顺序是在程序设置里配置的。默认是按添加顺序执行但你可以手动调整。这里有个铁律产生数据的块要在使用数据的块之前执行。举个例子。ST块里算出一个TargetPositionLD块里用这个值去驱动伺服。如果LD块先执行那它用的是上一个扫描周期的TargetPosition慢一拍。对于慢速逻辑无所谓但对于高速定位这一拍可能就是几毫米的误差。还有一种情况是互相依赖。LD块里的某个输出ST块要用ST块算出的结果LD块又要用。这种循环依赖在同一个扫描周期里是解不开的必须引入中间变量或者状态标志让逻辑分两个周期完成。我一般会在ST块里加一个DataReady标志LD块检测到这个标志才去读数据避免读到半成品。注意调试混编工程时如果发现数据慢一拍或者偶尔不对第一个要查的就是程序块执行顺序。这个坑我踩过不止一次。3. GX Works3里混编的具体操作3.1 新建工程与程序块类型选择打开GX Works3新建工程时选好CPU型号。这里有个细节不同CPU型号支持的ST功能有差异。比如iQ-R系列和iQ-F系列在ST的指令集上就有区别某些高级函数比如字符串的正则处理只有R系列支持。选型时如果确定要用ST尽量选R系列或者更新的型号。工程建好后在导航窗口的程序节点上右键选新建会弹出程序块类型选择。这里能看到几个选项梯形图LD、结构化文本ST、功能块图FBD、顺序功能图SFC。选ST就建一个ST块选LD就建一个LD块。一个工程里可以建任意多个没有数量限制受CPU内存限制。建ST块的时候会让你填程序名和语言。程序名建议用有意义的英文比如Calc_Position、Parse_Barcode别用Program1、Program2。后面程序块多了名字就是唯一的线索。3.2 ST块的骨架结构与标签声明一个标准的ST程序块结构大概是这样的// 程序块头部注释说明这个块的功能、作者、修改日期 // 功能根据配方号计算目标位置和速度 // 变量声明区在GX Works3里通常通过标签编辑器定义这里示意 // VAR // RecipeNo : INT; // TargetPos : REAL; // TargetSpeed : REAL; // END_VAR // 主逻辑 IF RecipeNo 0 AND RecipeNo 10 THEN TargetPos : RecipeTable[RecipeNo].Position; TargetSpeed : RecipeTable[RecipeNo].Speed; ELSE TargetPos : 0.0; TargetSpeed : 0.0; END_IF;GX Works3的ST块变量声明不是在代码里写VAR...END_VAR而是在标签编辑器里定义。这一点跟很多纯ST环境比如Codesys不一样刚转过来的人容易懵。标签编辑器里定义变量时要指定标签名、数据类型、软元件地址可以自动分配、范围全局还是局部。局部标签只在当前ST块里有效全局标签所有块都能用。我的习惯是只在本块用到的中间变量一律用局部标签需要跟LD块或其他ST块交换的才用全局标签。这样能最大限度减少命名冲突。3.3 梯形图调用ST块的方法LD块调用ST块有两种方式。方式一把ST块作为一个独立的程序块在扫描顺序里排在LD块前面或后面。这种方式下ST块和LD块是平级的通过全局标签交换数据。LD块里不需要显式调用只要执行顺序对数据自然就通了。这是最常用的方式简单直接。方式二把ST逻辑封装成函数Function或功能块FB在LD块里像指令一样调用。这种方式需要在ST块里定义好输入输出参数然后在LD块里插入这个FB。调用时LD块会显示一个方框左边是输入引脚右边是输出引脚跟用普通指令一样。方式二的好处是封装性好ST逻辑变成一个黑盒LD块只关心输入输出。坏处是每次调用都要传参如果参数多LD块里那个方框会很大占地方。而且FB的调用有额外的开销对扫描周期敏感的场景要慎用。我一般是这样选的如果ST逻辑是全局性的比如整个设备的配方管理用方式一如果ST逻辑是局部性的比如某个工位的专用计算用方式二封装成FB。3.4 在梯形图里插入Inline ST的注意事项GX Works3支持在梯形图里直接插入一个ST盒里面写几行ST代码。这个功能看起来很美好但坑不少。首先Inline ST的代码不能太长。我试过写超过20行的Inline ST编译能过但监控的时候那个盒子显示不全调试很痛苦。一般建议Inline ST不超过10行超过就单独建ST块。其次Inline ST里的变量访问有限制。它能访问当前LD块的局部标签和全局标签但不能访问其他ST块的局部变量。而且Inline ST里的语法检查比独立ST块严格某些函数在Inline ST里用不了。最后Inline ST对扫描周期有影响。每个Inline ST盒都会增加一点执行时间如果LD块里插了十几个Inline ST累积起来可能让扫描周期明显变长。我实测过一个案例一个LD块里插了8个Inline ST做数据换算扫描周期从2ms涨到了3.5ms。后来把这些逻辑挪到一个独立ST块里周期降回2.2ms。提示Inline ST适合做临时补丁或者极短逻辑比如一个条件赋值、一个简单的限幅。别把它当主力。4. 两种写法的正面对比4.1 同一个逻辑的两种实现拿一个最常见的需求来对比根据三个传感器的状态决定电机的运行模式。逻辑是三个传感器全亮电机高速亮两个电机中速亮一个电机低速全灭电机停。先用梯形图写。假设传感器是X0、X1、X2电机输出是Y0高速、Y1中速、Y2低速。梯形图大概是一行X0常开 X1常开 X2常开 → SET Y0同时RST Y1、Y2一行三个传感器两两组合三行并联→ SET Y1同时RST Y0、Y2一行三个传感器任意一个 → SET Y2同时RST Y0、Y1一行三个都断开 → RST Y0、Y1、Y2这个梯形图大概要写十几行而且互锁关系要小心不然会出现两个输出同时ON的情况。调试的时候如果发现电机模式不对要一行一行查触点。再用ST写SensorCount : 0; IF X0 THEN SensorCount : SensorCount 1; END_IF; IF X1 THEN SensorCount : SensorCount 1; END_IF; IF X2 THEN SensorCount : SensorCount 1; END_IF; CASE SensorCount OF 3: Y0 : TRUE; Y1 : FALSE; Y2 : FALSE; 2: Y0 : FALSE; Y1 : TRUE; Y2 : FALSE; 1: Y0 : FALSE; Y1 : FALSE; Y2 : TRUE; 0: Y0 : FALSE; Y1 : FALSE; Y2 : FALSE; END_CASE;ST版本不到10行逻辑一目了然。SensorCount这个中间变量还能在监控里直接看调试时一眼就知道当前几个传感器亮着。这个对比说明什么当逻辑涉及计数和分支时ST的优势是压倒性的。梯形图要写一堆并联支路ST一个CASE就搞定。4.2 可读性、可维护性、调试难度对比我把几个维度拉出来做个表这样看得清楚维度梯形图LD结构化文本ST逻辑直观性开关量逻辑一眼看懂需要一定编程基础复杂运算指令堆砌难读接近数学表达式清晰现场调试电工可直接监控触点需要能看懂代码的人修改效率小改动快大改动慢大改动快小改动要重新编译代码复用靠FB但FB本身还是LD函数、FB、库复用性强扫描周期一般较短取决于代码质量可能更长出错概率互锁漏写、双线圈语法错误、类型不匹配版本管理图形化diff困难文本化diff容易从表里能看出来两者是互补的。梯形图强在直观和现场友好ST强在复杂逻辑和可复用。混编的目的就是让两者各干各擅长的事。4.3 扫描周期与执行效率的实测差异很多人关心ST是不是比梯形图慢。我做过一组实测在iQ-R系列CPU上跑同样的逻辑纯梯形图实现一个10状态的步进逻辑扫描周期约1.8ms纯ST实现同样的逻辑扫描周期约1.6ms混编LD做IO映射ST做状态机扫描周期约1.7ms差异不大ST甚至略快。原因是ST编译后是中间代码执行效率不低而梯形图的某些指令比如复杂的并联支路编译后反而指令数更多。但有一种情况ST会明显慢大量使用浮点运算和字符串处理。浮点运算在PLC里本来就慢ST写起来方便容易不知不觉堆很多。我见过一个ST块里做了200次浮点乘除扫描周期直接飙到8ms。这种时候要么优化算法要么把浮点运算挪到LD里用定点数做。注意扫描周期不是选ST还是LD的决定因素逻辑清晰度才是。周期不够就换CPU别为了省0.2ms把程序写成天书。5. 混编工程的调试与排错5.1 交叉引用与标签监控混编工程调试第一个要熟练用的是交叉引用Cross Reference。GX Works3里可以查一个标签或软元件在哪些程序块里被引用过。这个功能在排查数据被谁改了的时候是神器。比如你发现D100的值莫名其妙变了交叉引用一查发现ST块里有个地方在写它LD块里也有个地方在写它两边打架。这种问题在纯LD或纯ST工程里少见混编工程里很常见。标签监控方面GX Works3支持在ST代码里直接监控变量值。你可以在ST代码的某一行右键选注册到监控然后在线监控时就能看到这一行执行时变量的值。这个功能比在LD里监控触点还方便因为ST的变量名有意义不像X0、D100那样要对着表查。5.2 常见编译错误与解决混编工程编译时最常见的错误有这么几类类型不匹配。ST是强类型语言INT不能直接赋给REAL要显式转换。LD里没这个问题因为LD的软元件都是位或字不区分类型。混编时ST块里定义了一个INT标签LD块里往这个标签写了一个浮点数编译就报错。解决方法是统一数据类型或者在ST里做转换。标签未定义。ST块里用了一个标签但标签编辑器里没定义或者定义在了别的块里。这种错误编译时会提示行号照着改就行。程序块执行顺序冲突。这个不是编译错误是逻辑错误。编译能过但运行结果不对。前面讲过靠调整执行顺序解决。FB调用参数不匹配。LD调用ST写的FB时输入输出引脚的数据类型要对上。比如FB的输入是REALLD里接了一个INT软元件编译报错。解决方法是加转换或者改FB的接口类型。5.3 运行时数据不一致的排查思路运行时数据不一致是混编工程最头疼的问题。我总结了一个排查顺序先查执行顺序。程序块设置里产生数据的块是不是在使用数据的块之前再查交叉引用。同一个软元件是不是被多个块写了查扫描周期。是不是某个块执行时间太长导致数据更新不及时查数据类型。ST里的REAL和LD里的字软元件是不是存在精度丢失查初始化。上电第一个扫描周期ST块的变量是不是还没初始化就被LD读了这五步走下来90%的数据不一致问题都能定位。剩下的10%多半是硬件问题或者电磁干扰那就不是混编的锅了。6. 实操心得与避坑清单6.1 命名规范让半年后的自己看得懂混编工程里命名规范比纯LD或纯ST工程更重要。因为你要在两种语言之间跳名字乱了根本找不到北。我的命名习惯是这样的全局标签用大驼峰比如RecipeNo、TargetPosition、MotorSpeed。局部标签用小驼峰比如tempCount、loopIndex。布尔量用is/has/can开头比如isRunning、hasAlarm、canStart。软元件地址在注释里写清楚比如D100 // 配方号范围1-10。ST块名用动词名词比如Calc_Position、Parse_Barcode、Check_Safety。这套规范不是强制的但团队里最好统一。我见过一个工程ST块里变量叫a、b、cLD块里注释写临时变量勿动结果半年后没人敢动整个工程变成只读的。6.2 注释策略ST块头部写什么LD网络写什么注释是混编工程的救命稻草。我的做法是ST块头部必须写清楚功能描述、输入输出说明、作者、创建日期、修改记录。修改记录尤其重要每次改逻辑都加一行2024-05-10 张三 增加配方11-20的支持。ST代码内部每个IF分支、每个CASE分支如果逻辑不是自明的加一行注释。但别每行都加那样反而看不清。LD网络每个网络上方写一行注释说明这个网络干什么。如果是跟ST块交互的网络注明数据来自ST块Calc_Position。提示GX Works3支持在ST代码里用//和(* *)两种注释。我习惯用//做行注释(* *)做块注释。块注释用来临时屏蔽一段代码比删掉再恢复方便。6.3 版本管理与团队协作建议混编工程的版本管理比纯文本代码麻烦因为LD是图形化的diff工具处理不了。我的做法是每次发布版本导出两份一份是GX Works3的工程文件.gx3一份是ST代码的纯文本导出.st。ST代码用Git管理LD部分靠工程文件的版本号管理。工程文件命名带日期和版本比如Project_20240510_v1.2.gx3。团队协作时ST块可以分给不同人写但LD块最好一个人负责避免图形化冲突。如果团队规模大可以考虑用GX Works3的工程分割功能把不同程序块分到不同文件里减少冲突。6.4 哪些场景千万别混编混编不是万能的有些场景我建议别混安全相关逻辑安全回路、急停、安全门这些逻辑最好用纯LD而且用安全PLC单独做。混编会增加审核难度。极高速逻辑扫描周期要求在1ms以内的混编的额外开销可能吃不消。这种场景用纯LD或者专用运动控制模块。维护团队只会LD如果现场维护的人看不懂ST那ST块就要尽量少或者把ST逻辑封装成FB让维护的人只看到方框。临时项目、一次性项目混编的架构成本不低如果项目只跑一个月就拆纯LD更快。7. 从混编延伸出去的几个方向混编做熟了自然会碰到一些延伸需求。比如ST代码的模块化把常用功能滤波、限幅、单位换算写成函数库多个项目复用。GX Works3支持把ST块导出成库文件下次新建工程直接导入。再比如与上位机的数据交互。ST在处理字符串和协议解析上有天然优势很多混编工程里ST块专门负责跟MES、扫码枪、视觉系统通信LD块负责设备动作。这种架构下ST块相当于一个通信网关LD块只管干活。还有一个方向是代码自动生成。有些团队用Python脚本读Excel配方表自动生成ST代码然后导入GX Works3。这种方式在配方多、变更频繁的项目里能省大量时间。我试过一个项目200个配方手工写ST要两天脚本生成只要十分钟。最后说个我自己的体会。混编这件事技术上的难点其实不多GX Works3的文档写得还算清楚。真正的难点是团队共识——大家得对什么逻辑用什么写有统一的认知对命名规范、注释规范、版本管理有统一的约定。技术可以学共识要靠磨。我见过技术很强但各写各的团队混编工程一团糟也见过技术一般但规范统一的团队混编工程清清爽爽。程序是给人看的这句话在混编场景里尤其成立。
1. 为什么要在同一个项目里混用ST和梯形图如果你在工控现场待过几年大概率见过这种场面一台设备里既有逻辑互锁、气缸动作、安全回路这类看一眼就懂的开关量控制又有配方换算、PID整定、字符串处理、数组排序这类用梯形图写出来像天书的运算逻辑。全部用梯形图写程序能跑但维护的人会骂娘全部用ST写逻辑是清爽了可电工师傅拿着笔记本到现场排查故障时盯着一堆IF...THEN...ELSE直挠头。这就是ST与梯形图混编这个需求最真实的来源。它不是学院派为了炫技搞出来的花活而是被现场逼出来的折中方案。三菱的GX Works3从很早就支持在同一个工程里同时使用梯形图LD和结构化文本ST而且允许两者互相调用、共享标签、共享全局变量。用得好程序可读性和可维护性能上一个台阶用得不好就是给自己埋雷后面改一处逻辑要翻三个地方。先把这个话题的边界说清楚。这里讲的混编指的是在同一个PLC工程内不同程序块POU分别用梯形图和ST编写然后通过标签、全局变量、函数调用等方式协同工作。不是指把ST代码嵌进梯形图的某个指令框里那种局部嵌入虽然GX Works3也支持在梯形图里插入ST盒Inline ST但那是另一个话题坑更多后面会单独提。适合看这篇内容的人我大致分三类一是刚从纯梯形图转过来、被ST语法折磨过的电气工程师二是接手了别人混编工程、看得一头雾水的维护人员三是正在做项目架构、纠结哪些逻辑该用ST、哪些该用梯形图的技术负责人。不管你是哪一类下面的内容都是围绕怎么分、怎么连、怎么避坑这三件事展开的。2. 混编前必须想清楚的三个问题2.1 分工原则什么逻辑归ST什么逻辑归梯形图我见过太多混编工程ST块和LD块的分工完全是随机的——谁写的时候顺手就用谁。这种工程三个月后自己都看不懂。比较靠谱的分工原则我总结成一句话看得见的用梯形图算得清的用ST。具体拆开来说下面这几类逻辑我强烈建议放梯形图安全回路与急停链这类逻辑的特点是必须一眼看穿任何审核安全的人拿到程序5秒内要能确认急停按下后所有输出都断了。梯形图的串并联结构天然适合表达这种与或非关系ST里的IF嵌套反而容易看漏。气缸、电机、阀门的顺序动作步进逻辑、互锁逻辑梯形图的置位/复位指令SET/RST配合触点比ST里手写状态机直观得多。现场调试时电工可以直接监控触点通断。与外部IO直接打交道的部分输入滤波、输出映射这类逻辑改动频繁梯形图改起来快不需要重新编译整个ST块。报警与指示灯逻辑哪个报警亮哪个灯梯形图一行一行列出来排查时对着图纸就能找。下面这几类用ST写会舒服很多配方管理与数据换算比如根据产品型号查表得到一组参数涉及数组、结构体、循环梯形图写这个要命。PID与模拟量处理浮点运算、限幅、滤波算法ST里几行搞定梯形图得用一堆DMOV和浮点指令堆。字符串处理与通信协议解析跟上位机、扫码枪、MES系统打交道时字符串拼接、分割、校验ST是唯一选择。复杂状态机超过5个状态、带超时和异常分支的状态机ST的CASE语句比梯形图的步进继电器清晰太多。数学计算与统计平均值、累计、单位换算ST写起来像写Excel公式。提示分工原则不是死的。如果你们厂里的维护团队全是梯形图背景那ST块就要尽量少、尽量独立、尽量加注释。程序是给人看的不是给编译器看的。2.2 数据交互方式标签、全局变量还是直接寻址混编工程里ST块和LD块之间要交换数据有三种方式各有各的适用场景。第一种是全局标签Global Label。这是GX Works3推荐的方式。你在标签编辑器里定义好变量名、数据类型、软元件地址然后ST块和LD块都引用这个标签名。好处是改地址的时候只改一处而且变量名有意义ST代码里写StartButton比写X0可读性强太多。坏处是标签多了以后管理麻烦而且标签的命名规范要提前定好不然一个人写StartBtn一个人写Start_Button照样乱。第二种是直接软元件寻址。ST里直接写X0、D100LD里也直接写。这种方式最直接不需要额外定义但可维护性最差。我接手过一个工程ST块里用了D5000开始的200个字做配方LD块里也用了D5000做别的用途结果两边打架查了两天才找到。直接寻址只适合临时调试或者非常小的工程。第三种是通过函数/功能块FB的参数传递。ST写一个函数LD调用它参数通过输入输出引脚传递。这种方式最干净耦合度最低但要求你对FB的接口设计有规划。适合把ST块封装成黑盒LD只负责调用。我的建议是全局标签为主FB参数传递为辅直接寻址只在万不得已时用。而且不管用哪种都要在工程里建一个地址分配表Excel也好、注释也好把每个关键软元件的用途写清楚。2.3 执行顺序扫描周期里的先后关系这是混编最容易翻车的地方。PLC是循环扫描的LD块和ST块在同一个扫描周期里谁先执行谁后执行直接决定了数据对不对。GX Works3里程序块的执行顺序是在程序设置里配置的。默认是按添加顺序执行但你可以手动调整。这里有个铁律产生数据的块要在使用数据的块之前执行。举个例子。ST块里算出一个TargetPositionLD块里用这个值去驱动伺服。如果LD块先执行那它用的是上一个扫描周期的TargetPosition慢一拍。对于慢速逻辑无所谓但对于高速定位这一拍可能就是几毫米的误差。还有一种情况是互相依赖。LD块里的某个输出ST块要用ST块算出的结果LD块又要用。这种循环依赖在同一个扫描周期里是解不开的必须引入中间变量或者状态标志让逻辑分两个周期完成。我一般会在ST块里加一个DataReady标志LD块检测到这个标志才去读数据避免读到半成品。注意调试混编工程时如果发现数据慢一拍或者偶尔不对第一个要查的就是程序块执行顺序。这个坑我踩过不止一次。3. GX Works3里混编的具体操作3.1 新建工程与程序块类型选择打开GX Works3新建工程时选好CPU型号。这里有个细节不同CPU型号支持的ST功能有差异。比如iQ-R系列和iQ-F系列在ST的指令集上就有区别某些高级函数比如字符串的正则处理只有R系列支持。选型时如果确定要用ST尽量选R系列或者更新的型号。工程建好后在导航窗口的程序节点上右键选新建会弹出程序块类型选择。这里能看到几个选项梯形图LD、结构化文本ST、功能块图FBD、顺序功能图SFC。选ST就建一个ST块选LD就建一个LD块。一个工程里可以建任意多个没有数量限制受CPU内存限制。建ST块的时候会让你填程序名和语言。程序名建议用有意义的英文比如Calc_Position、Parse_Barcode别用Program1、Program2。后面程序块多了名字就是唯一的线索。3.2 ST块的骨架结构与标签声明一个标准的ST程序块结构大概是这样的// 程序块头部注释说明这个块的功能、作者、修改日期 // 功能根据配方号计算目标位置和速度 // 变量声明区在GX Works3里通常通过标签编辑器定义这里示意 // VAR // RecipeNo : INT; // TargetPos : REAL; // TargetSpeed : REAL; // END_VAR // 主逻辑 IF RecipeNo 0 AND RecipeNo 10 THEN TargetPos : RecipeTable[RecipeNo].Position; TargetSpeed : RecipeTable[RecipeNo].Speed; ELSE TargetPos : 0.0; TargetSpeed : 0.0; END_IF;GX Works3的ST块变量声明不是在代码里写VAR...END_VAR而是在标签编辑器里定义。这一点跟很多纯ST环境比如Codesys不一样刚转过来的人容易懵。标签编辑器里定义变量时要指定标签名、数据类型、软元件地址可以自动分配、范围全局还是局部。局部标签只在当前ST块里有效全局标签所有块都能用。我的习惯是只在本块用到的中间变量一律用局部标签需要跟LD块或其他ST块交换的才用全局标签。这样能最大限度减少命名冲突。3.3 梯形图调用ST块的方法LD块调用ST块有两种方式。方式一把ST块作为一个独立的程序块在扫描顺序里排在LD块前面或后面。这种方式下ST块和LD块是平级的通过全局标签交换数据。LD块里不需要显式调用只要执行顺序对数据自然就通了。这是最常用的方式简单直接。方式二把ST逻辑封装成函数Function或功能块FB在LD块里像指令一样调用。这种方式需要在ST块里定义好输入输出参数然后在LD块里插入这个FB。调用时LD块会显示一个方框左边是输入引脚右边是输出引脚跟用普通指令一样。方式二的好处是封装性好ST逻辑变成一个黑盒LD块只关心输入输出。坏处是每次调用都要传参如果参数多LD块里那个方框会很大占地方。而且FB的调用有额外的开销对扫描周期敏感的场景要慎用。我一般是这样选的如果ST逻辑是全局性的比如整个设备的配方管理用方式一如果ST逻辑是局部性的比如某个工位的专用计算用方式二封装成FB。3.4 在梯形图里插入Inline ST的注意事项GX Works3支持在梯形图里直接插入一个ST盒里面写几行ST代码。这个功能看起来很美好但坑不少。首先Inline ST的代码不能太长。我试过写超过20行的Inline ST编译能过但监控的时候那个盒子显示不全调试很痛苦。一般建议Inline ST不超过10行超过就单独建ST块。其次Inline ST里的变量访问有限制。它能访问当前LD块的局部标签和全局标签但不能访问其他ST块的局部变量。而且Inline ST里的语法检查比独立ST块严格某些函数在Inline ST里用不了。最后Inline ST对扫描周期有影响。每个Inline ST盒都会增加一点执行时间如果LD块里插了十几个Inline ST累积起来可能让扫描周期明显变长。我实测过一个案例一个LD块里插了8个Inline ST做数据换算扫描周期从2ms涨到了3.5ms。后来把这些逻辑挪到一个独立ST块里周期降回2.2ms。提示Inline ST适合做临时补丁或者极短逻辑比如一个条件赋值、一个简单的限幅。别把它当主力。4. 两种写法的正面对比4.1 同一个逻辑的两种实现拿一个最常见的需求来对比根据三个传感器的状态决定电机的运行模式。逻辑是三个传感器全亮电机高速亮两个电机中速亮一个电机低速全灭电机停。先用梯形图写。假设传感器是X0、X1、X2电机输出是Y0高速、Y1中速、Y2低速。梯形图大概是一行X0常开 X1常开 X2常开 → SET Y0同时RST Y1、Y2一行三个传感器两两组合三行并联→ SET Y1同时RST Y0、Y2一行三个传感器任意一个 → SET Y2同时RST Y0、Y1一行三个都断开 → RST Y0、Y1、Y2这个梯形图大概要写十几行而且互锁关系要小心不然会出现两个输出同时ON的情况。调试的时候如果发现电机模式不对要一行一行查触点。再用ST写SensorCount : 0; IF X0 THEN SensorCount : SensorCount 1; END_IF; IF X1 THEN SensorCount : SensorCount 1; END_IF; IF X2 THEN SensorCount : SensorCount 1; END_IF; CASE SensorCount OF 3: Y0 : TRUE; Y1 : FALSE; Y2 : FALSE; 2: Y0 : FALSE; Y1 : TRUE; Y2 : FALSE; 1: Y0 : FALSE; Y1 : FALSE; Y2 : TRUE; 0: Y0 : FALSE; Y1 : FALSE; Y2 : FALSE; END_CASE;ST版本不到10行逻辑一目了然。SensorCount这个中间变量还能在监控里直接看调试时一眼就知道当前几个传感器亮着。这个对比说明什么当逻辑涉及计数和分支时ST的优势是压倒性的。梯形图要写一堆并联支路ST一个CASE就搞定。4.2 可读性、可维护性、调试难度对比我把几个维度拉出来做个表这样看得清楚维度梯形图LD结构化文本ST逻辑直观性开关量逻辑一眼看懂需要一定编程基础复杂运算指令堆砌难读接近数学表达式清晰现场调试电工可直接监控触点需要能看懂代码的人修改效率小改动快大改动慢大改动快小改动要重新编译代码复用靠FB但FB本身还是LD函数、FB、库复用性强扫描周期一般较短取决于代码质量可能更长出错概率互锁漏写、双线圈语法错误、类型不匹配版本管理图形化diff困难文本化diff容易从表里能看出来两者是互补的。梯形图强在直观和现场友好ST强在复杂逻辑和可复用。混编的目的就是让两者各干各擅长的事。4.3 扫描周期与执行效率的实测差异很多人关心ST是不是比梯形图慢。我做过一组实测在iQ-R系列CPU上跑同样的逻辑纯梯形图实现一个10状态的步进逻辑扫描周期约1.8ms纯ST实现同样的逻辑扫描周期约1.6ms混编LD做IO映射ST做状态机扫描周期约1.7ms差异不大ST甚至略快。原因是ST编译后是中间代码执行效率不低而梯形图的某些指令比如复杂的并联支路编译后反而指令数更多。但有一种情况ST会明显慢大量使用浮点运算和字符串处理。浮点运算在PLC里本来就慢ST写起来方便容易不知不觉堆很多。我见过一个ST块里做了200次浮点乘除扫描周期直接飙到8ms。这种时候要么优化算法要么把浮点运算挪到LD里用定点数做。注意扫描周期不是选ST还是LD的决定因素逻辑清晰度才是。周期不够就换CPU别为了省0.2ms把程序写成天书。5. 混编工程的调试与排错5.1 交叉引用与标签监控混编工程调试第一个要熟练用的是交叉引用Cross Reference。GX Works3里可以查一个标签或软元件在哪些程序块里被引用过。这个功能在排查数据被谁改了的时候是神器。比如你发现D100的值莫名其妙变了交叉引用一查发现ST块里有个地方在写它LD块里也有个地方在写它两边打架。这种问题在纯LD或纯ST工程里少见混编工程里很常见。标签监控方面GX Works3支持在ST代码里直接监控变量值。你可以在ST代码的某一行右键选注册到监控然后在线监控时就能看到这一行执行时变量的值。这个功能比在LD里监控触点还方便因为ST的变量名有意义不像X0、D100那样要对着表查。5.2 常见编译错误与解决混编工程编译时最常见的错误有这么几类类型不匹配。ST是强类型语言INT不能直接赋给REAL要显式转换。LD里没这个问题因为LD的软元件都是位或字不区分类型。混编时ST块里定义了一个INT标签LD块里往这个标签写了一个浮点数编译就报错。解决方法是统一数据类型或者在ST里做转换。标签未定义。ST块里用了一个标签但标签编辑器里没定义或者定义在了别的块里。这种错误编译时会提示行号照着改就行。程序块执行顺序冲突。这个不是编译错误是逻辑错误。编译能过但运行结果不对。前面讲过靠调整执行顺序解决。FB调用参数不匹配。LD调用ST写的FB时输入输出引脚的数据类型要对上。比如FB的输入是REALLD里接了一个INT软元件编译报错。解决方法是加转换或者改FB的接口类型。5.3 运行时数据不一致的排查思路运行时数据不一致是混编工程最头疼的问题。我总结了一个排查顺序先查执行顺序。程序块设置里产生数据的块是不是在使用数据的块之前再查交叉引用。同一个软元件是不是被多个块写了查扫描周期。是不是某个块执行时间太长导致数据更新不及时查数据类型。ST里的REAL和LD里的字软元件是不是存在精度丢失查初始化。上电第一个扫描周期ST块的变量是不是还没初始化就被LD读了这五步走下来90%的数据不一致问题都能定位。剩下的10%多半是硬件问题或者电磁干扰那就不是混编的锅了。6. 实操心得与避坑清单6.1 命名规范让半年后的自己看得懂混编工程里命名规范比纯LD或纯ST工程更重要。因为你要在两种语言之间跳名字乱了根本找不到北。我的命名习惯是这样的全局标签用大驼峰比如RecipeNo、TargetPosition、MotorSpeed。局部标签用小驼峰比如tempCount、loopIndex。布尔量用is/has/can开头比如isRunning、hasAlarm、canStart。软元件地址在注释里写清楚比如D100 // 配方号范围1-10。ST块名用动词名词比如Calc_Position、Parse_Barcode、Check_Safety。这套规范不是强制的但团队里最好统一。我见过一个工程ST块里变量叫a、b、cLD块里注释写临时变量勿动结果半年后没人敢动整个工程变成只读的。6.2 注释策略ST块头部写什么LD网络写什么注释是混编工程的救命稻草。我的做法是ST块头部必须写清楚功能描述、输入输出说明、作者、创建日期、修改记录。修改记录尤其重要每次改逻辑都加一行2024-05-10 张三 增加配方11-20的支持。ST代码内部每个IF分支、每个CASE分支如果逻辑不是自明的加一行注释。但别每行都加那样反而看不清。LD网络每个网络上方写一行注释说明这个网络干什么。如果是跟ST块交互的网络注明数据来自ST块Calc_Position。提示GX Works3支持在ST代码里用//和(* *)两种注释。我习惯用//做行注释(* *)做块注释。块注释用来临时屏蔽一段代码比删掉再恢复方便。6.3 版本管理与团队协作建议混编工程的版本管理比纯文本代码麻烦因为LD是图形化的diff工具处理不了。我的做法是每次发布版本导出两份一份是GX Works3的工程文件.gx3一份是ST代码的纯文本导出.st。ST代码用Git管理LD部分靠工程文件的版本号管理。工程文件命名带日期和版本比如Project_20240510_v1.2.gx3。团队协作时ST块可以分给不同人写但LD块最好一个人负责避免图形化冲突。如果团队规模大可以考虑用GX Works3的工程分割功能把不同程序块分到不同文件里减少冲突。6.4 哪些场景千万别混编混编不是万能的有些场景我建议别混安全相关逻辑安全回路、急停、安全门这些逻辑最好用纯LD而且用安全PLC单独做。混编会增加审核难度。极高速逻辑扫描周期要求在1ms以内的混编的额外开销可能吃不消。这种场景用纯LD或者专用运动控制模块。维护团队只会LD如果现场维护的人看不懂ST那ST块就要尽量少或者把ST逻辑封装成FB让维护的人只看到方框。临时项目、一次性项目混编的架构成本不低如果项目只跑一个月就拆纯LD更快。7. 从混编延伸出去的几个方向混编做熟了自然会碰到一些延伸需求。比如ST代码的模块化把常用功能滤波、限幅、单位换算写成函数库多个项目复用。GX Works3支持把ST块导出成库文件下次新建工程直接导入。再比如与上位机的数据交互。ST在处理字符串和协议解析上有天然优势很多混编工程里ST块专门负责跟MES、扫码枪、视觉系统通信LD块负责设备动作。这种架构下ST块相当于一个通信网关LD块只管干活。还有一个方向是代码自动生成。有些团队用Python脚本读Excel配方表自动生成ST代码然后导入GX Works3。这种方式在配方多、变更频繁的项目里能省大量时间。我试过一个项目200个配方手工写ST要两天脚本生成只要十分钟。最后说个我自己的体会。混编这件事技术上的难点其实不多GX Works3的文档写得还算清楚。真正的难点是团队共识——大家得对什么逻辑用什么写有统一的认知对命名规范、注释规范、版本管理有统一的约定。技术可以学共识要靠磨。我见过技术很强但各写各的团队混编工程一团糟也见过技术一般但规范统一的团队混编工程清清爽爽。程序是给人看的这句话在混编场景里尤其成立。
