1. IEC 61131-3的五种语言它们互相补位不互相取代很多刚接触PLC的朋友会问我一个问题“学长PLC编程是不是就是梯形图”说实话我当年也是这么以为的直到有一次给一台老设备做改造打开程序发现整个主控逻辑全是用ST写的我盯着满屏的IF...THEN半天没缓过来。也是从那时候开始我才真正意识到PLC的编程语言从来就不是只有梯形图一种。这里要引入一个绕不开的标准IEC 61131-3。它把PLC编程语言规范成了五种——梯形图LD、结构化文本ST、功能块图FBD、顺序功能图SFC、指令表IL。很多人第一次听到这个数字会觉得枯燥但实际上这套标准解决的是一个大麻烦以前每个厂家都有自己的方言换个品牌基本相当于重新学一次编程而IEC 61131-3给了大家一套通用语法框架西门子、三菱、施耐德、博世力士乐、汇川、信捷这些主流厂商虽然细节上有差异但核心逻辑是一致的。这五种语言不是哪个高级哪个低级的区别而是服务于不同类型问题的工具组合。用一个生活类比你要装修房子梯形图是锤子和螺丝刀ST是电钻和切割机FBD是水平尺SFC是施工图。你不会拿水平尺去敲钉子也不会用切割机去画线每样工具都有自己的主场。1.1 梯形图LD电气工程师的母语梯形图的历史可以追溯到继电器控制系统时代。在那个PLC还没普及的年代工厂里的控制柜里全是物理继电器、接触器、时间继电器电气工程师靠着一套“线圈得电、触点闭合”的逻辑组合控制设备运行。梯形图的每一行本质上就是一张继电器电路图左边是母线中间是串联的触点右边是一个线圈。这种设计的聪明之处在于电工师傅不需要额外学习“编程思维”只要会看继电器图纸就能看懂梯形图。比如一个最简单的自锁回路在继电器电路里是两个按钮加一个接触器在梯形图里就是X0启动、X1停止、Y0输出线圈再加Y0常开并联自锁。符号变了但逻辑习惯一点没变。直到今天梯形图依然是国内工厂里最常见的PLC语言尤其是在单机设备、小型产线、简单逻辑控制场景下梯形图的统治地位几乎不可撼动。它的优势很直白直观、易排查、和人脑的电路思维一致。现场电工拿个万用表就能照着梯形图查信号这是ST和IL做不到的。1.2 结构化文本ST程序员的“正常语言”如果说梯形图是为电气工程师准备的那么ST语言更像是给软件工程师准备的礼物。它的语法和Pascal、C语言非常接近有变量声明、有IF条件判断、有FOR循环、有CASE分支选择能处理数组能做复杂运算。我遇到过最典型的场景是一台设备有32个温度传感器需要实时采集、滤波、排序然后挑出最高点和最低点做温差判断。这种逻辑用梯形图写会写到怀疑人生——你需要手动维护几十个中间继电器变量程序长到翻页都费劲。但用ST写一个FOR循环加几个if就搞定了。很多老工程师不太愿意用ST觉得“不像PLC”但近几年新出的PLC产品尤其是Codesys、博途这种平台ST的使用比例明显上升。原因很简单设备越来越复杂数据交互和算法逻辑越来越多梯形图在复杂计算面前真的力不从心。1.3 功能块图FBD信号流的可视化FBD的逻辑表达方式很像电子电路里的门电路图左边是输入信号经过一个个功能块比如与门、或门、比较器、定时器、PID控制器右边输出结果信号从一个块的端子流到下一个块的端子。我在做过程控制类项目时特别偏爱FBD因为它非常适合表达模拟量信号处理链路。举个例子一个温度PID控制回路你把传感器信号接入一个标定块再进入滤波块然后进PID功能块最后输出到模拟量模块控制加热器开度。整个信号链路上每个环节都摆在那里一眼看过去就知道信号的“来龙去脉”排查问题比读梯形图省力多了。1.4 顺序功能图SFC流程逻辑的地图SFC是五种语言里最像“流程图”的一种。它不是用一行行的触点线圈来表达逻辑而是用“步”和“转换条件”来描述一个流程初始化步→条件满足→进入下一步→执行动作→等待下一个条件。但凡做过自动流水线的人都会理解SFC的价值。多工位设备、输送线、装配机这些设备的核心逻辑就是一步一步往下走的顺序控制如果用梯形图硬写顺序流程程序里会全是M中间继电器的置位复位逻辑一多根本理不清。而SFC把整个流程画在地图上哪一步该做什么、什么条件触发切换清清楚楚。1.5 指令表IL被遗忘的地下层IL是五种语言里最古老也最不直观的一种它长得像汇编语言每行一个操作码加一个操作数。比如LD X0 AND X1 OUT Y0这种写法在今天的主流编程环境里已经很少作为首选了但它的价值在于很多老设备的程序备份就是IL指令表你要是不认识它连维护都无从下手。另外IL和PLC底层指令集的对应关系最紧密理解IL能帮你更踏实地理解PLC扫描执行的机制。语言核心门类像什么最适合的场景LD梯形图电气逻辑继电器电路图开关量控制、逻辑联锁ST结构化文本算法计算Pascal/C数据处理、复杂运算FBD功能块图信号链路电子电路图模拟量处理、PID调节SFC顺序功能图流程控制业务流程图多步顺序、工位流水线IL指令表底层指令汇编语言老设备维护、极简系统2. 梯形图凭什么统治电气圈从继电器图纸到扫描周期梯形图能够成为PLC的“代名词”不是没有原因的。它最大的贡献是把电气工程师几十年的读图经验平移到了数字化世界。但有一个东西是继电器电路图里从来没有的而梯形图里处处都是这就是扫描周期。2.1 常开常闭最容易引起误会的两个概念我见过不少新手在这里栽跟头程序里明明给一个触点写的是“常闭”结果设备一通电该信号没动作输出就是不导通。问题出在哪里在于PLC梯形图里的“常开常闭”和物理继电器里的“常开常闭”看着一样但判断基准完全不同。物理继电器里的常开触点是线圈不得电时断开的触点常闭触点是线圈不得电时闭合的触点。而梯形图里的X0常开触点判断的是“X0这个输入信号是否为ON”X0常闭触点判断的是“X0这个输入信号是否为OFF”。换句话说梯形图里的常闭触点只是一个“取反”操作符它不代表物理触点本身的状态。这个差异在调试时特别坑人。有一次我帮朋友排查一台设备程序里用了一个急停开关的常闭触点接到PLC输入逻辑上按下急停时输入信号由ON变OFF梯形图里用常开触点去触发报警。朋友死活不明白为什么“按钮没按的时候报警一直响”其实就是他把“硬件常闭”和“程序常开”的关系搞反了。记住一条铁律PLC输入模块只关心外部信号的电平是24V还是0V梯形图里的常开常闭是在这个电平基础上做的逻辑取反。2.2 扫描周期PLC的“心跳”PLC不是一瞬间执行完所有指令的它是从上到下、从左到右一遍一遍循环扫描。每一次扫描分为三大阶段读取输入→执行程序→刷新输出。这个过程周而复始就是扫描周期。我给刚入行的朋友讲扫描周期最喜欢用食堂打饭来做类比。你端着餐盘走到打菜窗口师傅一次只服务一个学生但同时有好几个窗口在并排工作一个窗口扫完当前这盘菜才轮到你。PLC也一样CPU在同一时刻只执行一条指令扫描完第一行再扫第二行扫完整个用户程序才进入下一步。区别在于PLC的“打饭速度”极快普通中小型PLC的扫描周期在几毫秒到几十毫秒之间人眼几乎感知不到但设备的高速运行场景下这个时间差会直接影响控制精度。理解扫描周期后有两个常见坑就能躲开。第一个是“同一周期内先读后写”的问题如果程序里第一行给Y0置位第二行又给Y0复位最终输出取决于最后一次赋值的状态而不是中间过程。第二个是“输入输出锁存”的问题PLC在扫描开始时统一读取输入端子状态扫描过程中输入端子的变化不会立即被程序感知必须等到下一个扫描周期开始。所以做高频响应的控制时不能指望PLC像单片机中断一样“即时响应”。2.3 梯形图里最容易出错的三个习惯第一个是双线圈输出。同一个线圈编号在程序里出现两次这在大多数PLC里都会触发编译警告但很多人为了省事不理会。结果就是程序逻辑完全取决于执行顺序排查起来非常头疼。正确做法是把同一设备的所有条件汇总到一个逻辑表达式或者使用中间变量过渡。第二个是置位和复位的滥用。用SET/RST指令确实方便但很多新手把程序写成了“一把SET走天下”该复位的地方不复位设备状态越跑越乱。我的经验是置位复位一定要成对出现在逻辑清晰的路径里最好配合状态变量不要让复位条件散落在程序各个角落。第三个是缺少注释和符号命名规范。梯形图最大的优势是直观但如果你所有变量都叫M0、D100再直观也白搭。我见过最痛苦的一次维护是帮客户查一台08年的老设备程序里300多个中间继电器全是原始地址没有任何注释那一天我基本是在用排除法漫游。给变量起有意义的名字比写注释更重要因为名字本身就是注释。3. ST语言不是“高级到用不上”而是算力型逻辑的必需品聊完梯形图我想为ST语言多说几句公道话。在一个自动化项目群里只要有人问“PLC要不要学ST”底下准会有人回“学那玩意儿干嘛现场修设备谁看ST”这话有一定道理但只适用于纯开关量、逻辑简单、不改工艺的小设备。一旦设备开始谈“数据”、谈“算法”、谈“配方”ST就是绕不开的工具。3.1 什么时候你会意识到非用ST不可举一个我亲历的例子一台检测设备需要对20个测量点位的数据做滑动平均滤波还要剔除超过3倍标准差的异常值最后按大小排序并输出前三个异常点位编号。这个过程涉及数组、循环、条件判断、排序算法用梯形图去实现的话我估算了一下光中间变量就要加几十个程序容量和可读性都会爆炸。但如果用ST写核心逻辑大概就是这样的结构VAR rawData : ARRAY[0..19] OF REAL; filtered : REAL; maxIdx : INT; END_VAR FOR i : 0 TO 19 DO sum : sum rawData[i]; END_FOR avg : sum / 20.0; FOR i : 0 TO 19 DO IF rawData[i] avg 3.0 * stdDev THEN maxIdx : i; // 捕获异常点位 END_IF END_FOR说实话这个代码很简单但用梯形图写绝对不止三四十行。ST把编程语言里成熟的循环、数组、函数概念带进了PLC让你的控制器真正具备了“计算能力”而不只是“逻辑能力”。3.2 ST和LAD混用不是二选一而是打配合很多人以为选了ST就等于抛弃了梯形图这是个很大的误解。我做的绝大多数项目最终交付的程序都是混合语言编写的设备的总装流程用SFC或梯形图搭骨架各种算法和数据块用ST做内胆PID和模拟量链路用FBD处理。这就像一个团队里既有项目经理做统筹又有技术专家攻难点各干各擅长的活。具体到实践上我的习惯是凡是涉及设备安全联锁、急停、互锁这种性命攸关的逻辑一律用梯形图写因为它直观、容易审查、现场电工看得懂凡是涉及配方管理、通讯报文解析、数据统计分析这种偏“软件”的逻辑一律用ST写因为它简洁、易维护、扩展性好。两种语言混用有一点要注意不同语言写在同一个PRG或FB里时变量作用域和执行顺序要理清楚别让ST块里的边沿触发和梯形图里的线圈在扫描周期上打架。3.3 ST学习成本高吗真正的门槛不在语法在编程思维ST的语法本身并不难有C语言基础的人一天就能上手。难的是从“电气思维”切到“软件思维”。电气思维是并行的、实时的、依赖物理状态的软件思维是顺序的、抽象的、依赖数据结构的。一个32位浮点数数组在梯形图里就是D200到D231一堆寄存器你得自己记哪个是哪一个在ST里它就是一个带名字的变量集合有类型、有边界、有范围检查。我的建议是所有人不管现在用不用ST都值得花两周时间把ST基础过一遍。因为PLC的边界正在模糊现在越来越多的PLC支持MQTT、HTTP、OPC UA这些网络协议支持机器学习推理支持高级语言集成。这些能力的载体几乎都是ST或类似的高级语言。你可以暂时不用ST做项目但你不能看不懂ST写的功能块否则三五年后你会发现自己的可维护范围越来越窄。4. 真正拉开差距的是程序架构扫描周期、状态机和结构化设计编程语言是表程序架构是里。我在带新人时最常强调的一句话是你要学的不只是“怎么写代码”更是“怎么安排代码”。部分新手程序写得也漂亮但一上设备就各种怪问题——状态乱了、互锁漏了、掉电重启后动作错乱——基本都能在程序架构层面找到病根。4.1 从“会写指令”到“会做设计”程序分层一个成熟PLC程序的层次结构在我眼里大概是这个样子的最底层硬件映射层负责把输入输出点映射为有意义的变量例如把X0命名为“急停按钮”把Y2命名为“主轴接触器”。推荐用符号寻址不要让程序里到处是裸地址。中间层逻辑处理层负责根据输入变量、工艺参数、配方数据计算出输出指令。这一层是核心也是状态机、算法块、PID块驻留的地方。最上层通讯与人机交互层负责触摸屏、上位机、MES系统的数据交互处理报警、配方、参数下发。这个分层的价值在于现场出了问题你能马上判断问题在哪个层级而不是在几百行的程序里没头苍蝇一样瞎找。很多人觉得自己程序难维护不是逻辑复杂而是所有东西都揉在一个PRG里没有隔层。4.2 时序流程用状态机别用“M满天飞”顺序控制是所有自动化项目里最常见的逻辑需求。我刚入行时写的顺序控制清一色是“置位M0→M0动作→等条件→置位M1→复位M0”程序一旦超过二十个步骤画梯形图的人直接精神崩溃因为置位复位的链条绕在一起改一步牵动全身。后来我彻底转向了状态机写法。核心思想很简单用一个整数变量代表当前状态0代表停止、10代表启动前准备、20代表运行中、30代表故障等整个程序围绕“当前状态是什么、满足什么条件进入下一个状态”来展开。ST里可以用CASE语句梯形图里可以做一个HMI状态显示加多个“比较触点群”写出来逻辑清晰到像在读小说。举一个实际例子一个润滑系统加一个主轴系统要求是“润滑电机启动3秒后主轴电机才能运行停止时主轴先停4秒后润滑电机再停”。这个逻辑如果用状态机来写不过是三四个状态之间切换的问题如果按“启动按钮驱动所有动作”的思路写你的脑袋会卷成麻花。4.3 功能块FB把重复逻辑“封装”成工具箱PLC程序里最容易被忽略但也最有价值的部分是功能块FB的复用。一个设备有四个一模一样的加热区每个区都有温度采集、上下限报警、PID调节和加热器控制。如果不用FB你会写四份几乎一样的代码用了FB写一份然后调用四次就行每个调用实例独立保存自己的变量。我在做多工位项目时几乎每个工位都封装成一个FB工位A就是一个FB里面管理自己的气爪动作、传感器判断、报警输出。主程序只负责“调度”这些FB不用关心FB内部细节。这种方式带来的维护体验是革命性的工艺改动时主程序基本不动改对应FB的内部逻辑就行现场排查时每个工位都有独立的报警状态和调试变量不用在全局变量海洋里捞针。封装的功能块还要留意一个事FB内部的变量默认是背景数据块存储多个实例之间互不干扰但如果你用了全局变量去传递数据就会出现“调用两次互相串数据”的诡异问题。所以写FB时尽量做到“数据从输入引脚进来结果从输出引脚出去”内部不要直接引用全局变量。4.4 报警和安全程序架构里的“压舱石”聊到架构就绕不开报警和安全。很多新手在程序里把报警条件直接串在输出逻辑里这种做法很危险报警条件一满足输出直接断一旦运行人员看不出原因等于设备失灵。更合理的做法是报警逻辑独立于动作逻辑。每一类报警有单独的状态字报警产生时先记录下来再决定动作逻辑如何响应。这样既能保证安全联锁又能让操作员通过触摸屏看到具体报警原因而不是看到一个莫名其妙停机的设备。安全联锁的逻辑还要注意一个物理层的问题紧急停止、安全门开关这些信号一定要“硬件硬接”不能只靠程序处理。PLC程序再可靠也有扫描周期、有CPU跑飞的可能硬件安全回路是最后一道物理防线。这个原则和编程语言无关但每一个正经的自动化工程师都应该刻在脑门上。5. 品牌生态里的语言选型西门子、三菱、汇川、Codesys各有什么脾性总有新手问我“那我学的时候用哪个品牌的PLC来练语言比较好”这个问题其实没有标准答案但不同品牌的软件确实塑造了不同的编程习惯。我把我接触过的几个主流生态从“语言友好度”这个角度盘一遍供参考。5.1 主流生态的“语言气质”西门子博途TIA Portal毫无疑问是时下国内最火的PLC环境S7-1200、S7-1500系列在中小型项目里几乎成了默认选项。博途的编程语言齐全LD、FBD、ST、SFC都能用而且它的SCL结构化控制语言就是ST的西门子版本语法完整度高。西门子的FC、FB、DB块体系是我见过的所有PLC里最清晰的一套工程化框架非常适合建立结构化编程习惯。三菱的GX Works系列在小型设备、包装机械、注塑机行业保有量极大。三菱的传统强项是梯形图和指令表工程师群体里“三菱风格”很浓——用M中间继电器做逻辑编排的习惯根深蒂固。三菱的ST支持相对较弱但近年来GX Works3也逐步转向以结构化编程为主新系列FX5U和R系列对ST的支持明显增强。汇川和Codesys系的国产/新兴平台是近几年发展最快的阵营。汇川的中大型PLC比如AM系列、AC系列走的是Codesys内核路线编程语言全套支持而且价格比西门子亲民很多在非标自动化领域攻城略地。Codesys本身就是IEC 61131-3的“原教旨主义者”它对五种语言的完整度甚至超过了一些老牌厂商用Codesys越久越会发现语言之间的切换完全是无缝的因为底层变量和工程模型全部统一。AB罗克韦尔的Studio 5000在高端离散制造、汽车生产线领域地位很高它的梯形图体验极佳而且标签化编程方式直接用Tag名寻址不碰物理地址做得很彻底。但AB的ST不如Codesys灵活而且生态封闭在国内的工程师受众不算太大。5.2 一个新手的路线建议别在“先学谁”上纠结如果你完全零基础我的建议是先学梯形图、再啃ST、最后顺手掌握SFC品牌选一个你用得到或最容易买到的硬件就行。梯形图帮你建立“电气控制和扫描周期”的直觉ST帮你打开“数据和算法”的视野SFC帮你建立“流程架构”的意识。这三关过了后面换任何品牌都只是换工具熟悉度的问题不是换脑回路。有一点要提醒现在很多培训视频、网课都在教你“看视频学指令列表”但指令列表记一百条都不如亲手点一个按钮看到输出动作来得扎实。PLC编程是实践学科必须“边学边练”。没有真实设备的话仿真器就是最好的老师西门子有S7-PLCSIM三菱有GX SimulatorCodesys有在线仿真都可以让你在上面纯软件跑通一整套设备逻辑很大程度缓解“没硬件练不了手”的问题。5.3 选型参考这几种场景我倾向怎么选项目类型我的倾向单机设备、简单逻辑、成本敏感三菱FX系列或汇川H系列梯形图为主中小型产线、工艺可调、需要配方和通讯西门子S7-1200/1500SCL与LAD混写多轴运动控制、视觉搭配、中大型非标汇川AM系列、Codesys生态STFBDSFC高端离散制造、汽车焊装线AB Studio 5000梯形图为主过程控制温度、压力、流量调节任何支持成熟PID块和FBD的平台当然这不是绝对的。真实项目里往往还要考虑客户指定品牌、当地服务能力、备件采购周期这些因素。但有一点我敢肯定会结构化编程的人不管在哪个平台项目质量和维护效率都能拉开只会一种语言的人几个身位。5.4 调试现场的那些“非语言”坑最后这一小节算是给前面所有讨论补一个现场视角。你程序写得再漂亮到了现场调试阶段照样会被各种“非典型问题”折磨。比如很多人第一次连台达PLC下载程序时才发现串口参数不对用InoProShop连接PLC时死活设置不对端口号连不上网口还有贝加莱或者Codesys系PLC的AMS NetID配置6字节网络标识符和端口号搞错一位就连不上目标设备。这些问题的本质都和编程语言无关而是工程综合能力的问题网络通讯、硬件接线、地址分配、软件环境配置。所以我在带新人时总说PLC项目一半是写程序一半是跟通讯、电气、机械打官司。你梯形图写得再溜不认识设备通讯报文不会看网络配置到现场照样寸步难行。6. 编程语言的魅力不在语言本身而在“懂工艺”这三个字文章写到这里可能有人会问“那编程语言的魅力到底是什么你绕了一大圈也没给出终极答案。”不着急收尾我想从另一个角度回答这个问题。6.1 一个完整的小案例从需求到程序框架假设给你一台设备要求做“软启动器一拖三”的控制也就是三台电机共用一台软启动器每次只能启动一台需要互锁和轮换逻辑。看似简单但琢磨一下三台电机为什么不能同时启动因为软启动器同一时间只能旁路一台电机。启停顺序要遵循什么得保证软启动器脱离当前电机后才能接入下一台。故障怎么办软启动器报故障时必须立刻断开当前回路并锁定防止误启动。这个逻辑用梯形图写核心是几个互锁触点和转换条件用状态机思路写就得把“空闲→启动中→运行中→切换待机”这些状态理清楚。你会发现语言只是表达工具真正驱动程序的是你对工艺的理解深度。理解“软启动器为什么只能带一台”你才不会写出三台同时启动的逻辑理解“接触器切换需要时间”你才不会在切换瞬间触发短路保护。这就是PLC编程语言魅力的第一层它是连接电气世界与工艺世界的翻译器。6.2 懂工艺的工程师和懂代码的程序员差在哪里我自己见过两类人。一类是纯软件背景转过来的写ST很溜数据结构、算法样样行但到了现场看不懂接触器互锁也不知道为什么变频器启动前要加一个很小的延时段。另一类是老师傅电气精通、工艺滚瓜烂熟但一碰到复杂算法就头大配方多几个维度就理不清。真正让我觉得“可怕”的是两类人合体既能看懂继电器图纸上的硬互锁又能用ST写出优雅的数据结构既知道机械手每个轴的极限位置为什么这样设置又知道报文里的32位浮点数是大端还是小端。这类工程师不需要多么高深的技术但他们的程序一眼看去就舒服逻辑清晰、层次分明、变量命名有意义、报警齐全、注释到位。6.3 编程语言的魅力最终是一种不确定性焦虑的消解说得感性一点我理解的编程语言魅力不是在于哪种语言更酷、更新、更高级而是在于它能帮你把“说不清、道不明”的工艺需求一步步变成“可验证、可执行、可维护”的逻辑。你对着触摸屏按一个按钮电机转了、气缸伸了、传感器亮了那种“我在一个混沌的现实里建立了一小片秩序”的感觉是我干了十几年自动化还不想转行的原因。PLC基础篇聊到这里与其说是讲编程语言不如说是讲一个看待自动化项目的角度语言是皮工艺是骨架构是筋。我的建议始终是八个字——先用起来再求结构。第一步永远比选哪条路更重要。你把它想得再透不如在仿真器里点亮一个灯你背再多的指令不如现场看一次设备跑崩然后亲手找到那个逻辑漏洞。PLC编程这种能力是在一次次“搞懂了为什么”之后才真正长在你身上的。