1. 项目概述从全局变量到局部变量的思维转变在工业自动化编程尤其是基于IEC 61131-3标准的PLC编程中定时器Timer和计数器Counter是我们最常打交道的功能块。很多工程师尤其是从传统梯形图或经验丰富的老师傅那里入门的养成了一个习惯在全局变量表里声明所有的定时器和计数器。这样做直观、方便在任何程序块里都能直接调用。但当你开始构建更复杂、更模块化、需要被多次调用的函数块FB或程序PRG时这种“全局思维”就会带来麻烦。想象一下你写了一个精巧的阀门控制函数块里面用到了一个延时关闭的定时器。如果这个定时器是全局的那么你这个函数块就无法被同时用于控制两个不同的阀门——因为它们会共用同一个定时器实例导致时序完全混乱。所以“将IEC定时器和计数器声明为局部变量”这个需求本质上是一个编程范式从“面向过程”到“面向对象/模块化”的升级。它解决的核心问题是实例化Instantiation和数据封装Data Encapsulation。局部变量意味着变量生命周期和作用域被限制在其所属的程序组织单元POU内部。对于定时器和计数器这类功能块声明为局部变量就是在每次调用其父级POU时都会创建一个独立的、专有的实例拥有自己独立的内存空间和状态值从而实现了真正的可重用性。这不仅仅是语法上的小改动而是设计思路的跃迁。它让你的代码从一个“一锅炖”的全局脚本变成了由一个个独立、可插拔的“乐高积木”组成的系统。无论是西门子的TIA Portal、倍福的TwinCAT还是Codesys平台其底层逻辑都是相通的。掌握这个方法是写出高质量、易维护、可复用PLC代码的基石。2. 核心概念解析静态变量与功能块实例化要彻底搞懂如何局部声明必须先理解两个关键概念静态变量Static Variable和功能块实例化FB Instance。2.1 为什么定时器/计数器不能简单声明为局部“变量”在IEC 61131-3标准中TON接通延时定时器、CTU加计数器等它们并不是简单的数据类型如INT、BOOL而是功能块Function Block, FB。功能块与函数Function的最大区别在于它们拥有内部状态记忆。一个TON定时器需要记住当前计时值ET一个CTU计数器需要记住当前计数值CV。这些状态在扫描周期之间必须被保持。如果你在一个函数FC内部像声明一个INT变量那样声明一个定时器比如VAR myTimer: TON; // 错误这在FC中通常会导致问题 END_VAR在大多数系统中对于FC每次调用结束时其局部变量除非是STATIC通常会被初始化或状态不保留。这意味着myTimer的计时值在下个扫描周期可能就清零了无法实现延时功能。因此我们需要一种能在多次扫描间保持其内部状态的“局部”声明方式。2.2 静态变量VAR_STATIC与实例数据块Instance DB答案就是使用静态变量或在函数块FB内部声明。在函数块FB中声明这是最标准、最推荐的做法。FB本身就是为了管理状态而生的。在FB的变量声明区VAR或VAR_INST声明的定时器/计数器变量其生命周期与FB实例绑定。只要FB实例存在其内部的定时器状态就一直保持。这完美契合了定时器/计数器的需求。FUNCTION_BLOCK ValveControl VAR_INPUT bOpenCmd: BOOL; tDelayTime: TIME : T#2S; END_VAR VAR_OUTPUT bValveOpen: BOOL; END_VAR VAR // 在FB的VAR区声明相当于局部实例 tDelayTimer: TON; // 这是一个TON功能块的局部实例 END_VAR当你从OB1中调用ValveControlFB两次分别创建Valve1和Valve2两个实例时tDelayTimer在每个实例中都是完全独立、互不干扰的。在函数FC中使用静态变量VAR_STATIC某些情况下你可能需要在FC中实现一个简单的、带状态的功能。这时可以使用VAR_STATIC区域。静态变量在FC的整个生命周期内从PLC启动到停止保持其值不受FC调用结束的影响。但这需要非常小心因为它破坏了FC的“无状态”特性降低了可重用性通常不推荐作为主要方法。FUNCTION FC_Blinker: BOOL VAR_INPUT tCycleTime: TIME; END_VAR VAR_STATIC // 静态变量区 tBlinkTimer: TON; bFlipFlop: BOOL; END_VAR核心要点将定时器/计数器“局部化”的本质是将其作为一个功能块实例嵌入到另一个更高级的功能块FB的内部变量中。这个高级FB的实例本身可以是全局的也可以是另一个FB的局部变量从而形成层次化的实例树。3. 实操指南在不同POU类型中声明与调用理论清楚了我们来看具体怎么操作。我会以最常用的结构化文本ST语言为例在类Codesys的通用环境中进行说明。3.1 在函数块FB中声明为局部实例这是最经典和标准的模式。我们创建一个名为FB_Conveyor的函数块控制一条传送带需要用到启动延时和运行时间累计。FUNCTION_BLOCK FB_Conveyor VAR_INPUT bStart: BOOL; // 启动命令 bStop: BOOL; // 停止命令 tStartDelay: TIME : T#500ms; // 启动延时时间 END_VAR VAR_OUTPUT bRunning: BOOL; // 运行状态 tTotalRunTime: TIME; // 总运行时间累计 END_VAR VAR // 局部变量声明区 // 1. 声明定时器实例 tStartDelayTimer: TON; // 启动延时定时器 tRunTimeAccuTimer: TP; // 脉冲定时器用于累计运行时间每脉冲累加一个基准时间 // 2. 声明计数器实例 cJogPulseCounter: CTU; // 用于点动计数 // 3. 其他辅助变量 eInternalState: (IDLE, STARTING, RUNNING, STOPPING); tAccumulatedTime: TIME : T#0s; rCycleBaseTime: TIME : T#100ms; // 累计用的基准时间周期 END_VAR代码解读tStartDelayTimer: TON;这行代码在FB_Conveyor内部创建了一个TON功能块的实例。这个实例的名字是tStartDelayTimer它的生命周期和作用域完全局限于FB_Conveyor的某个具体实例比如Conveyor_A。同理cJogPulseCounter: CTU;创建了一个局部计数器实例。接下来我们需要在FB的程序体中对这些实例进行调用和逻辑编写。// FB_Conveyor 程序体 CASE eInternalState OF IDLE: bRunning : FALSE; tStartDelayTimer(IN:FALSE, PT:tStartDelay); // 复位延时定时器 cJogPulseCounter(R:TRUE); // 复位计数器 IF bStart AND NOT bStop THEN eInternalState : STARTING; END_IF STARTING: // 调用局部定时器实例IN为TRUE开始计时 tStartDelayTimer(IN:TRUE, PT:tStartDelay); IF tStartDelayTimer.Q THEN // 判断定时器实例的输出Q eInternalState : RUNNING; tStartDelayTimer(IN:FALSE); // 计时完成后复位定时器输入 ELSIF bStop THEN eInternalState : IDLE; END_IF RUNNING: bRunning : TRUE; // 使用TP脉冲定时器来累计时间简化模型实际可能用系统时间差 tRunTimeAccuTimer(IN:TRUE, PT:rCycleBaseTime); IF tRunTimeAccuTimer.Q THEN tAccumulatedTime : tAccumulatedTime rCycleBaseTime; END_IF tTotalRunTime : tAccumulatedTime; // 示例点动信号触发计数器 IF (*某个点动上升沿*) THEN cJogPulseCounter(CU:TRUE, PV:100); // 局部计数器实例计数 END_IF IF bStop THEN eInternalState : IDLE; END_IF END_CASE关键操作调用使用实例名如tStartDelayTimer就像调用一个功能块需要为其输入管脚IN, PT等赋值。访问状态通过实例名加点号访问其输出管脚如tStartDelayTimer.Q或当前值如tStartDelayTimer.ET。独立性如果你在OB1中声明了Conveyor_A: FB_Conveyor;和Conveyor_B: FB_Conveyor;那么Conveyor_A.tStartDelayTimer和Conveyor_B.tStartDelayTimer是两个完全独立的定时器互不影响。3.2 在程序PRG或主组织块如OB1中声明程序PRG可以看作是系统级别的、自动实例化的函数块。在PRG中声明的变量其作用域在这个PRG内但因为它通常只被系统调用一次所以这里的“局部”更像是“本程序全局”。不过这依然是实现设备级功能模块化的好方法避免污染真正的全局变量表。在TIA Portal的OB1或Codesys的主程序PRG中PROGRAM MAIN_PRGM VAR // 将设备控制FB实例化在这里而不是全局DB中 Feeder_1: FB_Conveyor; Feeder_2: FB_Conveyor; Mixer: FB_MixerControl; // 另一个FB // 甚至可以直接在这里声明简单的、仅在本程序使用的定时器 tGlobalCycleTimer: TON; END_VAR // 程序体 Feeder_1(bStart:%I0.0, bStop:%I0.1, tStartDelay:T#1S); Feeder_2(bStart:%I0.2, bStop:%I0.3, tStartDelay:T#2S); tGlobalCycleTimer(IN:TRUE, PT:T#10S); IF tGlobalCycleTimer.Q THEN // 每10秒执行一次的任务 tGlobalCycleTimer(IN:FALSE); // 复位自身准备下一次触发 END_IF这种方式将设备实例管理权收归主程序结构清晰全局变量表非常干净。3.3 在函数FC中声明需谨慎如前所述在标准的、无状态的FC中直接声明TON是不行的。但有两种变通方法使用VAR_STATIC静态变量如前例FC_Blinker。这会使FC带有“记忆”破坏了其纯函数特性通常只用于一些特定的、简单的工具函数且需详细注释因为其他工程师可能默认FC是无状态的。将定时器/计数器作为输入输出参数传递IN_OUT这是更优雅的方式。FC本身不“拥有”定时器而是操作一个从外部传入的定时器实例。FUNCTION FC_ProcessStep VAR_INPUT bExecute: BOOL; tDuration: TIME; END_VAR VAR_IN_OUT // 输入输出参数传递实例引用 tStepTimer: TON; // 注意这里声明的是TON类型但传递的是实例 END_VAR VAR_OUTPUT bStepDone: BOOL; END_VAR调用时// 在某个FB或PRG中 VAR myTimer: TON; END_VAR FC_ProcessStep(bExecute:x, tDuration:T#5S, tStepTimermyTimer, bStepDoney);这种方式保持了FC的无状态性同时又能操作定时器灵活性很高。4. 不同PLC平台的具体实现与注意事项虽然IEC标准是统一的但各家IDE的具体操作略有不同。这里列举几个常见平台的关键点。4.1 西门子 TIA Portal (S7-1200/1500)西门子中IEC定时器对应的是TON、TOF等系统功能块计数器是CTU、CTD等。它们本身就是背景数据块Instance DB的调用。在FB中声明在FB的“静态变量”Static表中直接定义变量数据类型选择TON、CTU等。在程序段中调用时从指令树拖出TON在调用的“调用选项”对话框中选择“多重实例”然后从下拉列表中选择你刚才定义的静态变量名如myTimer。这会将这个定时器实例“嵌入”到当前FB的背景数据块中。绝对不要选择“单个实例”那会在全局DB中创建就不是局部的了。在FC中操作如果想在FC中使用必须通过IN_OUT参数传入。在FC接口中定义一个IN_OUT变量数据类型为TON。调用FC时将外部的一个TON实例连接到此参数。在FC内部调用TON指令时同样选择“多重实例”并选择那个IN_OUT参数名。TIA Portal 重要心得使用“多重实例”后定时器/计数器的数据存储在其父级FB或FC的IN_OUT参数所关联的实例中。你需要进入该父级实例的数据块才能在线监控到定时器的ET、Q等状态值而不是在FC的局部变量表里看。4.2 倍福 TwinCAT 3 (基于 Codesys)TwinCAT的操作更贴近标准的IEC编程。在FB/PRG中声明在POU的声明部分VAR区域直接输入变量名和类型如tonDelay: TON;。在代码体中直接调用tonDelay(IN:bStart, PT:T#5S);。在线监控时展开对应的FB实例就能看到其内部的tonDelay变量进一步展开可以看到.Q,.ET等成员。在FC中操作推荐使用IN_OUT参数传递实例引用方法与上述通用描述一致。也可以使用VAR_STATIC但需注意其生命周期是整个任务周期。4.3 通用 Codesys 平台与TwinCAT类似声明和调用方式非常直接。需要注意的是库的引用。确保在项目树中已经添加了Standard库或Util库其中包含了TON,CTU等标准功能块。一个常见的 Codesys 项目结构示例MyProject ├── Application │ ├── PLC_PRG (PRG) - 主程序实例化设备FB │ ├── FB_Equipment (FB) - 设备层功能块内部声明局部定时器/计数器 │ ├── FB_Unit (FB) - 单元层功能块可能包含多个FB_Equipment实例 │ └── FC_Helper (FC) - 无状态工具函数通过IN_OUT操作定时器 ├── Libraries (已引用 Standard.lib) └── Global Variables - 尽量保持精简只放真正的全局信号如急停、总模式5. 高级技巧与设计模式掌握了基础声明后我们可以探讨一些提升代码质量的高级模式。5.1 使用自定义功能块封装复杂定时/计数逻辑如果你的设备需要一套复杂的、多状态的定时或计数序列不要在主FB里堆砌一堆TON和CTU。应该创建一个专用的自定义功能块来封装它们。例如创建一个FB_AdvancedTimer它内部可能包含多个标准TON、TOF并实现诸如“延时启动-运行-间歇暂停-超时报警”这样的复杂序列。对外只提供简洁的Start,Stop,Busy,Done,Error等接口。FUNCTION_BLOCK FB_AdvancedTimer VAR_INPUT bStart: BOOL; tPhase1, tPhase2, tTimeout: TIME; END_VAR VAR_OUTPUT bPhase1Active, bPhase2Active: BOOL; bSequenceDone: BOOL; bTimeoutFault: BOOL; END_VAR VAR tonPhase1: TON; tonPhase2: TON; tonWatchdog: TON; eInternalSeq: INT; END_VAR然后在你的主设备FB中只需要声明一个myAdvTimer: FB_AdvancedTimer;即可。这极大地简化了主程序的逻辑也便于复用和测试。5.2 数组化实例与批量处理当你有大量同类型的设备如50个加热区每个都需要自己的定时器时手动声明50个实例是灾难。此时可以使用数组。FUNCTION_BLOCK FB_HeatingZone VAR tHeatUpTimer: TON; tSoakTimer: TON; // ... 其他变量 END_VAR // 在主PRG或上级FB中 VAR aHeatingZones: ARRAY[1..50] OF FB_HeatingZone; END_VAR // 使用FOR循环批量处理 FOR i : 1 TO 50 DO aHeatingZones[i]( bStart : bStartAll AND NOT bFaults[i], tSetpoint : rGlobalSetpoint, // ... 其他参数连接 ); // 可以批量处理报警、状态采集等 bAnyZoneInFault : bAnyZoneInFault OR aHeatingZones[i].bFault; END_FOR这种方式不仅代码简洁而且由于索引是变量非常容易实现配方调用、批量参数设置等高级功能。5.3 通过方法Method访问内部状态在面向对象的扩展如OOP in Codesys中你可以为你的FB创建方法Method。例如为FB_Conveyor创建一个GetRunTime方法返回格式化的运行时间字符串。在方法内部你可以直接访问FB的局部变量包括那些定时器实例的当前值.ET但对外部调用者这些复杂的细节被隐藏了。这是一种更彻底的数据封装。6. 调试、监控与常见问题排查将定时器/计数器局部化后调试和监控方式与全局声明时有所不同。6.1 如何在线监控局部定时器/计数器这是新手最常遇到的问题我在程序里用了局部定时器在线时怎么看不到它的当前值解决方案监控父级实例你必须在线监控包含这个局部定时器的父级功能块实例。例如定时器tDelay在FB_Valve中声明而FB_Valve的实例名为Valve_01。那么你需要找到并打开Valve_01这个实例的在线数据视图。展开结构在Valve_01的变量列表中找到tDelay变量。它通常不会直接显示Q和ET。你需要点击它前面的“”号或三角形图标展开其内部结构才能看到tDelay.Q、tDelay.ET、tDelay.IN、tDelay.PT等成员变量。添加到监视表为了持续观察你可以将Valve_01.tDelay.ET这样的完整路径添加到监视表Watch Table中。6.2 常见编译错误与问题“未定义的标识符”或“类型 TON 未找到”原因没有添加包含标准定时器/计数器的库如Standard库。解决在项目树中右键“库管理器”或“引用”添加Standard库。“功能块实例未初始化”警告原因在FB中声明了局部功能块实例但在程序体中从未调用它。解决确保在代码逻辑中至少在某条路径下对该实例进行了调用即写了myTimer(IN:... , PT:...);这样的语句。未调用的实例可能不会被分配内存或初始化。定时器不计时或状态不保持检查1最常见确认定时器实例的调用是否在每个扫描周期都执行。如果你把tonDelay(IN:bStart, PT:T#5S);放在一个IF...THEN条件块里而条件不满足时该行代码不执行那么定时器将得不到执行机会自然无法工作。通常定时器调用应放在条件判断之外或者确保其IN为FALSE时也能被调用以执行复位逻辑。检查2确认PT时间参数是否正确赋值。避免使用未初始化的变量作为PT值。检查3针对FC静态变量如果在FC中使用VAR_STATIC声明的定时器请确认该FC是否被持续调用。如果FC只在某个条件触发时调用一次那么静态定时器也只在那一个周期工作一次。多个实例间相互干扰症状明明是两个独立的设备实例但一个的定时器启动会影响另一个。原因最可能的原因是错误地使用了单个实例Single Instance调用方式在TIA Portal中常见或者不小心将同一个定时器实例的引用传递给了多个FB。解决复查每个设备FB内部的定时器声明确保是独立的局部变量。检查调用选项是否为“多重实例”。6.3 性能与内存考量内存占用每个局部定时器/计数器实例都会占用一定的内存通常几十字节。对于有成千上万个实例的大型系统需要评估内存使用情况。不过对于现代PLC的存储容量来说这通常不是瓶颈。执行时间局部实例的调用开销与全局实例无异。使用数组和循环处理大量实例时需注意扫描周期时间避免在单个扫描周期内进行过于庞大的循环计算。可以考虑将处理分散到多个周期。将IEC定时器和计数器声明为局部变量是编写模块化、可重用、易维护PLC程序的必备技能。它初看可能比全局声明麻烦一点但一旦形成习惯其带来的结构清晰度和调试便利性是巨大的。从今天开始尝试在你的新项目或旧项目重构中实践这一原则你会发现你的代码库从此变得大不一样。记住好的程序结构不是一次写成的而是在每一次面对“是图省事用全局变量还是多花两分钟设计局部实例”的选择时坚持选择后者而逐渐塑造出来的。
PLC编程进阶：IEC定时器与计数器的局部变量声明与模块化设计
发布时间：2026/5/16 14:56:52
1. 项目概述从全局变量到局部变量的思维转变在工业自动化编程尤其是基于IEC 61131-3标准的PLC编程中定时器Timer和计数器Counter是我们最常打交道的功能块。很多工程师尤其是从传统梯形图或经验丰富的老师傅那里入门的养成了一个习惯在全局变量表里声明所有的定时器和计数器。这样做直观、方便在任何程序块里都能直接调用。但当你开始构建更复杂、更模块化、需要被多次调用的函数块FB或程序PRG时这种“全局思维”就会带来麻烦。想象一下你写了一个精巧的阀门控制函数块里面用到了一个延时关闭的定时器。如果这个定时器是全局的那么你这个函数块就无法被同时用于控制两个不同的阀门——因为它们会共用同一个定时器实例导致时序完全混乱。所以“将IEC定时器和计数器声明为局部变量”这个需求本质上是一个编程范式从“面向过程”到“面向对象/模块化”的升级。它解决的核心问题是实例化Instantiation和数据封装Data Encapsulation。局部变量意味着变量生命周期和作用域被限制在其所属的程序组织单元POU内部。对于定时器和计数器这类功能块声明为局部变量就是在每次调用其父级POU时都会创建一个独立的、专有的实例拥有自己独立的内存空间和状态值从而实现了真正的可重用性。这不仅仅是语法上的小改动而是设计思路的跃迁。它让你的代码从一个“一锅炖”的全局脚本变成了由一个个独立、可插拔的“乐高积木”组成的系统。无论是西门子的TIA Portal、倍福的TwinCAT还是Codesys平台其底层逻辑都是相通的。掌握这个方法是写出高质量、易维护、可复用PLC代码的基石。2. 核心概念解析静态变量与功能块实例化要彻底搞懂如何局部声明必须先理解两个关键概念静态变量Static Variable和功能块实例化FB Instance。2.1 为什么定时器/计数器不能简单声明为局部“变量”在IEC 61131-3标准中TON接通延时定时器、CTU加计数器等它们并不是简单的数据类型如INT、BOOL而是功能块Function Block, FB。功能块与函数Function的最大区别在于它们拥有内部状态记忆。一个TON定时器需要记住当前计时值ET一个CTU计数器需要记住当前计数值CV。这些状态在扫描周期之间必须被保持。如果你在一个函数FC内部像声明一个INT变量那样声明一个定时器比如VAR myTimer: TON; // 错误这在FC中通常会导致问题 END_VAR在大多数系统中对于FC每次调用结束时其局部变量除非是STATIC通常会被初始化或状态不保留。这意味着myTimer的计时值在下个扫描周期可能就清零了无法实现延时功能。因此我们需要一种能在多次扫描间保持其内部状态的“局部”声明方式。2.2 静态变量VAR_STATIC与实例数据块Instance DB答案就是使用静态变量或在函数块FB内部声明。在函数块FB中声明这是最标准、最推荐的做法。FB本身就是为了管理状态而生的。在FB的变量声明区VAR或VAR_INST声明的定时器/计数器变量其生命周期与FB实例绑定。只要FB实例存在其内部的定时器状态就一直保持。这完美契合了定时器/计数器的需求。FUNCTION_BLOCK ValveControl VAR_INPUT bOpenCmd: BOOL; tDelayTime: TIME : T#2S; END_VAR VAR_OUTPUT bValveOpen: BOOL; END_VAR VAR // 在FB的VAR区声明相当于局部实例 tDelayTimer: TON; // 这是一个TON功能块的局部实例 END_VAR当你从OB1中调用ValveControlFB两次分别创建Valve1和Valve2两个实例时tDelayTimer在每个实例中都是完全独立、互不干扰的。在函数FC中使用静态变量VAR_STATIC某些情况下你可能需要在FC中实现一个简单的、带状态的功能。这时可以使用VAR_STATIC区域。静态变量在FC的整个生命周期内从PLC启动到停止保持其值不受FC调用结束的影响。但这需要非常小心因为它破坏了FC的“无状态”特性降低了可重用性通常不推荐作为主要方法。FUNCTION FC_Blinker: BOOL VAR_INPUT tCycleTime: TIME; END_VAR VAR_STATIC // 静态变量区 tBlinkTimer: TON; bFlipFlop: BOOL; END_VAR核心要点将定时器/计数器“局部化”的本质是将其作为一个功能块实例嵌入到另一个更高级的功能块FB的内部变量中。这个高级FB的实例本身可以是全局的也可以是另一个FB的局部变量从而形成层次化的实例树。3. 实操指南在不同POU类型中声明与调用理论清楚了我们来看具体怎么操作。我会以最常用的结构化文本ST语言为例在类Codesys的通用环境中进行说明。3.1 在函数块FB中声明为局部实例这是最经典和标准的模式。我们创建一个名为FB_Conveyor的函数块控制一条传送带需要用到启动延时和运行时间累计。FUNCTION_BLOCK FB_Conveyor VAR_INPUT bStart: BOOL; // 启动命令 bStop: BOOL; // 停止命令 tStartDelay: TIME : T#500ms; // 启动延时时间 END_VAR VAR_OUTPUT bRunning: BOOL; // 运行状态 tTotalRunTime: TIME; // 总运行时间累计 END_VAR VAR // 局部变量声明区 // 1. 声明定时器实例 tStartDelayTimer: TON; // 启动延时定时器 tRunTimeAccuTimer: TP; // 脉冲定时器用于累计运行时间每脉冲累加一个基准时间 // 2. 声明计数器实例 cJogPulseCounter: CTU; // 用于点动计数 // 3. 其他辅助变量 eInternalState: (IDLE, STARTING, RUNNING, STOPPING); tAccumulatedTime: TIME : T#0s; rCycleBaseTime: TIME : T#100ms; // 累计用的基准时间周期 END_VAR代码解读tStartDelayTimer: TON;这行代码在FB_Conveyor内部创建了一个TON功能块的实例。这个实例的名字是tStartDelayTimer它的生命周期和作用域完全局限于FB_Conveyor的某个具体实例比如Conveyor_A。同理cJogPulseCounter: CTU;创建了一个局部计数器实例。接下来我们需要在FB的程序体中对这些实例进行调用和逻辑编写。// FB_Conveyor 程序体 CASE eInternalState OF IDLE: bRunning : FALSE; tStartDelayTimer(IN:FALSE, PT:tStartDelay); // 复位延时定时器 cJogPulseCounter(R:TRUE); // 复位计数器 IF bStart AND NOT bStop THEN eInternalState : STARTING; END_IF STARTING: // 调用局部定时器实例IN为TRUE开始计时 tStartDelayTimer(IN:TRUE, PT:tStartDelay); IF tStartDelayTimer.Q THEN // 判断定时器实例的输出Q eInternalState : RUNNING; tStartDelayTimer(IN:FALSE); // 计时完成后复位定时器输入 ELSIF bStop THEN eInternalState : IDLE; END_IF RUNNING: bRunning : TRUE; // 使用TP脉冲定时器来累计时间简化模型实际可能用系统时间差 tRunTimeAccuTimer(IN:TRUE, PT:rCycleBaseTime); IF tRunTimeAccuTimer.Q THEN tAccumulatedTime : tAccumulatedTime rCycleBaseTime; END_IF tTotalRunTime : tAccumulatedTime; // 示例点动信号触发计数器 IF (*某个点动上升沿*) THEN cJogPulseCounter(CU:TRUE, PV:100); // 局部计数器实例计数 END_IF IF bStop THEN eInternalState : IDLE; END_IF END_CASE关键操作调用使用实例名如tStartDelayTimer就像调用一个功能块需要为其输入管脚IN, PT等赋值。访问状态通过实例名加点号访问其输出管脚如tStartDelayTimer.Q或当前值如tStartDelayTimer.ET。独立性如果你在OB1中声明了Conveyor_A: FB_Conveyor;和Conveyor_B: FB_Conveyor;那么Conveyor_A.tStartDelayTimer和Conveyor_B.tStartDelayTimer是两个完全独立的定时器互不影响。3.2 在程序PRG或主组织块如OB1中声明程序PRG可以看作是系统级别的、自动实例化的函数块。在PRG中声明的变量其作用域在这个PRG内但因为它通常只被系统调用一次所以这里的“局部”更像是“本程序全局”。不过这依然是实现设备级功能模块化的好方法避免污染真正的全局变量表。在TIA Portal的OB1或Codesys的主程序PRG中PROGRAM MAIN_PRGM VAR // 将设备控制FB实例化在这里而不是全局DB中 Feeder_1: FB_Conveyor; Feeder_2: FB_Conveyor; Mixer: FB_MixerControl; // 另一个FB // 甚至可以直接在这里声明简单的、仅在本程序使用的定时器 tGlobalCycleTimer: TON; END_VAR // 程序体 Feeder_1(bStart:%I0.0, bStop:%I0.1, tStartDelay:T#1S); Feeder_2(bStart:%I0.2, bStop:%I0.3, tStartDelay:T#2S); tGlobalCycleTimer(IN:TRUE, PT:T#10S); IF tGlobalCycleTimer.Q THEN // 每10秒执行一次的任务 tGlobalCycleTimer(IN:FALSE); // 复位自身准备下一次触发 END_IF这种方式将设备实例管理权收归主程序结构清晰全局变量表非常干净。3.3 在函数FC中声明需谨慎如前所述在标准的、无状态的FC中直接声明TON是不行的。但有两种变通方法使用VAR_STATIC静态变量如前例FC_Blinker。这会使FC带有“记忆”破坏了其纯函数特性通常只用于一些特定的、简单的工具函数且需详细注释因为其他工程师可能默认FC是无状态的。将定时器/计数器作为输入输出参数传递IN_OUT这是更优雅的方式。FC本身不“拥有”定时器而是操作一个从外部传入的定时器实例。FUNCTION FC_ProcessStep VAR_INPUT bExecute: BOOL; tDuration: TIME; END_VAR VAR_IN_OUT // 输入输出参数传递实例引用 tStepTimer: TON; // 注意这里声明的是TON类型但传递的是实例 END_VAR VAR_OUTPUT bStepDone: BOOL; END_VAR调用时// 在某个FB或PRG中 VAR myTimer: TON; END_VAR FC_ProcessStep(bExecute:x, tDuration:T#5S, tStepTimermyTimer, bStepDoney);这种方式保持了FC的无状态性同时又能操作定时器灵活性很高。4. 不同PLC平台的具体实现与注意事项虽然IEC标准是统一的但各家IDE的具体操作略有不同。这里列举几个常见平台的关键点。4.1 西门子 TIA Portal (S7-1200/1500)西门子中IEC定时器对应的是TON、TOF等系统功能块计数器是CTU、CTD等。它们本身就是背景数据块Instance DB的调用。在FB中声明在FB的“静态变量”Static表中直接定义变量数据类型选择TON、CTU等。在程序段中调用时从指令树拖出TON在调用的“调用选项”对话框中选择“多重实例”然后从下拉列表中选择你刚才定义的静态变量名如myTimer。这会将这个定时器实例“嵌入”到当前FB的背景数据块中。绝对不要选择“单个实例”那会在全局DB中创建就不是局部的了。在FC中操作如果想在FC中使用必须通过IN_OUT参数传入。在FC接口中定义一个IN_OUT变量数据类型为TON。调用FC时将外部的一个TON实例连接到此参数。在FC内部调用TON指令时同样选择“多重实例”并选择那个IN_OUT参数名。TIA Portal 重要心得使用“多重实例”后定时器/计数器的数据存储在其父级FB或FC的IN_OUT参数所关联的实例中。你需要进入该父级实例的数据块才能在线监控到定时器的ET、Q等状态值而不是在FC的局部变量表里看。4.2 倍福 TwinCAT 3 (基于 Codesys)TwinCAT的操作更贴近标准的IEC编程。在FB/PRG中声明在POU的声明部分VAR区域直接输入变量名和类型如tonDelay: TON;。在代码体中直接调用tonDelay(IN:bStart, PT:T#5S);。在线监控时展开对应的FB实例就能看到其内部的tonDelay变量进一步展开可以看到.Q,.ET等成员。在FC中操作推荐使用IN_OUT参数传递实例引用方法与上述通用描述一致。也可以使用VAR_STATIC但需注意其生命周期是整个任务周期。4.3 通用 Codesys 平台与TwinCAT类似声明和调用方式非常直接。需要注意的是库的引用。确保在项目树中已经添加了Standard库或Util库其中包含了TON,CTU等标准功能块。一个常见的 Codesys 项目结构示例MyProject ├── Application │ ├── PLC_PRG (PRG) - 主程序实例化设备FB │ ├── FB_Equipment (FB) - 设备层功能块内部声明局部定时器/计数器 │ ├── FB_Unit (FB) - 单元层功能块可能包含多个FB_Equipment实例 │ └── FC_Helper (FC) - 无状态工具函数通过IN_OUT操作定时器 ├── Libraries (已引用 Standard.lib) └── Global Variables - 尽量保持精简只放真正的全局信号如急停、总模式5. 高级技巧与设计模式掌握了基础声明后我们可以探讨一些提升代码质量的高级模式。5.1 使用自定义功能块封装复杂定时/计数逻辑如果你的设备需要一套复杂的、多状态的定时或计数序列不要在主FB里堆砌一堆TON和CTU。应该创建一个专用的自定义功能块来封装它们。例如创建一个FB_AdvancedTimer它内部可能包含多个标准TON、TOF并实现诸如“延时启动-运行-间歇暂停-超时报警”这样的复杂序列。对外只提供简洁的Start,Stop,Busy,Done,Error等接口。FUNCTION_BLOCK FB_AdvancedTimer VAR_INPUT bStart: BOOL; tPhase1, tPhase2, tTimeout: TIME; END_VAR VAR_OUTPUT bPhase1Active, bPhase2Active: BOOL; bSequenceDone: BOOL; bTimeoutFault: BOOL; END_VAR VAR tonPhase1: TON; tonPhase2: TON; tonWatchdog: TON; eInternalSeq: INT; END_VAR然后在你的主设备FB中只需要声明一个myAdvTimer: FB_AdvancedTimer;即可。这极大地简化了主程序的逻辑也便于复用和测试。5.2 数组化实例与批量处理当你有大量同类型的设备如50个加热区每个都需要自己的定时器时手动声明50个实例是灾难。此时可以使用数组。FUNCTION_BLOCK FB_HeatingZone VAR tHeatUpTimer: TON; tSoakTimer: TON; // ... 其他变量 END_VAR // 在主PRG或上级FB中 VAR aHeatingZones: ARRAY[1..50] OF FB_HeatingZone; END_VAR // 使用FOR循环批量处理 FOR i : 1 TO 50 DO aHeatingZones[i]( bStart : bStartAll AND NOT bFaults[i], tSetpoint : rGlobalSetpoint, // ... 其他参数连接 ); // 可以批量处理报警、状态采集等 bAnyZoneInFault : bAnyZoneInFault OR aHeatingZones[i].bFault; END_FOR这种方式不仅代码简洁而且由于索引是变量非常容易实现配方调用、批量参数设置等高级功能。5.3 通过方法Method访问内部状态在面向对象的扩展如OOP in Codesys中你可以为你的FB创建方法Method。例如为FB_Conveyor创建一个GetRunTime方法返回格式化的运行时间字符串。在方法内部你可以直接访问FB的局部变量包括那些定时器实例的当前值.ET但对外部调用者这些复杂的细节被隐藏了。这是一种更彻底的数据封装。6. 调试、监控与常见问题排查将定时器/计数器局部化后调试和监控方式与全局声明时有所不同。6.1 如何在线监控局部定时器/计数器这是新手最常遇到的问题我在程序里用了局部定时器在线时怎么看不到它的当前值解决方案监控父级实例你必须在线监控包含这个局部定时器的父级功能块实例。例如定时器tDelay在FB_Valve中声明而FB_Valve的实例名为Valve_01。那么你需要找到并打开Valve_01这个实例的在线数据视图。展开结构在Valve_01的变量列表中找到tDelay变量。它通常不会直接显示Q和ET。你需要点击它前面的“”号或三角形图标展开其内部结构才能看到tDelay.Q、tDelay.ET、tDelay.IN、tDelay.PT等成员变量。添加到监视表为了持续观察你可以将Valve_01.tDelay.ET这样的完整路径添加到监视表Watch Table中。6.2 常见编译错误与问题“未定义的标识符”或“类型 TON 未找到”原因没有添加包含标准定时器/计数器的库如Standard库。解决在项目树中右键“库管理器”或“引用”添加Standard库。“功能块实例未初始化”警告原因在FB中声明了局部功能块实例但在程序体中从未调用它。解决确保在代码逻辑中至少在某条路径下对该实例进行了调用即写了myTimer(IN:... , PT:...);这样的语句。未调用的实例可能不会被分配内存或初始化。定时器不计时或状态不保持检查1最常见确认定时器实例的调用是否在每个扫描周期都执行。如果你把tonDelay(IN:bStart, PT:T#5S);放在一个IF...THEN条件块里而条件不满足时该行代码不执行那么定时器将得不到执行机会自然无法工作。通常定时器调用应放在条件判断之外或者确保其IN为FALSE时也能被调用以执行复位逻辑。检查2确认PT时间参数是否正确赋值。避免使用未初始化的变量作为PT值。检查3针对FC静态变量如果在FC中使用VAR_STATIC声明的定时器请确认该FC是否被持续调用。如果FC只在某个条件触发时调用一次那么静态定时器也只在那一个周期工作一次。多个实例间相互干扰症状明明是两个独立的设备实例但一个的定时器启动会影响另一个。原因最可能的原因是错误地使用了单个实例Single Instance调用方式在TIA Portal中常见或者不小心将同一个定时器实例的引用传递给了多个FB。解决复查每个设备FB内部的定时器声明确保是独立的局部变量。检查调用选项是否为“多重实例”。6.3 性能与内存考量内存占用每个局部定时器/计数器实例都会占用一定的内存通常几十字节。对于有成千上万个实例的大型系统需要评估内存使用情况。不过对于现代PLC的存储容量来说这通常不是瓶颈。执行时间局部实例的调用开销与全局实例无异。使用数组和循环处理大量实例时需注意扫描周期时间避免在单个扫描周期内进行过于庞大的循环计算。可以考虑将处理分散到多个周期。将IEC定时器和计数器声明为局部变量是编写模块化、可重用、易维护PLC程序的必备技能。它初看可能比全局声明麻烦一点但一旦形成习惯其带来的结构清晰度和调试便利性是巨大的。从今天开始尝试在你的新项目或旧项目重构中实践这一原则你会发现你的代码库从此变得大不一样。记住好的程序结构不是一次写成的而是在每一次面对“是图省事用全局变量还是多花两分钟设计局部实例”的选择时坚持选择后者而逐渐塑造出来的。
