3. PLC程序组织与任务配置
在TwinCAT 3中，PLC程序并不是“写在一个文件里从头跑到尾”的单一脚本，而是由POU（Program Organization Unit，程序组织单元）、任务（Task）和实时调度器共同构成的分层执行体系。理解这套体系，是让程序既能正确运行、又能满足实时性要求的前提。本节围绕程序组织、任务周期、优先级、看门狗和实时性参数展开，重点说明“怎么配、配了以后会发生什么”。
一、MAIN程序与POU：程序的组织骨架
每个TwinCAT PLC项目默认包含一个MAIN程序（PRG类型）。MAIN是程序执行的入口，但它本身并不神秘——它只是一个被任务调用的普通POU。真正决定“谁在什么时候执行”的，是任务与POU的绑定关系。
POU按实现语言可分为几类，它们可以混合使用，最终都编译为PLC可执行代码：
- PRG（Program）：程序单元，可被任务直接调用，内部可声明输入/输出/局部变量，适合作为主逻辑或功能模块。
- FBD（Function Block Diagram）：功能块图，用图形化方框和连线表达逻辑，适合布尔逻辑、联锁和信号处理。
- LD（Ladder Diagram）：梯形图，接近继电器逻辑，适合电气工程师阅读和维护。
- ST（Structured Text）：结构化文本，类似Pascal的高级语言，适合算法、循环、数学运算和复杂条件判断。
- CFC（Continuous Function Chart）：连续功能图，自由布局的功能块网络，适合过程控制、信号流和复杂数据流表达。
实际工程中常见的组织方式是：MAIN作为顶层调度程序，内部按功能调用若干子PRG或功能块，例如PRG_Motion、PRG_IO、PRG_HMI。这样做的价值在于：任务可以只绑定MAIN，而MAIN内部再决定调用顺序；也可以把不同PRG分别绑定到不同任务，实现“快任务跑快逻辑、慢任务跑慢逻辑”。
二、任务周期与优先级：实时性的核心参数
TwinCAT的任务由实时内核调度，每个任务有四个关键参数：周期（Cycle Time）、优先级（Priority）、看门狗时间（Watchdog）和任务类型（Cyclic / Event）。它们共同决定程序的实时行为。
周期是任务被触发的间隔。例如设置Cycle Time = 1 ms，任务每1 ms执行一次。周期越短，控制响应越快，但CPU负载越高。TwinCAT允许的最小周期取决于CPU性能和任务数量，常见工程中：
- 高速运动控制任务：250 µs ~ 1 ms
- 普通逻辑与IO任务：2 ms ~ 10 ms
- HMI通信、数据记录任务：10 ms ~ 100 ms
优先级决定多个任务同时就绪时谁先执行。TwinCAT优先级数值越小，优先级越高（0为最高）。例如：
- 运动控制任务：优先级 1，周期 500 µs
- IO与逻辑任务：优先级 5，周期 2 ms
- HMI与日志任务：优先级 20，周期 20 ms
高优先级任务可以抢占低优先级任务。如果高优先级任务执行时间过长，低优先级任务会被推迟，甚至导致看门狗超时。因此，优先级配置必须与周期和实际执行时间匹配。
示例：假设运动任务周期500 µs，实测执行时间120 µs；IO任务周期2 ms，执行时间300 µs。运动任务每500 µs占用120 µs，CPU占用率约24%；IO任务每2 ms占用300 µs，占用率约15%。两者叠加后总负载约39%，系统仍有充足余量。若运动任务执行时间涨到400 µs，占用率升至80%，IO任务就可能被频繁打断，导致周期抖动。
三、看门狗与实时性参数设置
看门狗（Watchdog）是任务的“超时保护”。如果任务在设定时间内没有执行完，TwinCAT会触发看门狗错误，通常表现为PLC进入停止状态或任务被挂起。看门狗时间一般设置为任务周期的1.5~3倍。例如周期2 ms的任务，看门狗可设为5 ms。这样既能容忍偶发的执行抖动，又能在程序死循环或阻塞时及时暴露问题。
实时性参数还包括任务偏移（Offset）和CPU亲和性（Affinity）。偏移用于错开多个任务的触发时刻，避免它们在同一时刻争抢CPU。例如两个周期均为1 ms的任务，可分别设置偏移0 µs和500 µs，使它们交替执行。CPU亲和性则把任务绑定到特定CPU核心，减少核心间迁移带来的抖动，在多核工控机上尤其有用。
配置任务时，建议遵循以下顺序：先确定控制对象的响应要求，再分配周期；根据周期和实测执行时间确定优先级；最后设置看门狗和偏移。不要先写程序再“随便配一个周期”，否则后期很难调优。
四、从配置到验证：如何判断实时性是否达标
任务配置完成后，不能只看“程序能跑”，还要验证实时性。TwinCAT提供了几种观察手段：
- 任务负载（Task Load）：在TwinCAT System Manager或XAE中查看每个任务的CPU占用率。一般建议单任务不超过50%，总负载不超过70%。
- 周期抖动（Jitter）：观察任务实际执行间隔与设定周期的偏差。抖动过大说明优先级或CPU亲和性需要调整。
- 看门狗计数：如果看门狗频繁触发，说明任务执行时间接近或超过设定值，需要优化代码或放宽周期。
- 执行时间测量：在ST中可用
TIME()或F_GetSystemTime()记录任务起止时刻，计算实际耗时。
实用建议：初次配置时，可先把所有任务周期设得比理论值宽裕一些，运行稳定后再逐步收紧。每次只调整一个参数，观察负载和抖动变化，避免同时改周期、优先级和看门狗导致问题难以定位。
五、常见配置误区
实际工程中，以下问题最容易导致实时性异常：
- 把耗时逻辑放在高优先级任务中：例如在500 µs任务里做字符串处理或文件读写，会直接拖垮系统。
- 看门狗设得过小：等于周期或略大于周期，偶发的执行抖动就会触发停机。
- 所有任务绑在同一CPU核心：多核工控机上没有利用亲和性，导致核心间争抢。
- 忽略任务偏移：多个同周期任务同时触发，造成周期性CPU峰值。
- 用MAIN包揽一切：所有逻辑都放在一个任务里，无法区分快慢逻辑，后期难以优化。
正确的做法是：先按控制对象的响应要求划分任务，再为每个任务选择合适的POU语言和实现方式，最后通过负载、抖动和看门狗数据反复验证。程序组织与任务配置不是一次性的设置，而是随着程序复杂度增长需要持续调整的工程过程。