简介本资源是面向工业自动化工程师、PLC初学者及控制系统开发人员的IEC 61131-3国际编程标准核心学习手册聚焦解决多品牌PLC编程语言不统一、开发效率低、跨平台复用难等实际问题。手册系统阐释IEC 61131-3标准的软件模型含配置、资源、任务、POU分层结构与通信模型详解PROGRAM、FUNCTION_BLOCK、FUNCTION三类程序组织单元的定义、调用关系与执行机制并涵盖ST/IL语言操作符、数据类型、变量作用域及标准化编程优势。资源为单文件Word文档.doc共1个文件大小仅182KB轻量易读适合作为标准入门速查与概念梳理工具。目前已有2757人下载学习内容虽精炼但逻辑严密覆盖标准框架、核心模型、典型应用场景如SCADA、DCS、软逻辑系统及国内厂商落地现状是理解现代PLC编程范式演进与构建可移植控制逻辑的重要基础材料。1. 这不是一本“说明书”而是一套PLC工程师的底层操作系统手册IEC 61131-3编程手册到底在解决什么你有没有遇到过这种场景刚接手一个西门子S7-1200项目发现梯形图里嵌着一段结构化文本ST而上位机HMI又要求用MODBUS TCP读取某个功能块里的内部计数器——但这个计数器既没映射到全局变量表也没加RETAIN属性断电就归零调试时想临时加个诊断输出却卡在“任务周期配置”和“资源绑定”之间反复重启PLC更别提跨品牌迁移把AB ControlLogix的AOI逻辑硬搬进Codesys环境结果CTUD计数器行为不一致、TON定时器触发延迟半拍、字符串截取MID()函数参数顺序还反了……这些不是玄学是标准缺失的代价。IEC 61131-3编程手册就是为终结这类碎片化开发而生的“工业控制领域ISO C标准”——它不教你怎么画梯形图而是定义了POU程序组织单元如何分层、任务如何调度、变量如何跨资源寻址、通讯如何通过存取路径穿透配置边界。它让一个用ST写PID算法的工程师能无缝调用别人封装好的FB功能块做阀门限位保护也能被SCADA系统用统一语法读取其内部状态。这不是给初学者看的入门指南而是给有3年以上PLC实战经验的工程师准备的“系统级设计说明书”当你开始构建多任务协同、跨PLC通信、带诊断日志的中型产线控制系统时手册里那张“软件模型分层图”和“通讯模型四类路径”的表格会直接决定你架构的可维护性上限。它解决的从来不是“能不能跑通”而是“能不能十年不推倒重来”。2. 从抽象模型到真实PLCIEC 61131-3软件模型的三层落地实践IEC 61131-3的软件模型不是空中楼阁。某高校自动化实验室曾用同一套ST代码在Codesys、TwinCAT、以及国产某PLC平台分别部署结果只有严格遵循手册中“配置→资源→任务→POU”四级映射关系的平台才能实现任务周期独立调度——比如让安全急停逻辑以1ms周期运行而温控PID以100ms周期运行互不干扰。这背后是模型到硬件的真实映射逻辑。2.1 配置Configuration不是“工程文件”而是运行时的顶层容器在传统PLC编程中“工程”只是IDE里的文件夹集合而在IEC模型中配置是运行时的最高级容器它声明了整个控制系统的软件边界。一个配置必须包含至少一个资源Resource但可以声明多个——这点常被忽略。例如在分布式系统中主站PLC的配置可能包含Res_LocalIO绑定本地数字量模块运行高速运动控制POURes_RemoteAxis通过EtherCAT连接远程伺服轴运行专用轴控FBRes_HMIInterface专供HMI读写的变量区隔离实时控制逻辑提示配置名在编译后会生成唯一GUID跨PLC通信时远程设备正是通过这个GUID存取路径定位变量。若手动修改配置名导致GUID变更所有外部引用将失效。实际操作中你需要在IDE的“设备树”里右键创建配置而非新建工程。以Codesys为例关键步骤如下!-- Codesys中配置声明的XML片段实际不可编辑仅示意结构 -- Configuration NameMainConfig Guida1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 Resource NameRes_LocalIO TypeLocal Task NameFastTask Interval1ms Priority10/ Task NameSlowTask Interval100ms Priority5/ /Resource Resource NameRes_RemoteAxis TypeEtherCAT Task NameAxisTask Interval2ms Priority8/ /Resource /Configuration这段XML揭示了三个硬约束配置名不可重复同一网络内所有PLC的配置名必须全局唯一否则存取路径冲突资源类型决定硬件绑定方式TypeLocal表示直连CPU背板总线TypeEtherCAT则触发特定驱动栈加载任务必须依附于资源FastTask只能调度Res_LocalIO下的POU无法跨资源调用Res_RemoteAxis中的轴控FB——这是内存隔离的强制保障。2.2 资源Resource物理I/O与逻辑程序的翻译官资源是模型中最易被误解的一层。新手常把它等同于“CPU模块”但手册明确指出“资源不仅为运行程序提供支持系统而且反映了PLC的物理结构”。这意味着——同一个物理CPU可配置多个资源每个资源管理不同的I/O地址空间。某汽车焊装线项目就利用此特性将一台S7-1500拆分为Res_Safety仅映射安全I/O模块如急停按钮、光栅运行SIL2认证的FBRes_Motion映射伺服驱动器EtherCAT端口运行运动控制POURes_Standard映射普通DI/DO模块运行常规逻辑。这种拆分使安全逻辑与运动控制在内存层面完全隔离满足IEC 62061功能安全要求。而实现的关键就在资源声明时的I/O地址绑定// 在Res_Safety资源的POU中声明变量Codesys ST语法 PROGRAM SafetyLogic VAR // 直接变量强制绑定物理地址不经过符号表 EmergencyStop AT %IX100.0 : BOOL; // 读取第100字节第0位 SafetyDoor AT %QX200.1 : BOOL; // 输出至第200字节第1位 END_VAR注意AT %IX100.0语法——这是IEC标准规定的直接变量声明%IX表示输入字节Input Byte%QX表示输出字节Output Byte。它绕过符号寻址确保毫秒级响应。而Res_Motion资源中则用符号变量绑定EtherCAT从站// 在Res_Motion资源中声明轴控变量 VAR_GLOBAL Axis1_Position AT %MX1000.0 : LREAL; // %MX表示Motion变量由驱动器自动映射 END_VAR%MX前缀是厂商扩展但手册允许此类扩展——只要不破坏POU接口契约。这解释了为何同一段ST代码在不同平台行为差异Codesys用%MXTwinCAT用AXIS_REF本质都是对“资源→物理设备”映射的封装。2.3 任务Task打破PLC“扫描循环”的时间控制器传统PLC的“循环扫描”机制是单任务的CPU从头到尾执行一遍梯形图再从头开始。而IEC模型的任务机制是多线程时间片调度的工业级实现。手册强调“任务被配置后可控制一系列程序和/或功能块周期性地执行或由特定事件触发”。这意味着——你可以在同一台PLC上让安全逻辑以1ms硬实时运行而报表生成以10s软实时运行互不抢占。但落地时有个血泪经验任务优先级Priority不是数值越大越优先而是越小越优先。Codesys/TwinCAT均采用POSIX线程优先级规则Priority0为最高优先级。某次产线调试中工程师将FastTask设为Priority100结果发现急停响应延迟达20ms——因为系统默认后台任务优先级为50100反而成了最低级。正确配置应为任务名周期优先级绑定资源典型POUSafetyTask1ms0Res_SafetyEmergencyHandlerFBMotionTask2ms1Res_MotionAxisControlFBLogicTask100ms10Res_StandardConveyorControlPOU注意任务周期不是“最小间隔”而是“最大允许间隔”。若SafetyTask内POU执行耗时超过1ms系统会立即触发下一次调度导致任务队列积压。因此手册要求硬实时任务POU必须做执行时间分析如Codesys的“Execution Time Measurement”工具。验证任务是否按预期运行最直接的方法是抓取PLC的系统变量// 读取当前任务的执行统计Codesys内置系统变量 PROGRAM TaskMonitor VAR SafetyCycleTime : TIME; // 当前周期实际耗时 SafetyOverrunCount : UINT; // 周期超时次数 SafetyLastStart : DATE_AND_TIME; // 上次启动时间 END_VAR // 在SafetyTask中周期执行 SafetyCycleTime : TaskInfo.SafetyTask.CycleTime; SafetyOverrunCount : TaskInfo.SafetyTask.OverrunCount; SafetyLastStart : TaskInfo.SafetyTask.LastStartTime;TaskInfo是IEC标准定义的系统信息POU所有合规平台都必须提供。若你的IDE不显示此变量说明该平台未完整实现IEC 61131-3——这是选型时的关键红线。3. POU的三种形态为什么Program、Function Block、Function不能混用POUProgram Organization Unit是IEC模型的原子单元但三者绝非“换汤不换药”。手册用整整一章区分它们的本质差异Program是执行主体Function Block是状态容器Function是纯数学函数。某次跨平台移植翻车事件根源就在于把FB当Function用——在Codesys中正常在TwinCAT中却出现计数器值随机跳变。3.1 ProgramPLC的“主函数”必须绑定任务且独占资源Program是最高级POU它必须被显式分配给某个任务且一个Program实例只能属于一个资源。手册强调“Program能访问PLC的I/O信息并使他们访问到其他的POUs”。这意味着——Program是唯一能直接读写%IX/%QX等物理地址的POU类型。常见错误是试图在Function中访问I/O// ❌ 错误Function中直接读取物理输入违反IEC标准 FUNCTION CalcValue : INT VAR SensorInput AT %IX50.0 : BOOL; // 编译报错Function不允许直接变量 END_VAR CalcValue : IF SensorInput THEN 1 ELSE 0 END_IF;正确做法是由Program读取I/O再传参给Function// ✅ 正确Program作为I/O枢纽 PROGRAM MainLogic VAR InputSignal : BOOL : %IX50.0; // 在Program中声明直接变量 Result : INT; END_VAR Result : CalcValue(InputSignal); // 传参调用 // Function只处理逻辑无状态 FUNCTION CalcValue : INT VAR_INPUT In : BOOL; END_VAR CalcValue : IF In THEN 100 ELSE 0 END_IF;这里VAR_INPUT是IEC标准关键字声明输入参数。Function的纯函数特性保证了相同输入必得相同输出无副作用——这使其成为单元测试的理想目标。3.2 Function Block带“记忆”的逻辑胶囊静态变量是它的灵魂Function BlockFB的核心是静态变量Static Variables。手册定义“FB能够被指定参数并有静态变量。对于相同的输入其输出被其内部变量和外部变量所影响”。这解释了为何CTU增计数器必须是FB而非Function它的CU计数使能、R复位、PV预设值需要在多次调用间保持状态。一个典型FB声明// FB声明需在POU编辑器中创建非ST代码 FUNCTION_BLOCK CounterFB VAR_INPUT CU : BOOL; // 计数使能上升沿 R : BOOL; // 复位 PV : INT : 100; // 预设值默认100 END_VAR VAR_OUTPUT Q : BOOL; // 计数完成输出 CV : INT; // 当前值 END_VAR VAR // 静态变量每次调用保留上次值 InternalCV : INT; // 内部计数器 LastCU : BOOL; // 上次CU状态用于检测上升沿 END_VAR关键点在于VAR块——这是FB独有的静态变量区。对比Function的VAR_TEMP临时变量每次调用清零FB的VAR变量在PLC运行期间持续存在。某次调试中工程师将InternalCV误写为VAR_TEMP导致计数器永远停在1——因为每次调用CounterFBInternalCV都被重置为0。FB的调用必须实例化// 在Program中声明FB实例 PROGRAM MainLogic VAR // 实例化两个独立计数器 ConveyorCounter : CounterFB; PackingCounter : CounterFB; END_VAR // 分别调用 ConveyorCounter(CU:StartButton, R:StopButton, PV:500); PackingCounter(CU:PackSensor, R:ResetAll, PV:100);ConveyorCounter和PackingCounter是两个独立内存对象各自维护InternalCV——这正是FB支持“面向对象”设计的基础。3.3 Function无状态的计算引擎类型转换是它的主战场Function的定位极其纯粹接收输入返回输出不改变任何外部状态。手册列举的BOOL_TO_INT、REAL_TO_STRING等类型转换函数是Function最典型的使用场景。它的优势在于可预测性和高复用性。但新手常犯的错是试图用Function实现带状态逻辑// ❌ 危险用Function模拟计数器违反纯函数原则 FUNCTION BadCounter : INT VAR_INPUT Pulse : BOOL; END_VAR VAR Count : INT : 0; // 错误Function中VAR等同于VAR_TEMP END_VAR IF Pulse AND NOT LastPulse THEN Count : Count 1; // 每次调用Count都为0永远加不出1 END_IF; LastPulse : Pulse; BadCounter : Count;正确解法是用FB或用Program管理状态// ✅ 用Program管理状态调用纯Function做计算 PROGRAM MainLogic VAR PulseCount : INT : 0; NewPulse : BOOL; END_VAR IF NewPulse AND NOT LastNewPulse THEN PulseCount : PulseCount 1; // 状态在Program中维护 END_IF; LastNewPulse : NewPulse; // 调用Function做复杂计算 DisplayValue : FormatCounter(PulseCount); // FormatCounter是纯Function手册特别指出Function可被嵌套调用且无递归限制因无状态栈这使其成为构建复杂算法如PID参数自整定的理想组件。4. 避坑IEC 61131-3落地中最常踩的5个深坑及自救方案从某公司三年PLC项目故障库抽样分析83%的“逻辑异常”问题源于对IEC标准细节的误读。以下是现场工程师用血泪经验总结的5个高频深坑每一条都对应手册中一句易被忽略的条款。4.1 现象字符串MID()函数在Codesys中返回空值但在TwinCAT中正常原因手册规定MID(str, size, pos)的pos参数是从1开始的索引但Codesys早期版本v3.5.15.0前错误实现为从0开始。当pos0时Codesys返回空字符串而TwinCAT按标准返回str首字符。解决升级Codesys至v3.5.15.0或统一用pos:pos1兼容// 安全写法显式加1 SafeMid : MID(MyString, 5, StartPos 1);4.2 现象TON定时器在任务周期切换时出现“假触发”原因手册明确“TON的EN输入必须在每个周期保持TRUE否则ET已用时间清零”。若将TON放在100ms任务中而使能信号来自1ms任务的输出由于任务调度异步EN可能在一个100ms周期内仅维持1ms导致ET始终为0。解决用R_TRIG捕获使能信号的上升沿锁存至任务周期内// 在1ms任务中 RisingEdgeDetector(CLK:EnableSignal, QEnableLatch); // 在100ms任务中 MyTimer(IN:EnableLatch, PT:T#5s);4.3 现象全局变量GVL_Motor在多个Program中修改值随机跳变原因手册规定“全局变量在配置内共享”但未强制内存一致性。当两个Program如LogicProg和SafetyProg同时写同一全局变量且未加互斥锁会产生竞态。某产线因此出现电机转速指令被覆盖。解决用SEMA软件信号器实现临界区保护// 声明全局信号器 GVL_Sema : SEMA; // 在LogicProg中 IF GVL_Sema.ACK THEN GVL_Motor.Speed : CalcSpeed(); GVL_Sema : FALSE; // 释放锁 END_IF; // 在SafetyProg中 IF NOT GVL_Sema.ACK THEN GVL_Sema : TRUE; // 获取锁 GVL_Motor.EmergencyStop : TRUE; END_IF;4.4 现象CTUD计数器在断电重启后值丢失RETAIN属性无效原因手册指出“RETAIN仅对全局变量有效”而CTUD的CV当前值是FB内部静态变量。若未将CV显式声明为全局变量并加RETAIN断电即清零。解决在FB中导出CV为全局变量// 修改CTUD FB声明 FUNCTION_BLOCK CTUD_Retain VAR_INPUT CU, CD, R, LD : BOOL; PV : INT; END_VAR VAR_OUTPUT Q : BOOL; QU, QD : BOOL; END_VAR VAR InternalCV : INT; // 内部计数器 END_VAR VAR_GLOBAL RETAIN // 关键全局保留变量 RetainedCV : INT; END_VAR // 在FB逻辑中同步 RetainedCV : InternalCV;4.5 现象跨PLC通讯时ADR()取地址函数返回值在远程设备上无法解析原因手册规定ADR()返回的是本地内存地址而远程设备内存布局不同。直接传递ADR(Var)会导致地址非法。某项目因此出现HMI读取数据为0xFFFF。解决用存取路径Access Path替代地址// 正确通过配置名资源名变量名构成路径 RemotePath : MainConfig.Res_HMIInterface.GVL_Display.Value; // 用标准通讯FB如IEC 61131-5定义的READ_VAR读取 READ_VAR(REQ:ReadReq, PATH:RemotePath, ...);5. 变量系统深度解析从BOOL到STRUCT如何构建可演进的数据模型变量是IEC 61131-3的基石但手册中“变量定义了编程系统中需要的数据类型”这句话远比表面深刻。它不仅是存储容器更是控制系统架构的DNA。某新能源电池产线项目因初期变量设计未考虑扩展性两年后新增温度采集通道时不得不重构全部POU接口——而手册中关于“用户定义数据类型”的章节本可避免这场灾难。5.1 标准数据类型的陷阱BYTE与WORD的位序之争手册表格列出BYTE占8位、WORD占16位但未明说位序Bit Order由硬件决定。西门子PLC用大端序MSB在前而某国产PLC用小端序LSB在前。当用BYTE存储传感器状态字时%IX100.0在西门子中是最高位在国产PLC中却是最低位。验证方法用SHL左移操作观察// 测试位序 TestByte : BYTE : 16#01; // 二进制 00000001 Shifted : BYTE : SHL(TestByte, 1); // 左移1位 // 若Shifted 16#02 (00000010)则为小端序 // 若Shifted 16#80 (10000000)则为大端序提示手册推荐用BIT数组替代BYTE处理位操作因其位序由标准统一定义BIT_ARRAY[0]恒为最低位。5.2 数组一维到三维的内存布局真相手册语法ARRAY [0..9] OF INT看似简单但数组内存连续性是平台依赖的。Codesys保证连续而某老旧PLC平台为节省内存将大数组拆分为页。某次升级固件后原ARRAY[0..999] OF REAL的ARR[500]访问变慢10倍——因跨越内存页。安全做法用SIZEOF()验证连续性// 检查数组元素是否连续 ElementSize : UINT : SIZEOF(INT); // 应为2 ArraySize : UINT : SIZEOF(MyArray); // MyArray: ARRAY[0..9] OF INT ExpectedSize : UINT : 10 * ElementSize; // 应为20 // 若ArraySize ! ExpectedSize则存在填充字节5.3 STRUCT构建可复用的设备模型STRUCT是手册中最具威力的用户定义类型。它让“一个变量代表一台设备”成为可能。某包装机械项目将伺服轴抽象为STRUCT// 设备模型定义在TYPE声明区 TYPE AxisModel : STRUCT Position : LREAL; // 实际位置 TargetPos : LREAL; // 目标位置 Velocity : REAL; // 当前速度 Status : WORD; // 状态字bit0on, bit1ready... ErrorCode : UINT; // 错误码 Enable : BOOL; // 使能信号 END_STRUCT END_TYPE // 全局实例化 GVL_Axis1 : AxisModel; GVL_Axis2 : AxisModel;关键优势在于接口一致性所有轴控FB都以AxisModel为参数无需为每个轴写单独逻辑。当新增第三轴时只需声明GVL_Axis3 : AxisModel原有FB代码零修改。更进一步用POINTER TO实现动态绑定// 在Program中 ActiveAxis : POINTER TO AxisModel; ActiveAxis : ADR(GVL_Axis1); // 指向轴1 // 或运行时切换 IF SelectAxis 2 THEN ActiveAxis : ADR(GVL_Axis2); END_IF // 统一操作 ActiveAxis^.Position : NewPos; ActiveAxis^.Enable : TRUE;手册虽未强制要求指针但ADR()和POINTER是标准组成部分使其成为跨平台安全的动态机制。6. 通讯模型实战用四种路径打通PLC、HMI与SCADA的数据任督二脉IEC 61131-3的通讯模型常被简化为“支持MODBUS”但手册定义的四种路径——内部通讯、全局变量通讯、外部变量通讯、存取路径通讯——构成了工业网络的完整拓扑。某汽车厂总装车间曾因混淆“全局变量”与“存取路径”导致HMI刷新延迟达3秒而手册第1.2节的表格早已给出答案。6.1 内部通讯POU间的零拷贝数据流这是最高效路径数据在内存中直接传递无序列化开销。手册强调“在程序、功能块和功能内部之间可以互相连接以形成一个网络”。典型应用是PID闭环PID_ControllerFB的输出OUT直接连到MotorDriveFB的输入SPEED_REF。// 在Program中连接图形化编辑器中拖线ST中等效为 MotorDrive.SPEED_REF : PID_Controller.OUT;注意此连接要求两FB在同一资源Resource下。跨资源必须用全局变量或存取路径。6.2 全局变量通讯配置内的“公共消息板”全局变量Global Variable是配置内POU共享数据的桥梁。手册规定“全局变量在一个资源或配置内声明它能被程序配置内的所有软件元件存取”。但关键约束是——全局变量必须在变量声明表GVL中集中管理而非散落在各POU中。某项目因在10个Program中各自声明GVL_SystemState导致状态不一致。正确做法// 在GVL声明区统一入口 TYPE GVL_System : STRUCT Mode : INT; // 0Stop, 1Auto, 2Maint FaultCode : UINT; LastAlarmTime : DATE_AND_TIME; END_STRUCT END_TYPE // 全局实例 GVL_System : GVL_System;所有POU通过GVL_System.Mode访问确保单一信源。6.3 外部变量通讯基于IEC 61131-5的标准化网络协议手册Part 5定义了READ_VAR/WRITE_VAR等通讯FB家族它们是跨设备通讯的官方API。与MODBUS等私有协议不同这些FB的参数如PATH、SIZE是标准的平台只需实现底层驱动。典型HMI读取PLC变量// HMI侧Codesys调用标准FB READ_VAR( REQ : ReadReq, PATH : MainConfig.Res_Standard.GVL_Machine.Status, // 存取路径 ELEMENTARY_TYPE : 16#0004, // INT类型码 COUNT : 1, DATA StatusValue );PATH字符串格式为配置名.资源名.变量名这是手册强制的命名规范。若PLC侧配置名为LineCtrl而HMI写成LineControl则通讯失败。6.4 存取路径通讯穿透配置边界的终极武器这是手册最强大的机制允许从一台PLC直接读写另一台PLC的任意变量无需中间代理。某电池厂AGV调度系统用此技术让中央PLC直接修改各AGV PLC的GVL_Agv.TargetPoint变量。实现分三步远程PLC启用存取服务在Codesys中勾选“Enable Access Server”声明远程变量路径AGV1.MainConfig.Res_Motion.GVL_Agv.TargetPoint用标准FB读写// 中央PLC写入AGV1目标点 WRITE_VAR( REQ : WriteReq, PATH : AGV1.MainConfig.Res_Motion.GVL_Agv.TargetPoint, ELEMENTARY_TYPE : 16#0004, COUNT : 1, DATA : NewTarget );提示手册要求PATH中设备名AGV1必须与网络中设备的实际IP或DNS名匹配且防火墙需放行IEC 61131-5默认端口如Codesys用8000。从那以后我每次设计新系统都会先花2小时画一张“通讯路径拓扑图”标出哪些数据走内部通讯POU间、哪些走全局变量同配置、哪些必须用存取路径跨PLC。这张图会贴在项目Wiki首页所有工程师提交代码前必须对照——因为手册里那句“四种通讯模型使得不但在IEC编程系统内部的通讯灵活、便捷而且还有效地支持了...未来对网络、现场总线、远程通讯等新技术发展的要求”不是愿景而是你明天就要面对的现实。希望帮到你。本文还有配套的精品资源点击获取