1. 工控圈绕不开的IEC61131：它到底在管什么
刚入行做PLC编程那会儿，我最怕听到的一句话就是“你这个程序不符合IEC61131规范”。当时心里想的是，程序能跑不就行了，管它什么规范不规范。后来踩的坑多了才明白，这套标准不是拿来卡人的，而是让不同品牌、不同型号的控制器之间有了一个共同的“语言基础”。你可以把它理解成工控领域的普通话——各家PLC厂商就像不同地方的方言区，IEC61131就是那个让大家都听得懂的通用语。
IEC61131是国际电工委员会专门为可编程控制器制定的一套标准，总共分为八个部分，从总览、硬件要求、编程语言、用户指南一直到通信规范都有覆盖。但真正跟咱们日常编程打交道最多的，是它的第三部分——编程语言标准。这部分定义了五种编程语言，分别是梯形图（LD）、功能块图（FBD）、顺序功能图（SFC）、指令表（IL）和结构化文本（ST）。很多刚接触PLC的朋友可能只用过梯形图，觉得其他几种离自己很远，但实际上，越往后做越复杂的项目，你会发现光靠梯形图真的不够用。
这套标准解决的核心问题是什么？说白了就是可移植性和可维护性。没有这套标准之前，你在这个品牌的PLC上写的程序，换到另一个品牌基本上等于重写。有了这套标准之后，至少编程的思路、数据类型的定义、程序结构的组织方式有了统一的参考框架。当然，现实中各家厂商还是会加自己的“私货”，但大框架是趋同的。对于工程师个人来说，掌握IEC61131的知识意味着你不会被某一个品牌绑死，换一个平台也能快速上手。
这篇文章适合谁看？如果你是刚入行的PLC编程新手，它能帮你建立一个完整的知识框架，知道自己在学的东西处于整个体系的哪个位置。如果你已经做了几年项目，但一直停留在梯形图阶段，那这篇文章能帮你打开思路，看看ST语言和SFC能怎么帮你解决复杂逻辑问题。如果你是从IT领域转过来的，那更好，你会发现IEC61131的很多设计理念跟你熟悉的编程范式有相通之处。
2. 五种编程语言怎么选：不是哪个高级就用哪个
2.1 梯形图LD：电气工程师的老朋友
梯形图是从继电器控制电路图演变过来的，它的最大优势是直观。对于做电气出身的工程师来说，看梯形图几乎零门槛，因为那些常开触点、常闭触点、线圈的符号跟继电器电路图几乎一模一样。我见过很多做了十几年的老师傅，你让他写ST语言他浑身难受，但给他一个梯形图，他三下五除二就能把逻辑理清楚。
梯形图适合什么场景？离散逻辑控制是它最擅长的领域。比如一个简单的启保停电路、电机的正反转控制、气缸的伸缩顺序控制，用梯形图写起来又快又清晰。调试的时候也方便，在线监控能看到每个触点的通断状态，哪一步没走通一眼就能看出来。
但梯形图也有明显的短板。当逻辑变得复杂，涉及大量数据处理、数学运算、字符串操作的时候，梯形图就会变得非常臃肿。我见过一个项目用梯形图做PID参数的自整定计算，整整写了三十多个网络段，看着就头疼，后来改成ST语言只用了不到二十行代码。所以梯形图不是万能的，它有自己的舒适区。
实操心得：新手不要觉得梯形图“低级”，恰恰相反，能把梯形图写得规范、清晰、易维护，本身就是一项硬功夫。我见过太多梯形图程序，逻辑全堆在一起，没有任何注释和分段，换个人接手根本看不懂。
2.2 结构化文本ST：复杂运算的利器
ST语言的语法跟Pascal和C比较接近，如果你有高级语言的编程基础，上手会非常快。它支持条件判断（IF-THEN-ELSIF-ELSE）、循环（FOR、WHILE、REPEAT）、数组操作、结构体定义，基本上高级语言该有的它都有。
ST最适合的场景是数学运算、数据处理、算法实现。比如你要做一个温度补偿算法，需要根据多个传感器的读数进行加权计算，用ST写起来就非常自然。再比如你要处理一个配方管理系统，需要从数组里查找、排序、比较数据，ST的效率比梯形图高出一个数量级。
但ST也不是没有缺点。它的在线调试体验不如梯形图直观。梯形图你可以看到每个触点的实时状态，ST语言虽然也能单步调试和变量监控，但对于不熟悉编程的人来说，理解起来门槛更高。另外，ST的灵活性也意味着更容易写出“只有自己看得懂”的代码，团队协作时需要更严格的编码规范。
2.3 功能块图FBD：信号流一目了然
FBD用图形化的功能块来表示逻辑运算，块与块之间用连线表示信号流向。它的思维方式跟数字电路非常像，如果你学过数字逻辑电路，看FBD会觉得特别亲切。
FBD最擅长的场景是过程控制和信号处理。比如模拟量信号的滤波、标定、报警判断，用FBD搭起来非常清晰。一个AI模块的信号进来，经过几个功能块的处理，最后输出到AO模块，整个信号链路一目了然。在DCS系统中，FBD是绝对的主力语言。
FBD的局限性在于，当逻辑分支特别多的时候，连线会变得非常复杂，像蜘蛛网一样。而且FBD不太适合表达顺序逻辑，你要用它来做步进控制，会觉得很别扭。
2.4 顺序功能图SFC：步进控制的标准化表达
SFC是专门为顺序控制设计的语言。它把一个控制过程分解成若干个“步”（Step），每个步代表一个稳定的状态，步与步之间通过“转换条件”（Transition）来切换。这种思维方式跟实际的生产流程非常吻合。
举个例子，一个自动灌装机的流程是：等待瓶子到位→开始灌装→灌装完成→移走瓶子→等待下一个瓶子。用SFC来表达，每个步骤就是一个步，转换条件就是传感器信号。整个程序结构跟工艺流程图几乎一一对应，操作工看了都能理解。
SFC最大的价值在于结构清晰。当你的设备有十几个甚至几十个工位，每个工位又有多个动作顺序的时候，用SFC可以把整个流程拆解得非常清楚。而且SFC天然支持并行分支和选择分支，可以处理复杂的流程逻辑。
但SFC也有一个坑：步的激活和去激活逻辑需要仔细设计。如果转换条件写得不好，可能会出现两个步同时激活的情况，导致输出混乱。我踩过这个坑，后来养成了一个习惯，每个转换条件都加上前一步的激活状态作为互锁，确保任何时刻只有一个步是激活的。
2.5 指令表IL：正在被淘汰但值得了解
IL是一种类似于汇编语言的文本编程方式，每一行是一条指令，操作码加操作数。现在新出的PLC编程软件里，IL的支持越来越少了，很多已经不再提供IL编辑器。但了解IL有助于理解PLC的底层执行逻辑，而且一些老设备上还在用IL程序，维护的时候需要能看懂。
2.6 语言选择速查表
| 语言 | 最适合场景 | 学习难度 | 调试便利性 | 可维护性 |
|---|---|---|---|---|
| LD梯形图 | 离散逻辑、联锁控制 | 低 | 高 | 中 |
| ST结构化文本 | 运算、数据处理、算法 | 中 | 中 | 高 |
| FBD功能块图 | 过程控制、信号处理 | 低 | 高 | 中 |
| SFC顺序功能图 | 步进控制、流程控制 | 中 | 中 | 高 |
| IL指令表 | 底层逻辑、老设备维护 | 高 | 低 | 低 |
实际项目中，很少只用一种语言。混合编程才是常态。我通常的做法是：整体程序框架用SFC搭，每个步里面具体的逻辑用LD或ST实现，模拟量处理用FBD，复杂运算用ST。这样各取所长，程序结构清晰，维护也方便。
3. 数据类型与变量：程序的地基
3.1 IEC61131定义的标准数据类型
IEC61131定义了一套标准的数据类型，这是保证程序可移植性的基础。最常用的几类：
布尔型（BOOL）：只有TRUE和FALSE两个值，对应开关量信号。在梯形图里就是一个触点或线圈。
整型：包括SINT（短整型，8位）、INT（整型，16位）、DINT（双整型，32位）、LINT（长整型，64位）。选哪种取决于你的数值范围。比如一个计数器最大计到1000，用INT就够了；如果要计到10万以上，就得用DINT。
无符号整型：USINT、UINT、UDINT、ULINT，跟有符号整型的区别就是不能表示负数，但正数范围更大。比如UINT的范围是0到65535，而INT是-32768到32767。
浮点型：REAL（32位）和LREAL（64位）。REAL的精度大约是6到7位有效数字，LREAL能到15到16位。做模拟量运算和PID控制的时候，一般用REAL就够了，除非对精度要求特别高。
时间型：TIME表示时间间隔，TOD表示一天中的时刻，DATE表示日期，DT表示日期时间。这些类型在做定时控制和数据记录的时候非常有用。
字符串型：STRING和WSTRING。STRING是单字节字符，WSTRING是宽字符，支持中文等多字节字符。做HMI显示和配方管理的时候会用到。
3.2 变量作用域：全局变量和局部变量怎么选
IEC61131把变量分为全局变量和局部变量。全局变量在整个程序中都能访问，局部变量只在定义它的程序组织单元（POU）内部有效。
新手最容易犯的错误就是滥用全局变量。觉得全局变量方便，哪里都能用，结果程序越写越乱，改一个地方影响一大片。我的经验是：能用局部变量就用局部变量，全局变量只用来传递那些确实需要跨程序共享的数据，比如设备状态、报警信息、配方参数。
局部变量还有一个好处是可重入。如果你把一个功能块封装好，里面的变量都是局部的，那这个功能块可以在程序的不同地方同时调用，互不干扰。这在做标准化程序库的时候特别重要。
3.3 直接地址与符号地址
直接地址就是直接写硬件的物理地址，比如%IX0.0表示输入模块第0个字节的第0位，%QW64表示输出模块的第64个字。符号地址就是给这个地址起个名字，比如“StartButton”对应%IX0.0，“MotorOutput”对应%QW64。
我强烈建议全部使用符号地址。原因很简单：可读性。你写%IX0.0，过两个月自己都不记得这是什么信号。但你写StartButton，一看就知道是启动按钮。而且如果硬件地址变了，你只需要在变量表里改一处，程序里所有引用这个变量的地方自动更新，不用满程序去找。
注意事项：有些老旧的编程软件对符号地址的支持不好，或者符号名长度有限制。这种情况下，至少要在变量表里做好注释，说明每个地址对应的物理信号。
4. 程序组织单元POU：把代码装进合适的盒子里
4.1 功能FC、功能块FB和程序PRG的区别
IEC61131定义了三种程序组织单元：功能（Function，FC）、功能块（Function Block，FB）和程序（Program，PRG）。这三个概念新手很容易搞混，我用一个生活化的类比来解释。
功能FC就像一个纯数学函数。你给它输入参数，它给你返回一个结果，不保留任何内部状态。比如一个计算平均值的功能，你传入五个数，它返回平均值。下次再调用，它不会记得上次算的是什么。FC适合做那些纯粹的运算和处理，不需要记忆状态的场景。
功能块FB就像一个带记忆的电子元件。你给它输入，它给你输出，但它会记住上一次的状态。比如一个定时器功能块，你给它启动信号，它开始计时，时间到了输出一个信号。下次再调用同一个定时器，它会从上次的状态继续。FB适合做那些需要保持状态的逻辑，比如定时器、计数器、PID控制器、状态机。
程序PRG是整个应用的顶层组织单元。一个项目里可以有多个PRG，每个PRG对应一个任务。比如你可以有一个主程序PRG负责整体调度，一个报警处理PRG负责报警逻辑，一个通信PRG负责数据交换。
4.2 功能块实例化：为什么每个调用都要一个实例
这是新手最容易踩的坑之一。功能块FB在使用之前必须先“实例化”，也就是给它分配一块内存来保存它的内部状态。如果你在程序里调用了两次同一个FB，但没有给它们分别分配实例，那这两个调用会共享同一块内存，互相干扰。
我举个例子：你写了一个电机控制FB，里面有启动、停止、故障复位等逻辑，内部有一个定时器用来做启动超时检测。如果你在程序里用这个FB控制两台电机，但只实例化了一次，那两台电机的定时器会互相影响，一台电机启动的时候，另一台电机的定时器也会被触发。这种bug非常隐蔽，调试的时候很难发现。
正确的做法是：每调用一次FB，就给它分配一个独立的实例。比如Motor1_FB和Motor2_FB，分别对应两台电机的控制实例。这样它们各自有独立的内部状态，互不干扰。
4.3 封装自己的功能块库
当你做了一段时间项目之后，会发现很多逻辑是重复的。比如电机控制、阀门控制、PID控制、报警处理，这些逻辑在每个项目里都会用到。这时候就应该把它们封装成标准的功能块，形成一个自己的库。
封装FB的好处是：一次编写，到处使用。而且因为经过了多个项目的验证，可靠性比每次重新写要高得多。我自己的库里积累了二十多个常用的FB，新项目开始的时候，先把这些FB导入进去，能省下大量的开发时间。
封装FB的时候要注意几点：接口要清晰，输入输出变量的命名要规范，让人一看就知道是什么意思；内部逻辑要健壮，要考虑各种异常情况，比如输入超范围、传感器故障等；要有注释和文档，说明这个FB的功能、参数含义、使用注意事项。
5. 任务与程序执行：程序是怎么跑起来的
5.1 周期扫描机制
PLC的工作方式是周期扫描，这一点跟普通计算机的程序执行方式完全不同。普通计算机的程序是事件驱动的，你不点击按钮，程序就不执行。PLC是循环执行的，从上电开始，它就一遍又一遍地扫描程序，周而复始，直到断电。
一个完整的扫描周期包括几个阶段：读取输入→执行程序→刷新输出→系统通信和处理。读取输入阶段，PLC把所有输入模块的信号读进来，存到输入映像区。执行程序阶段，PLC按照程序逻辑逐条执行，读写输入输出映像区和内部变量。刷新输出阶段，PLC把输出映像区的值写到输出模块上。系统通信和处理阶段，PLC处理通信请求、诊断等任务。
这个机制有一个重要的含义：程序执行期间，输入信号的变化不会立即反映到程序中。因为输入映像区是在扫描周期开始时统一读取的，程序执行期间用的是那一刻的快照。同样，程序执行期间对输出映像区的修改，也要等到扫描周期结束才会真正输出到硬件。
理解这一点对编程非常重要。比如你写了一个逻辑：如果按钮按下，就立即输出一个信号。但实际上，从按钮按下到输出信号真正发出，中间可能隔了一个完整的扫描周期。对于大多数应用来说，这个延迟（通常几毫秒到几十毫秒）是可以接受的，但对于高速响应要求的场合，就需要用中断来处理。
5.2 任务配置与优先级
稍微高级一点的PLC都支持多任务。你可以把程序分成几个任务，每个任务有不同的执行周期和优先级。比如：
- 主任务：周期10ms，负责常规逻辑控制
- 高速任务：周期1ms，负责高速计数和位置控制
- 慢速任务：周期100ms，负责数据处理和通信
任务优先级决定了当多个任务同时就绪时，哪个先执行。高优先级的任务可以打断低优先级的任务，这就是抢占式调度。配置任务的时候要小心，高优先级任务不能执行太长时间，否则会阻塞低优先级任务，导致系统响应变慢。
5.3 中断处理
中断是处理突发事件的机制。当某个事件发生时（比如一个高速输入信号到来），PLC暂停当前的任务，立即执行中断程序，处理完后再回到原来的任务继续执行。
中断程序要尽量短小，只做最紧急的处理，比如记录一个时间戳、设置一个标志位。复杂的处理逻辑应该放到主程序里，根据标志位来判断执行。中断程序执行时间过长，会影响其他任务的实时性。
6. 常见问题与排查技巧实录
6.1 程序能下载但运行不对，怎么查
这是最常见的问题。程序编译通过，下载到PLC也没报错，但设备就是不按预期动作。排查思路一般是从外到内，从硬到软。
先确认硬件接线是否正确。输入信号有没有真正到达PLC？输出信号有没有从PLC发出？用万用表量一下，或者看PLC上的指示灯。这一步能排除掉至少一半的问题。
硬件没问题的话，就打开编程软件的在线监控功能，看程序的执行状态。输入信号对应的变量有没有变化？逻辑条件是否满足？输出变量有没有被置位？一步步往下追，总能找到断点。
我遇到过一个案例：程序里用了一个定时器，设定时间是5秒，但实际动作要等十几秒才发生。查了半天发现是扫描周期的问题——那个定时器的使能条件在一个慢速任务里，任务周期是100ms，定时器的计时精度受到了影响。后来把定时器移到快速任务里就正常了。
6.2 模拟量信号波动大怎么办
模拟量信号波动是工控现场的老大难问题。原因可能有很多：传感器本身精度不够、信号线受到干扰、接地不良、PLC的模拟量模块分辨率不够。
处理办法分几步：先排除硬件问题。检查信号线是否用了屏蔽线，屏蔽层是否单端接地；检查传感器供电是否稳定；检查周围是否有变频器、大功率电机等干扰源。
硬件没问题的话，在程序里做软件滤波。最简单的是平均值滤波，连续采样N次取平均。N越大，滤波效果越好，但响应也越慢。我一般用10到20次。如果波动还是有规律的高频噪声，可以用一阶滞后滤波，效果比简单平均更好。
6.3 程序修改后下载，设备动作异常
这种情况通常是变量地址冲突或者程序逻辑遗漏导致的。修改程序的时候，如果不小心把某个变量的地址改了，或者删除了某个关键的逻辑段，就可能出现异常。
我的习惯是：每次修改程序之前，先备份当前版本。修改的时候，用软件的“交叉引用”功能检查变量的使用情况，确保没有遗漏。下载之前，先在仿真环境里跑一遍，确认逻辑正确再下载到实际设备。
还有一个容易忽略的点：掉电保持区。有些变量设置了掉电保持，PLC重新上电后这些变量会恢复成上次断电前的值。如果你修改了程序逻辑，但没有清除这些保持变量，可能会出现意料之外的行为。下载新程序之前，先清除保持区，让所有变量回到初始值。
6.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决措施 |
|---|---|---|---|
| 程序下载后无输出 | 输出模块未供电 | 检查输出模块电源 | 接通电源 |
| 输入信号不响应 | 输入地址配错 | 在线监控输入变量 | 修正变量地址 |
| 定时器不准 | 任务周期设置不当 | 检查任务配置 | 调整任务周期 |
| 模拟量波动 | 干扰或滤波不足 | 检查屏蔽和接地 | 增加软件滤波 |
| 通信中断 | 站号或波特率不匹配 | 检查通信参数 | 统一通信配置 |
| FB行为异常 | 实例未正确分配 | 检查FB调用 | 分配独立实例 |
6.5 几个保命的编程习惯
做了这么多年项目，我总结了几个能帮你少加班的习惯。
第一，变量命名要规范。不要用a、b、c这种名字，也不要用中文拼音缩写。用有意义的英文单词组合，比如Conveyor1_Start、Tank2_Level_High。变量表里写清楚注释，说明这个变量的物理含义。
第二，程序要分段。不管用梯形图还是ST，都要按功能把程序分成若干段，每段前面加注释说明这段是干什么的。不要把所有逻辑堆在一个网络里。
第三，关键逻辑要加互锁。特别是涉及安全的地方，比如电机的正反转、阀门的开关，一定要加互锁逻辑，防止同时动作。
第四，定期备份。每次修改程序之前备份，每个项目节点备份，项目结束后归档备份。我吃过亏，一个项目做了三个月，硬盘坏了，程序全没了，只能从头再来。
第五，仿真先行。现在大多数PLC编程软件都带仿真功能，程序写完后先在仿真里跑一遍，确认逻辑正确再下载到实际设备。能省下大量在现场调试的时间。
7. 从标准到实践：我的学习路径建议
如果你刚开始学PLC编程，我的建议是先不要贪多。先把梯形图吃透，能熟练地用梯形图写出常见的控制逻辑。然后学一个品牌的PLC编程软件，把基本的指令、功能块、程序结构搞清楚。这个阶段大概需要一到两个月。
有了基础之后，开始学ST语言。ST是你从“会编程”到“会写好程序”的关键一步。很多用梯形图写起来很别扭的逻辑，用ST写起来非常自然。学ST的时候，重点掌握条件判断、循环、数组、结构体这几个概念。
再往后，学SFC和功能块封装。这两个技能能帮你把程序组织得更加清晰，提高代码的复用率。到了这个阶段，你基本上可以独立负责一个中等规模的项目了。
最后，多看看别人写的程序。每个工程师都有自己的编程风格和技巧，看别人的程序能学到很多书本上没有的东西。我到现在还保持着看开源PLC程序和行业案例的习惯，每次都能发现一些新的思路。
IEC61131这套标准，刚开始看的时候可能觉得枯燥，但当你真正理解了它背后的设计思想，你会发现它其实是在帮你把程序写得更好、更规范、更容易维护。它不是束缚，而是工具。用好了，受益的是你自己。
