PLC编程进阶：IEC定时器与计数器的局部变量声明与模块化设计

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）内部声明。

1. 在函数块（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在每个实例中都是完全独立、互不干扰的。

2. 在函数（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是不行的。但有两种变通方法：

1. 使用VAR_STATIC（静态变量）：如前例FC_Blinker。这会使FC带有“记忆”，破坏了其纯函数特性，通常只用于一些特定的、简单的工具函数，且需详细注释，因为其他工程师可能默认FC是无状态的。
2. 将定时器/计数器作为输入输出参数传递（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, tStepTimer=>myTimer, bStepDone=>y);

   这种方式保持了FC的无状态性，同时又能操作定时器，灵活性很高。

4. 不同PLC平台的具体实现与注意事项

虽然IEC标准是统一的，但各家IDE的具体操作略有不同。这里列举几个常见平台的关键点。

4.1 西门子 TIA Portal (S7-1200/1500)

西门子中，IEC定时器对应的是TON、TOF等系统功能块，计数器是CTU、CTD等。它们本身就是背景数据块（Instance DB）的调用。

在FB中声明：

1. 在FB的“静态变量”（Static）表中，直接定义变量，数据类型选择TON、CTU等。
2. 在程序段中调用时，从指令树拖出TON，在调用的“调用选项”对话框中，选择“多重实例”，然后从下拉列表中选择你刚才定义的静态变量名（如myTimer）。这会将这个定时器实例“嵌入”到当前FB的背景数据块中。
3. 绝对不要选择“单个实例”，那会在全局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中声明：

1. 在POU的声明部分（VAR区域），直接输入变量名和类型，如tonDelay: TON;。
2. 在代码体中直接调用tonDelay(IN:=bStart, PT:=T#5S);。
3. 在线监控时，展开对应的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 如何在线监控局部定时器/计数器？

这是新手最常遇到的问题：我在程序里用了局部定时器，在线时怎么看不到它的当前值？

解决方案：

1. 监控父级实例：你必须在线监控包含这个局部定时器的父级功能块实例。例如，定时器tDelay在FB_Valve中声明，而FB_Valve的实例名为Valve_01。那么你需要找到并打开Valve_01这个实例的在线数据视图。
2. 展开结构：在Valve_01的变量列表中，找到tDelay变量。它通常不会直接显示Q和ET。你需要点击它前面的“+”号或三角形图标，展开其内部结构，才能看到tDelay.Q、tDelay.ET、tDelay.IN、tDelay.PT等成员变量。
3. 添加到监视表：为了持续观察，你可以将Valve_01.tDelay.ET这样的完整路径添加到监视表（Watch Table）中。

6.2 常见编译错误与问题

1. “未定义的标识符”或“类型 TON 未找到”：

   • 原因：没有添加包含标准定时器/计数器的库（如Standard库）。
   • 解决：在项目树中，右键“库管理器”或“引用”，添加Standard库。

2. “功能块实例未初始化”警告：

   • 原因：在FB中声明了局部功能块实例，但在程序体中从未调用它。
   • 解决：确保在代码逻辑中（至少在某条路径下）对该实例进行了调用（即写了myTimer(IN:=... , PT:=...);这样的语句）。未调用的实例可能不会被分配内存或初始化。

3. 定时器不计时或状态不保持：

   • 检查1（最常见）：确认定时器实例的调用是否在每个扫描周期都执行。如果你把tonDelay(IN:=bStart, PT:=T#5S);放在一个IF...THEN条件块里，而条件不满足时该行代码不执行，那么定时器将得不到执行机会，自然无法工作。通常，定时器调用应放在条件判断之外，或者确保其IN为FALSE时也能被调用（以执行复位逻辑）。
   • 检查2：确认PT时间参数是否正确赋值。避免使用未初始化的变量作为PT值。
   • 检查3（针对FC静态变量）：如果在FC中使用VAR_STATIC声明的定时器，请确认该FC是否被持续调用。如果FC只在某个条件触发时调用一次，那么静态定时器也只在那一个周期工作一次。

4. 多个实例间相互干扰：

   • 症状：明明是两个独立的设备实例，但一个的定时器启动会影响另一个。
   • 原因：最可能的原因是错误地使用了单个实例（Single Instance）调用方式（在TIA Portal中常见），或者不小心将同一个定时器实例的引用传递给了多个FB。
   • 解决：复查每个设备FB内部的定时器声明，确保是独立的局部变量。检查调用选项是否为“多重实例”。

6.3 性能与内存考量

• 内存占用：每个局部定时器/计数器实例都会占用一定的内存（通常几十字节）。对于有成千上万个实例的大型系统，需要评估内存使用情况。不过，对于现代PLC的存储容量来说，这通常不是瓶颈。
• 执行时间：局部实例的调用开销与全局实例无异。使用数组和循环处理大量实例时，需注意扫描周期时间，避免在单个扫描周期内进行过于庞大的循环计算。可以考虑将处理分散到多个周期。

将IEC定时器和计数器声明为局部变量，是编写模块化、可重用、易维护PLC程序的必备技能。它初看可能比全局声明麻烦一点，但一旦形成习惯，其带来的结构清晰度和调试便利性是巨大的。从今天开始，尝试在你的新项目或旧项目重构中实践这一原则，你会发现你的代码库从此变得大不一样。记住，好的程序结构不是一次写成的，而是在每一次面对“是图省事用全局变量，还是多花两分钟设计局部实例”的选择时，坚持选择后者而逐渐塑造出来的。