1. 先聊清楚IEC 61131到底在“标准化”什么做PLC编程的人迟早都会遭遇一次灵魂拷问为什么项目里别人写的程序我读起来费劲为什么不同的PLC型号之间代码没法直接迁移如果你一直在某一家厂商的生态里工作可能还会觉得“PLC编程不就是这样吗”直到你接触了IEC 61131你才会发现自己之前对“可移植性”和“结构化编程”的理解其实相当模糊。IEC 61131是国际电工委员会制定的一套关于可编程逻辑控制器的标准全称很长通常我们说IEC 61131就是指它。它覆盖的范围不只是编程语言还包括硬件、通信、测试方法等好几个部分。但对于绝大多数工程师来说真正天天打交道的是其中的第三部分——IEC 61131-3也就是编程语言这一块。我见过不少朋友一上来就埋头学指令表学完发现换了品牌照样不会写原因就是没先把IEC 61131-3这个框架吃透。这套标准解决了几个非常现实的问题。第一是编程语言的规范化它定义了五种标准编程语言你不管用哪个牌子的PLC都能找到对应的语言形态第二是程序结构的规范化它引入了程序组织单元POU、任务、全局变量这些概念让PLC程序从“一坨梯形图堆到底”变成“分模块、分文件、可复用”的工程第三是数据类型的规范化它定义了一套标准的数据类型体系包括整数、实数、布尔、字符串以及衍生出来的结构体和枚举。这么说吧IEC 61131-3对于PLC行业的意义类似于高级语言标准化对计算机行业的推动。你可以不背标准条文但你写的程序结构、变量命名、任务分配方式本质上都是在标准的框架内运行的。理解了这套框架你再看任何一家PLC的编程软件都会觉得“原来如此”而不是每个牌子都像一座孤岛。这篇内容适合谁看呢刚入门PLC、面对手册不知道从哪下手的新手想从梯形图转型结构化文本的进阶工程师以及那些需要在多品牌PLC之间切换、饱受代码迁移之苦的从业者。我会尽量用实际操作里的话来聊不给你背书只讲怎么理解、怎么落地。2. 五种编程语言怎么选别被名字吓住本质就三类套路IEC 61131-3规定了五种编程语言梯形图LD、功能块图FBD、结构化文本ST、指令表IL和顺序功能图SFC。听起来很多其实仔细一梳理它们的关系并不复杂。2.1 梯形图LD电气人的母语梯形图是所有语言里最像继电器电路的一种左边一条母线、右边一条母线中间是常开触点、常闭触点、线圈逻辑通过“能流”从左往右传递。学电气出身的人看梯形图几乎不需要转换思维因为它就是拿继电器控制电路换了个形式搬到屏幕上。梯形图的优势是直观尤其是在纯逻辑控制、互锁保护、启停控制这些场景里画面和电路一一对应排查问题特别方便。车间里的维修电工可能不懂ST但他看梯形图能看懂哪里有问题这就是梯形图至今仍然是PLC编程主力语言的原因。它的缺点也很明显不适合做复杂数学运算、不适合处理大量数据、不适合描述复杂的状态跳转。你非要用梯形图算PID也不是不能写但那画面太美维护起来想摔键盘。2.2 功能块图FBD从输入到输出的数据流功能块图长得更像电子电路图用的是方框和连线框框之间通过信号线连接信号从左到右流动。每个功能块内部封装了一段逻辑或算法你只需要关心它的输入、输出和参数。FBD最大的价值在于信号流清晰特别适合模拟量处理、闭环控制、滤波算法这一类需要把“输入—处理—输出”结构明确表达出来的场景。PID控制用FBD来表达就很合适给定值输入一个框反馈值输入一个框经过PID功能块运算之后输出一个控制量框图上一眼就能看出来整个控制链路。实际工程里FBD经常和梯形图混着用梯形图负责逻辑联锁FBD负责回路控制。这种混合用法在过程控制行业尤其常见。2.3 结构化文本STPLC界的“C语言”结构化文本是一种高级文本语言语法上和Pascal、C有相似之处支持变量声明、IF条件、FOR循环、CASE分支、函数调用。它的表达能力强适合做算法、数学运算、复杂条件判断和数据处理。我自己的切身体会一旦你尝试在两个项目里用ST写了几段逻辑再回头用梯形图写复杂判断就会觉得梯形图确实有点“费劲”。比如一段需要考虑好几种情况的逻辑在梯形图里要串并联一大堆触点读起来非常累在ST里就是一个IF…ELSIF…ELSE的问题几行代码清清楚楚。ST的另外一个隐藏优势是便于代码复用和跨平台移植。由于它接近通用编程语言的表达方式你从A品牌PLC迁移到B品牌PLC时ST代码的转换成本远远小于梯形图。很多PLC品牌包括一些以往以梯形图为主的品牌这几年都在强化ST编辑器的能力就是这个趋势。2.4 指令表IL从汇编时代走来的老将指令表在标准里和汇编语言对标是一种低级的文本语言一行一条指令操作码加操作数。LD AAND BOUT C就这么一路写下去。在老一点的项目里尤其欧系PLC的早期程序里IL用得非常多。但说句实在话现在新项目已经很少有人主动选IL了它的可读性差、维护成本高很多年轻工程师甚至没见过IL写出来的程序。如果你碰到一个需要维护的老设备打开程序发现是IL写的那种心情我懂——别慌把IL翻译成ST或者梯形图慢慢看逻辑上完全等价只是表达方式不同。2.5 顺序功能图SFC给“流程”而生的语言顺序功能图和其他四种语言不太一样它不是用来写“一个周期内怎么算”的而是用来描述“整个流程分几步走”的。SFC用步Step和转换Transition来表示流程一个步骤干活干完了满足转换条件跳到下一步每一步里可以嵌套梯形图、FBD或者ST代码。SFC特别适合描述顺序控制类应用比如自动生产线、流水线工序、设备启动/停止流程。它的核心价值是把流程结构和具体逻辑解耦你先把流程骨架搭出来哪一步做什么、什么条件触发切换一目了然然后每一“步”内部的实现细节可以随便用其他语言填充。我用过一个饮料灌装线的项目整条线的核心控制就是一个大SFC待机步、启动步、灌装步、封盖步、排出步、清洗步每步之间通过传感器信号和定时器做转换。后续客户要加一个瓶盖检测工序我只需要在SFC里插入一个新步然后填上该步的逻辑就行不需要改动其他部分的代码——这种扩展性用梯形图写顺序控制是做不到的。2.6 语言选型的经验法则综合来看五种语言如何选我给你几个实操中总结的原则纯逻辑联锁、保护回路、启停控制优先梯形图。模拟量处理、PID回路、运算链优先FBD。复杂算法、数据处理、批量判断优先ST。多步骤顺序流程优先SFC。除非维护老设备否则不要新写IL。还有一个经验一个项目里不要只用一种语言混合使用是正常且推荐的。标准本身就允许你在同一个程序里调用不同语言编写的POU这恰恰是IEC 61131-3框架的一个核心优点。3. 从“写代码”到“搭工程”POU、任务与数据类型的底层逻辑很多人学PLC习惯了一上来就拖触点、拖线圈从来不思考程序的“组织方式”。但IEC 61131-3恰恰最重视的就是组织方式。你要理解这一套先记住三个关键词POU、任务、数据类型。3.1 POU程序、功能块、函数三兄弟要分清POUProgram Organization Unit是程序组织单元具体分成三类程序PROGRAM、功能块Function Block、函数Function。函数Function是指没有内部状态、同样的输入必然得到同样输出的逻辑单元比如加法、绝对值、取整、字符串拼接都属于函数。你写一个自定义函数输入两个实数返回它们的平均值不管调用多少次结果都只取决于输入这就是函数。功能块Function Block则不一样它是带“记忆”的输入相同不代表输出相同因为它内部有静态变量保存历史状态。最典型的功能块就是定时器你给它同样的启动信号它内部计时到不同时间点输出的结果就不同。PID控制器、计数器、边沿检测器统统都是功能块。程序PROGRAM是PLC执行的顶层单元相当于你的主程序。程序里可以调用函数和功能块但函数和功能块不能反过来调用程序。整个PLC程序的入口就是若干个被任务调度的程序。理解这三者的区别是至关重要的你把一个该用功能块实现的东西比如定时器写成了函数运行结果必然出错因为函数不能保存储内部状态。3.2 任务决定程序“什么时候跑”任务Task是IEC 61131-3里的调度机制。PLC虽然是实时系统但程序并不是所有代码都在一个循环里跑。任务负责告诉系统某段程序是周期性执行还是事件触发执行执行优先级是多少。我见过不少工程师写了程序却跑不对最后发现是任务配置出了问题比如程序逻辑本身没问题但任务周期设置过长导致现场信号变化了程序却没来得及刷新。或者多个任务优先级配错了低速任务里的程序把高速任务里的变量给改了造成数据竞争。正确理解任务的用法是把高速、实时性要求高的逻辑放在优先级高、周期短的任务里比如伺服控制、故障保护把低速、非实时的逻辑放在周期长的任务里比如数据采集、报表记录。任务之间通过共享变量通信时要特别注意读写一致性问题必要的时候用互斥机制。这些细节实际项目里很常见但很多人不知道问题出在哪。3.3 数据类型不只是整数和布尔那么简单IEC 61131-3定义了一套标准的数据类型从基础的BOOL、BYTE、WORD、DINT、REAL到衍生的数组、结构体、枚举、字符串。数据类型的选择对你的程序质量和稳定性影响非常大。举个最常见的坑PLC内部做运算时整数类型溢出会直接导致结果变成错误值。比如用一个INT16位有符号整数存一个比较大的累加值超过32767就溢出变成负数你的程序却还在继续往下算这种Bug非常难排查。我遇到过类似的现场问题设备运行到某个时间点后突然行为异常查了很久才发现是一个计数器的数据类型用小了。另外现在主流的IEC 61131-3实现都支持结构化数据类型就是你可以像C语言里定义结构体一样自己定义一个“模拟量通道”类型里面包含原始值、工程值、量程上限、量程下限、单位、报警状态等字段。然后用这个类型声明一堆变量代码里的表达力会一下子提高不少。比如你声明了一个“温度传感器”类型的变量代码里写“温度.工程值”和“温度.报警状态”语义就非常明确。3.4 变量作用域全局变量能不用就不用IEC 61131-3里的变量可以在不同层级声明局部变量、功能块内的变量、全局变量。很多新手为了省事把变量全都声明成全局的整个程序所有POU都能访问。短期看确实省事长期看是给自己挖坑。全全局变量过多会导致程序耦合度极高你改一个变量根本不知道会影响哪些功能块排查问题的时候只能满项目找引用点。我在项目里定的规矩是能局部就局部能封装就封装全局变量只留给真正需要跨程序共享的数据比如设备总启停信号、报警汇总。4. IEC 61131-3的实战落地一段程序从设计到运行的完整拆解前面讲的都是概念和框架这一节我们实打实地走一遍。假设现在有一个简单的项目需求做一个混料罐控制搅拌电机在液位高于低限、低于高限、且启动按钮按下时运行液位超高或急停按下时停止同时记录累计运行时间。4.1 从需求到POU的拆解这个需求看起来简单但按IEC 61131-3的思路不能直接开始拖梯形图。先分解这个系统里有几个功能启动停止逻辑是一个累计运行时间是一个液位信号处理是一个。那我们就把系统分解成三个POU一个程序PROGRAM作为顶层组织者负责调用下面两个逻辑块一个功能块叫“搅拌控制”负责电机的启停逻辑和锁定状态一个功能块叫“运行计时”负责累计电机运行时间。为什么要把启停和计时分开因为它们是两个独立的关注点一个是状态逻辑一个是数据累计。拆开之后如果以后要加一个“运行次数统计”只需要再写一个功能块不需要动原来的代码。这就是模块化的价值。4.2 ST语言的具体实现下面的代码用ST语言写因为ST最容易展示这种逻辑的清晰结构。在支持IEC 61131-3的PLC上这段代码可以直接输入ST编辑器。首先是“搅拌控制”功能块FUNCTION_BLOCK FB_MixerControl VAR_INPUT StartButton : BOOL; // 启动按钮 StopButton : BOOL; // 停止按钮 LevelLow : BOOL; // 液位低限开关 LevelHigh : BOOL; // 液位高限开关 EStop : BOOL; // 急停 END_VAR VAR_OUTPUT MotorRun : BOOL; // 电机运行输出 END_VAR VAR StartSig : BOOL; // 启动上升沿锁存信号 END_VAR // 核心逻辑只有液位在低限和高限之间才能启动 StartSig : (StartButton AND NOT StopButton AND LevelLow AND NOT LevelHigh) OR (StartSig AND NOT StopButton); // 急停优先任何情况下一旦急停立刻停止 MotorRun : StartSig AND NOT EStop;这里要注意的点有几个。第一StartSig是一个有记忆的变量它会在启动条件满足时置位然后通过“自保持”逻辑维持输出这就是典型的“锁存”模式。第二急停信号放在最终输出上做“硬切”不管之前是什么状态急停一触发就切断。第三如果液位条件不满足StartSig不会置位这是工艺约束的体现。然后是“运行计时”功能块FUNCTION_BLOCK FB_RunTimeCounter VAR_INPUT MotorRun : BOOL; // 电机运行状态 END_VAR VAR_OUTPUT TotalHours : REAL; // 累计运行小时 END_VAR VAR LastState : BOOL; // 上一次运行状态用于边沿检测 TickCount : DINT; // 计数累计值 END_VAR // 检测电机从停止到运行的上升沿 IF MotorRun AND NOT LastState THEN TickCount : 0; END_IF // 运行时每个扫描周期累加 IF MotorRun THEN TickCount : TickCount 1; END_IF // 假设任务周期为100ms换算成小时 TotalHours : INT_TO_REAL(TickCount) * 0.1 / 3600.0; LastState : MotorRun;这个功能块利用了“每个扫描周期执行一次”的事实做时间累计任务周期是100毫秒每次执行时计数加1然后用周期时间换算成实际时间。这里有个前提任务周期必须稳定如果任务被高优先级任务抢占导致抖动计时精度也会受影响。想要更精确的时间可以用硬件实时时钟但对大多数设备维护场景来说这个精度已经够用。4.3 在程序里组合POU顶层程序负责把上面两个功能块“接线”PROGRAM PRG_Mixer VAR FB_Mixer : FB_MixerControl; FB_Timer : FB_RunTimeCounter; LevelLowSwitch : BOOL AT %I0.0; // 实际输入映射 LevelHighSwitch : BOOL AT %I0.1; StartPB : BOOL AT %I0.2; StopPB : BOOL AT %I0.3; EStopPB : BOOL AT %I0.4; MotorContact : BOOL AT %Q0.0; // 实际输出映射 RunHours : REAL; END_VAR // 调用搅拌控制功能块 FB_Mixer(StartButton : StartPB, StopButton : StopPB, LevelLow : LevelLowSwitch, LevelHigh : LevelHighSwitch, EStop : EStopPB, MotorRun MotorContact); // 调用计时功能块 FB_Timer(MotorRun : MotorContact, TotalHours RunHours);这个程序里用了IEC 61131-3标准的“AT %I”和“AT %Q”语法做I/O映射这是直接把变量绑定到物理输入输出地址的标准写法。程序本身没有复杂的数学运算但结构非常清晰物理信号做映射逻辑进功能块功能块之间用变量关联。这种写法最大的好处是如果现场发现电机启动条件不对你去查FB_MixerControl的内部逻辑就行不需要在整个项目里大海捞针式地搜索触点。4.4 FBD和LD怎么看这段逻辑同样的控制需求如果车间老师傅更习惯梯形图完全可以在其他POU里用LD重写一遍“搅拌控制”。比如用梯形图表达就是常开触点对应StartButton、LevelLow常闭触点对应StopButton、LevelHigh输出线圈是StartSig再加上StartSig自己的常开触点并联做自锁最后再用EStop的常闭触点串在MotorRun输出回路上。而FBD的写法就是把StartSig的“与-或”逻辑画成几个逻辑功能块的组合一个AND块接收StartButton、NOT StopButton、LevelLow、NOT LevelHigh的输出结果送到OR块的一个输入OR块的另一个输入接StartSig反馈OR的结果输出StartSig。两种表达方式逻辑完全等价区别只是观感和维护习惯。4.5 程序下载前后的检查清单不管用什么语言写程序要上线之前我有几项必做检查变量类型是不是都够大计数器会不会溢出实数除法的分母会不会为零功能块的实例化是不是都分配了独立内存同一个功能块被多次调用时每次调用都要有自己的实例不然内部状态会互相干扰。任务配置对不对周期、优先级是否匹配控制需求I/O刷新方式是否配置正确启动行为是不是可控设备上电时输出会不会意外动作锁存变量的初始值是什么有没有给关键变量加保持属性断电再上电后累计值和状态能不能恢复这最后一条很多人会忘。有些累计数据比如运行时间、计数次数需要在断电后保留如果你声明变量时没加保持Retain属性断电之后归零那之前计的数据全没了。反过来有些状态变量你不希望断电恢复后还保持原值比如设备的启动状态就需要设置为非保持否则可能一来电设备就自己启动了这是很大的安全隐患。5. 踩坑与排障我在IEC 61131项目里的教训清单写IEC 61131程序这些年踩过的坑不算少。这里挑几个典型的都是真实维护现场会遇到的问题希望能帮你少走弯路。5.1 同变量名冲突与命名规范问题IEC 61131-3标准规定变量名不区分大小写也就是说“MotorRun”和“motorrun”是同一个变量。这跟高级语言不一样很多从C语言转过来的工程师会在这里踩坑。有的PLC平台会在变量名上警告有的直接就编译通过但运行时行为让你摸不着头脑。解决方法是制定一套严格的命名规范。我的习惯是POU名称用前缀区分类型FB_开头是功能块PRG_开头是程序FC_开头是函数全局变量用GVL_前缀物理输入映射用I前缀物理输出映射用Q前缀。这套规范沿用下来项目代码的阅读成本大幅降低。5.2 不同厂家的IEC 61131实现差异标准是标准实际各PLC厂商的实现总有些偏差。比如有的厂家把标准的数据类型名改了个花活有的厂家对周期任务的最小间隔有不同限制有的厂家对ST语法支持不完整比如不支持FOR循环的高级写法。跨品牌移植代码的时候这部分是最大的坑。我处理的办法是核心控制逻辑尽量只用标准语法遇到厂商扩展功能就单独封装一层后续换平台时只改这一层。比如某个厂家的特定通信库函数我就单独写一个功能块包一层其他POU只调用我封装的功能块接口。这样换品牌时只动封装层不用动整个程序的逻辑。5.3 调试器的陷阱在线修改与编译不一致IEC 61131开发环境普遍支持在线修改就是程序跑着的时候改一小段逻辑直接下载。这个功能很方便但也埋了不少雷在线修改之后程序的实际运行版本和磁盘上的工程文件版本不一致如果你忘了上传到电脑下次换台电脑打开同一个工程看到的还是老版本代码。等设备出问题时一排查才发现现场的PLC跑的根本不是你以为的那版程序。我的经验是每次在线修改之后立刻执行“上传”操作把PLC里的当前程序重新拉回工程文件并做好版本备注。这个习惯看起来冗余但现场事故排查时能救你命。5.4 模拟量与工程量的转换精度IEC 61131-3项目里大量处理模拟量信号。最常见的问题不是逻辑写错而是量程转换时数据类型和精度处理不当。很多PLC的AI模块把原始值放在INT里比如0到27648对应4到20mA你要把原始值转换成实际的温度或者压力值公式是实际值 (原始值 / 量程上限) × (工程量上限 - 工程量下限) 工程量下限如果你直接拿INT做除法就会得到截断的整数导致实际值跳动或者精度不够。正确做法是先转换成REAL再做运算。这个属于最基本的细节但我在不少项目里见过这个错误现象就是模拟量显示数值不准确、波动大排查半天其实只是因为漏了一个REAL转换。6. 从标准到习惯我怎么看IEC 61131的长期价值回到最开始的问题学IEC 61131到底是为了什么我个人的看法是它真正带来的不是某个语法、某个语言而是一整套工程思维。以前PLC编程给人感觉像“画电路图”想到哪画到哪。基于IEC 61131编程更像在“做软件工程”先设计功能块划分再定义数据接口然后分配任务周期最后才是填逻辑细节。这个过程里你会自然地去思考模块边界、数据流、状态管理这些被梯形图掩盖的问题。对新手来说我的建议很简单从梯形图入门完全没问题但不要停留在梯形图。试着用ST重写一遍已经做过的梯形图项目你会发现原来脑子里“只能靠画”的逻辑其实可以用文字更精确地表达。再进一步尝试把一个中大型项目按POU拆分来组织你会体会到模块化的好处——改一个功能不会牵一发动全身。对老手来说IEC 61131的真正意义在于“通用性”。它是一套跨品牌的公共语言你用它思考问题就能够在不同平台上更快地迁移。它不能保证代码一字不改地迁移厂商差异现实存在但它能保证你的思维方式和设计方法是可以迁移的。最后分享一个小习惯我会在维护项目里专门建一个“公用功能块库”把定时器变种、边沿检测、量程转换、电机控制、阀门控制这些经常用到的逻辑沉淀下来做成自己的标准POU集合。每个新项目从库里拖出来直接用配置一下参数就完事。几年下来这个库才是真正属于你自己的“IEC 61131标准”——因为你已经把标准消化成了自己的工程习惯这才是学习这套标准最实在的收获。
1. 先聊清楚IEC 61131到底在“标准化”什么做PLC编程的人迟早都会遭遇一次灵魂拷问为什么项目里别人写的程序我读起来费劲为什么不同的PLC型号之间代码没法直接迁移如果你一直在某一家厂商的生态里工作可能还会觉得“PLC编程不就是这样吗”直到你接触了IEC 61131你才会发现自己之前对“可移植性”和“结构化编程”的理解其实相当模糊。IEC 61131是国际电工委员会制定的一套关于可编程逻辑控制器的标准全称很长通常我们说IEC 61131就是指它。它覆盖的范围不只是编程语言还包括硬件、通信、测试方法等好几个部分。但对于绝大多数工程师来说真正天天打交道的是其中的第三部分——IEC 61131-3也就是编程语言这一块。我见过不少朋友一上来就埋头学指令表学完发现换了品牌照样不会写原因就是没先把IEC 61131-3这个框架吃透。这套标准解决了几个非常现实的问题。第一是编程语言的规范化它定义了五种标准编程语言你不管用哪个牌子的PLC都能找到对应的语言形态第二是程序结构的规范化它引入了程序组织单元POU、任务、全局变量这些概念让PLC程序从“一坨梯形图堆到底”变成“分模块、分文件、可复用”的工程第三是数据类型的规范化它定义了一套标准的数据类型体系包括整数、实数、布尔、字符串以及衍生出来的结构体和枚举。这么说吧IEC 61131-3对于PLC行业的意义类似于高级语言标准化对计算机行业的推动。你可以不背标准条文但你写的程序结构、变量命名、任务分配方式本质上都是在标准的框架内运行的。理解了这套框架你再看任何一家PLC的编程软件都会觉得“原来如此”而不是每个牌子都像一座孤岛。这篇内容适合谁看呢刚入门PLC、面对手册不知道从哪下手的新手想从梯形图转型结构化文本的进阶工程师以及那些需要在多品牌PLC之间切换、饱受代码迁移之苦的从业者。我会尽量用实际操作里的话来聊不给你背书只讲怎么理解、怎么落地。2. 五种编程语言怎么选别被名字吓住本质就三类套路IEC 61131-3规定了五种编程语言梯形图LD、功能块图FBD、结构化文本ST、指令表IL和顺序功能图SFC。听起来很多其实仔细一梳理它们的关系并不复杂。2.1 梯形图LD电气人的母语梯形图是所有语言里最像继电器电路的一种左边一条母线、右边一条母线中间是常开触点、常闭触点、线圈逻辑通过“能流”从左往右传递。学电气出身的人看梯形图几乎不需要转换思维因为它就是拿继电器控制电路换了个形式搬到屏幕上。梯形图的优势是直观尤其是在纯逻辑控制、互锁保护、启停控制这些场景里画面和电路一一对应排查问题特别方便。车间里的维修电工可能不懂ST但他看梯形图能看懂哪里有问题这就是梯形图至今仍然是PLC编程主力语言的原因。它的缺点也很明显不适合做复杂数学运算、不适合处理大量数据、不适合描述复杂的状态跳转。你非要用梯形图算PID也不是不能写但那画面太美维护起来想摔键盘。2.2 功能块图FBD从输入到输出的数据流功能块图长得更像电子电路图用的是方框和连线框框之间通过信号线连接信号从左到右流动。每个功能块内部封装了一段逻辑或算法你只需要关心它的输入、输出和参数。FBD最大的价值在于信号流清晰特别适合模拟量处理、闭环控制、滤波算法这一类需要把“输入—处理—输出”结构明确表达出来的场景。PID控制用FBD来表达就很合适给定值输入一个框反馈值输入一个框经过PID功能块运算之后输出一个控制量框图上一眼就能看出来整个控制链路。实际工程里FBD经常和梯形图混着用梯形图负责逻辑联锁FBD负责回路控制。这种混合用法在过程控制行业尤其常见。2.3 结构化文本STPLC界的“C语言”结构化文本是一种高级文本语言语法上和Pascal、C有相似之处支持变量声明、IF条件、FOR循环、CASE分支、函数调用。它的表达能力强适合做算法、数学运算、复杂条件判断和数据处理。我自己的切身体会一旦你尝试在两个项目里用ST写了几段逻辑再回头用梯形图写复杂判断就会觉得梯形图确实有点“费劲”。比如一段需要考虑好几种情况的逻辑在梯形图里要串并联一大堆触点读起来非常累在ST里就是一个IF…ELSIF…ELSE的问题几行代码清清楚楚。ST的另外一个隐藏优势是便于代码复用和跨平台移植。由于它接近通用编程语言的表达方式你从A品牌PLC迁移到B品牌PLC时ST代码的转换成本远远小于梯形图。很多PLC品牌包括一些以往以梯形图为主的品牌这几年都在强化ST编辑器的能力就是这个趋势。2.4 指令表IL从汇编时代走来的老将指令表在标准里和汇编语言对标是一种低级的文本语言一行一条指令操作码加操作数。LD AAND BOUT C就这么一路写下去。在老一点的项目里尤其欧系PLC的早期程序里IL用得非常多。但说句实在话现在新项目已经很少有人主动选IL了它的可读性差、维护成本高很多年轻工程师甚至没见过IL写出来的程序。如果你碰到一个需要维护的老设备打开程序发现是IL写的那种心情我懂——别慌把IL翻译成ST或者梯形图慢慢看逻辑上完全等价只是表达方式不同。2.5 顺序功能图SFC给“流程”而生的语言顺序功能图和其他四种语言不太一样它不是用来写“一个周期内怎么算”的而是用来描述“整个流程分几步走”的。SFC用步Step和转换Transition来表示流程一个步骤干活干完了满足转换条件跳到下一步每一步里可以嵌套梯形图、FBD或者ST代码。SFC特别适合描述顺序控制类应用比如自动生产线、流水线工序、设备启动/停止流程。它的核心价值是把流程结构和具体逻辑解耦你先把流程骨架搭出来哪一步做什么、什么条件触发切换一目了然然后每一“步”内部的实现细节可以随便用其他语言填充。我用过一个饮料灌装线的项目整条线的核心控制就是一个大SFC待机步、启动步、灌装步、封盖步、排出步、清洗步每步之间通过传感器信号和定时器做转换。后续客户要加一个瓶盖检测工序我只需要在SFC里插入一个新步然后填上该步的逻辑就行不需要改动其他部分的代码——这种扩展性用梯形图写顺序控制是做不到的。2.6 语言选型的经验法则综合来看五种语言如何选我给你几个实操中总结的原则纯逻辑联锁、保护回路、启停控制优先梯形图。模拟量处理、PID回路、运算链优先FBD。复杂算法、数据处理、批量判断优先ST。多步骤顺序流程优先SFC。除非维护老设备否则不要新写IL。还有一个经验一个项目里不要只用一种语言混合使用是正常且推荐的。标准本身就允许你在同一个程序里调用不同语言编写的POU这恰恰是IEC 61131-3框架的一个核心优点。3. 从“写代码”到“搭工程”POU、任务与数据类型的底层逻辑很多人学PLC习惯了一上来就拖触点、拖线圈从来不思考程序的“组织方式”。但IEC 61131-3恰恰最重视的就是组织方式。你要理解这一套先记住三个关键词POU、任务、数据类型。3.1 POU程序、功能块、函数三兄弟要分清POUProgram Organization Unit是程序组织单元具体分成三类程序PROGRAM、功能块Function Block、函数Function。函数Function是指没有内部状态、同样的输入必然得到同样输出的逻辑单元比如加法、绝对值、取整、字符串拼接都属于函数。你写一个自定义函数输入两个实数返回它们的平均值不管调用多少次结果都只取决于输入这就是函数。功能块Function Block则不一样它是带“记忆”的输入相同不代表输出相同因为它内部有静态变量保存历史状态。最典型的功能块就是定时器你给它同样的启动信号它内部计时到不同时间点输出的结果就不同。PID控制器、计数器、边沿检测器统统都是功能块。程序PROGRAM是PLC执行的顶层单元相当于你的主程序。程序里可以调用函数和功能块但函数和功能块不能反过来调用程序。整个PLC程序的入口就是若干个被任务调度的程序。理解这三者的区别是至关重要的你把一个该用功能块实现的东西比如定时器写成了函数运行结果必然出错因为函数不能保存储内部状态。3.2 任务决定程序“什么时候跑”任务Task是IEC 61131-3里的调度机制。PLC虽然是实时系统但程序并不是所有代码都在一个循环里跑。任务负责告诉系统某段程序是周期性执行还是事件触发执行执行优先级是多少。我见过不少工程师写了程序却跑不对最后发现是任务配置出了问题比如程序逻辑本身没问题但任务周期设置过长导致现场信号变化了程序却没来得及刷新。或者多个任务优先级配错了低速任务里的程序把高速任务里的变量给改了造成数据竞争。正确理解任务的用法是把高速、实时性要求高的逻辑放在优先级高、周期短的任务里比如伺服控制、故障保护把低速、非实时的逻辑放在周期长的任务里比如数据采集、报表记录。任务之间通过共享变量通信时要特别注意读写一致性问题必要的时候用互斥机制。这些细节实际项目里很常见但很多人不知道问题出在哪。3.3 数据类型不只是整数和布尔那么简单IEC 61131-3定义了一套标准的数据类型从基础的BOOL、BYTE、WORD、DINT、REAL到衍生的数组、结构体、枚举、字符串。数据类型的选择对你的程序质量和稳定性影响非常大。举个最常见的坑PLC内部做运算时整数类型溢出会直接导致结果变成错误值。比如用一个INT16位有符号整数存一个比较大的累加值超过32767就溢出变成负数你的程序却还在继续往下算这种Bug非常难排查。我遇到过类似的现场问题设备运行到某个时间点后突然行为异常查了很久才发现是一个计数器的数据类型用小了。另外现在主流的IEC 61131-3实现都支持结构化数据类型就是你可以像C语言里定义结构体一样自己定义一个“模拟量通道”类型里面包含原始值、工程值、量程上限、量程下限、单位、报警状态等字段。然后用这个类型声明一堆变量代码里的表达力会一下子提高不少。比如你声明了一个“温度传感器”类型的变量代码里写“温度.工程值”和“温度.报警状态”语义就非常明确。3.4 变量作用域全局变量能不用就不用IEC 61131-3里的变量可以在不同层级声明局部变量、功能块内的变量、全局变量。很多新手为了省事把变量全都声明成全局的整个程序所有POU都能访问。短期看确实省事长期看是给自己挖坑。全全局变量过多会导致程序耦合度极高你改一个变量根本不知道会影响哪些功能块排查问题的时候只能满项目找引用点。我在项目里定的规矩是能局部就局部能封装就封装全局变量只留给真正需要跨程序共享的数据比如设备总启停信号、报警汇总。4. IEC 61131-3的实战落地一段程序从设计到运行的完整拆解前面讲的都是概念和框架这一节我们实打实地走一遍。假设现在有一个简单的项目需求做一个混料罐控制搅拌电机在液位高于低限、低于高限、且启动按钮按下时运行液位超高或急停按下时停止同时记录累计运行时间。4.1 从需求到POU的拆解这个需求看起来简单但按IEC 61131-3的思路不能直接开始拖梯形图。先分解这个系统里有几个功能启动停止逻辑是一个累计运行时间是一个液位信号处理是一个。那我们就把系统分解成三个POU一个程序PROGRAM作为顶层组织者负责调用下面两个逻辑块一个功能块叫“搅拌控制”负责电机的启停逻辑和锁定状态一个功能块叫“运行计时”负责累计电机运行时间。为什么要把启停和计时分开因为它们是两个独立的关注点一个是状态逻辑一个是数据累计。拆开之后如果以后要加一个“运行次数统计”只需要再写一个功能块不需要动原来的代码。这就是模块化的价值。4.2 ST语言的具体实现下面的代码用ST语言写因为ST最容易展示这种逻辑的清晰结构。在支持IEC 61131-3的PLC上这段代码可以直接输入ST编辑器。首先是“搅拌控制”功能块FUNCTION_BLOCK FB_MixerControl VAR_INPUT StartButton : BOOL; // 启动按钮 StopButton : BOOL; // 停止按钮 LevelLow : BOOL; // 液位低限开关 LevelHigh : BOOL; // 液位高限开关 EStop : BOOL; // 急停 END_VAR VAR_OUTPUT MotorRun : BOOL; // 电机运行输出 END_VAR VAR StartSig : BOOL; // 启动上升沿锁存信号 END_VAR // 核心逻辑只有液位在低限和高限之间才能启动 StartSig : (StartButton AND NOT StopButton AND LevelLow AND NOT LevelHigh) OR (StartSig AND NOT StopButton); // 急停优先任何情况下一旦急停立刻停止 MotorRun : StartSig AND NOT EStop;这里要注意的点有几个。第一StartSig是一个有记忆的变量它会在启动条件满足时置位然后通过“自保持”逻辑维持输出这就是典型的“锁存”模式。第二急停信号放在最终输出上做“硬切”不管之前是什么状态急停一触发就切断。第三如果液位条件不满足StartSig不会置位这是工艺约束的体现。然后是“运行计时”功能块FUNCTION_BLOCK FB_RunTimeCounter VAR_INPUT MotorRun : BOOL; // 电机运行状态 END_VAR VAR_OUTPUT TotalHours : REAL; // 累计运行小时 END_VAR VAR LastState : BOOL; // 上一次运行状态用于边沿检测 TickCount : DINT; // 计数累计值 END_VAR // 检测电机从停止到运行的上升沿 IF MotorRun AND NOT LastState THEN TickCount : 0; END_IF // 运行时每个扫描周期累加 IF MotorRun THEN TickCount : TickCount 1; END_IF // 假设任务周期为100ms换算成小时 TotalHours : INT_TO_REAL(TickCount) * 0.1 / 3600.0; LastState : MotorRun;这个功能块利用了“每个扫描周期执行一次”的事实做时间累计任务周期是100毫秒每次执行时计数加1然后用周期时间换算成实际时间。这里有个前提任务周期必须稳定如果任务被高优先级任务抢占导致抖动计时精度也会受影响。想要更精确的时间可以用硬件实时时钟但对大多数设备维护场景来说这个精度已经够用。4.3 在程序里组合POU顶层程序负责把上面两个功能块“接线”PROGRAM PRG_Mixer VAR FB_Mixer : FB_MixerControl; FB_Timer : FB_RunTimeCounter; LevelLowSwitch : BOOL AT %I0.0; // 实际输入映射 LevelHighSwitch : BOOL AT %I0.1; StartPB : BOOL AT %I0.2; StopPB : BOOL AT %I0.3; EStopPB : BOOL AT %I0.4; MotorContact : BOOL AT %Q0.0; // 实际输出映射 RunHours : REAL; END_VAR // 调用搅拌控制功能块 FB_Mixer(StartButton : StartPB, StopButton : StopPB, LevelLow : LevelLowSwitch, LevelHigh : LevelHighSwitch, EStop : EStopPB, MotorRun MotorContact); // 调用计时功能块 FB_Timer(MotorRun : MotorContact, TotalHours RunHours);这个程序里用了IEC 61131-3标准的“AT %I”和“AT %Q”语法做I/O映射这是直接把变量绑定到物理输入输出地址的标准写法。程序本身没有复杂的数学运算但结构非常清晰物理信号做映射逻辑进功能块功能块之间用变量关联。这种写法最大的好处是如果现场发现电机启动条件不对你去查FB_MixerControl的内部逻辑就行不需要在整个项目里大海捞针式地搜索触点。4.4 FBD和LD怎么看这段逻辑同样的控制需求如果车间老师傅更习惯梯形图完全可以在其他POU里用LD重写一遍“搅拌控制”。比如用梯形图表达就是常开触点对应StartButton、LevelLow常闭触点对应StopButton、LevelHigh输出线圈是StartSig再加上StartSig自己的常开触点并联做自锁最后再用EStop的常闭触点串在MotorRun输出回路上。而FBD的写法就是把StartSig的“与-或”逻辑画成几个逻辑功能块的组合一个AND块接收StartButton、NOT StopButton、LevelLow、NOT LevelHigh的输出结果送到OR块的一个输入OR块的另一个输入接StartSig反馈OR的结果输出StartSig。两种表达方式逻辑完全等价区别只是观感和维护习惯。4.5 程序下载前后的检查清单不管用什么语言写程序要上线之前我有几项必做检查变量类型是不是都够大计数器会不会溢出实数除法的分母会不会为零功能块的实例化是不是都分配了独立内存同一个功能块被多次调用时每次调用都要有自己的实例不然内部状态会互相干扰。任务配置对不对周期、优先级是否匹配控制需求I/O刷新方式是否配置正确启动行为是不是可控设备上电时输出会不会意外动作锁存变量的初始值是什么有没有给关键变量加保持属性断电再上电后累计值和状态能不能恢复这最后一条很多人会忘。有些累计数据比如运行时间、计数次数需要在断电后保留如果你声明变量时没加保持Retain属性断电之后归零那之前计的数据全没了。反过来有些状态变量你不希望断电恢复后还保持原值比如设备的启动状态就需要设置为非保持否则可能一来电设备就自己启动了这是很大的安全隐患。5. 踩坑与排障我在IEC 61131项目里的教训清单写IEC 61131程序这些年踩过的坑不算少。这里挑几个典型的都是真实维护现场会遇到的问题希望能帮你少走弯路。5.1 同变量名冲突与命名规范问题IEC 61131-3标准规定变量名不区分大小写也就是说“MotorRun”和“motorrun”是同一个变量。这跟高级语言不一样很多从C语言转过来的工程师会在这里踩坑。有的PLC平台会在变量名上警告有的直接就编译通过但运行时行为让你摸不着头脑。解决方法是制定一套严格的命名规范。我的习惯是POU名称用前缀区分类型FB_开头是功能块PRG_开头是程序FC_开头是函数全局变量用GVL_前缀物理输入映射用I前缀物理输出映射用Q前缀。这套规范沿用下来项目代码的阅读成本大幅降低。5.2 不同厂家的IEC 61131实现差异标准是标准实际各PLC厂商的实现总有些偏差。比如有的厂家把标准的数据类型名改了个花活有的厂家对周期任务的最小间隔有不同限制有的厂家对ST语法支持不完整比如不支持FOR循环的高级写法。跨品牌移植代码的时候这部分是最大的坑。我处理的办法是核心控制逻辑尽量只用标准语法遇到厂商扩展功能就单独封装一层后续换平台时只改这一层。比如某个厂家的特定通信库函数我就单独写一个功能块包一层其他POU只调用我封装的功能块接口。这样换品牌时只动封装层不用动整个程序的逻辑。5.3 调试器的陷阱在线修改与编译不一致IEC 61131开发环境普遍支持在线修改就是程序跑着的时候改一小段逻辑直接下载。这个功能很方便但也埋了不少雷在线修改之后程序的实际运行版本和磁盘上的工程文件版本不一致如果你忘了上传到电脑下次换台电脑打开同一个工程看到的还是老版本代码。等设备出问题时一排查才发现现场的PLC跑的根本不是你以为的那版程序。我的经验是每次在线修改之后立刻执行“上传”操作把PLC里的当前程序重新拉回工程文件并做好版本备注。这个习惯看起来冗余但现场事故排查时能救你命。5.4 模拟量与工程量的转换精度IEC 61131-3项目里大量处理模拟量信号。最常见的问题不是逻辑写错而是量程转换时数据类型和精度处理不当。很多PLC的AI模块把原始值放在INT里比如0到27648对应4到20mA你要把原始值转换成实际的温度或者压力值公式是实际值 (原始值 / 量程上限) × (工程量上限 - 工程量下限) 工程量下限如果你直接拿INT做除法就会得到截断的整数导致实际值跳动或者精度不够。正确做法是先转换成REAL再做运算。这个属于最基本的细节但我在不少项目里见过这个错误现象就是模拟量显示数值不准确、波动大排查半天其实只是因为漏了一个REAL转换。6. 从标准到习惯我怎么看IEC 61131的长期价值回到最开始的问题学IEC 61131到底是为了什么我个人的看法是它真正带来的不是某个语法、某个语言而是一整套工程思维。以前PLC编程给人感觉像“画电路图”想到哪画到哪。基于IEC 61131编程更像在“做软件工程”先设计功能块划分再定义数据接口然后分配任务周期最后才是填逻辑细节。这个过程里你会自然地去思考模块边界、数据流、状态管理这些被梯形图掩盖的问题。对新手来说我的建议很简单从梯形图入门完全没问题但不要停留在梯形图。试着用ST重写一遍已经做过的梯形图项目你会发现原来脑子里“只能靠画”的逻辑其实可以用文字更精确地表达。再进一步尝试把一个中大型项目按POU拆分来组织你会体会到模块化的好处——改一个功能不会牵一发动全身。对老手来说IEC 61131的真正意义在于“通用性”。它是一套跨品牌的公共语言你用它思考问题就能够在不同平台上更快地迁移。它不能保证代码一字不改地迁移厂商差异现实存在但它能保证你的思维方式和设计方法是可以迁移的。最后分享一个小习惯我会在维护项目里专门建一个“公用功能块库”把定时器变种、边沿检测、量程转换、电机控制、阀门控制这些经常用到的逻辑沉淀下来做成自己的标准POU集合。每个新项目从库里拖出来直接用配置一下参数就完事。几年下来这个库才是真正属于你自己的“IEC 61131标准”——因为你已经把标准消化成了自己的工程习惯这才是学习这套标准最实在的收获。
