4. 任务与程序结构故障诊断
在 Studio 5000 Logix Designer 中，一个控制器项目并不是“一个程序从头跑到尾”，而是由任务（Task）、程序（Program）和例程（Routine）三层结构共同决定执行时机与执行顺序。任务负责调度，程序负责组织，例程负责实际逻辑。复杂项目一旦出现“某段逻辑偶尔不执行”“关键联锁响应变慢”“扫描时间突然飙升”等现象，问题往往不在梯形图本身，而在任务与程序结构层面。
三类任务的执行机制差异
Logix 控制器支持三种任务类型，它们的触发方式和优先级行为完全不同：
- 连续任务（Continuous Task）：项目中有且只能有一个，优先级最低，在没有周期任务和事件任务运行时循环执行。它适合放置对实时性要求不高的常规逻辑，如状态显示、数据记录、非关键联锁。
- 周期任务（Periodic Task）：按设定周期（如 10 ms、50 ms、100 ms）定时触发，优先级高于连续任务。周期越短，优先级越高。它适合运动控制、过程闭环、需要确定性扫描的场合。
- 事件任务（Event Task）：由特定事件触发，如输入模块的 Change of State、Consumed Tag 更新、运动轴事件等。它优先级最高，用于捕捉快速跳变信号或紧急响应。
三者的优先级关系是：事件任务 > 周期任务（周期越短优先级越高）> 连续任务。理解这条优先级链，是排查执行异常的基础。
执行异常的典型表现与根因
连续任务“饿死”是最常见的结构性问题。当周期任务设置过密（例如同时存在 2 ms、5 ms、10 ms 三个周期任务），或事件任务触发频率过高时，连续任务可能长时间得不到执行。现象是 HMI 上某些数据长时间不更新，但控制器没有报错。排查方法是打开 Task Monitor，观察连续任务的“实际扫描时间”是否远大于“理论可用时间”。
周期任务超时（Task Overrun）的根因通常有三类：一是任务内程序过多，单次扫描无法在周期内完成；二是任务内存在等待指令（如 MSG 指令等待响应、运动指令等待到位），阻塞了扫描；三是被更高优先级任务长时间抢占。判断依据是 Task Monitor 中的“Overrun Count”持续增加，同时“Max Scan Time”超过设定周期。
事件任务风暴往往由输入模块的 Change of State 配置不当引起。例如某个模拟量输入因噪声频繁跳变，每次跳变都触发事件任务，导致 CPU 反复进入高优先级中断。现象是系统整体响应变慢，但单个任务扫描时间看起来正常。解决方法是增加输入滤波、调整 COS 触发阈值，或改用周期任务轮询。
优先级反转的识别与处理
优先级反转是指：高优先级任务因为等待低优先级任务持有的资源（如某个标签、某个程序锁）而被阻塞，此时中等优先级任务反而先执行。在 Logix 中，虽然不像 RTOS 那样有显式互斥量，但以下场景仍会造成类似效果：
- 高优先级任务和低优先级任务同时读写同一个 Produced/Consumed Tag，且低优先级任务先获得更新权。
- 高优先级任务通过 MSG 指令读取低优先级任务所在控制器数据，MSG 排队等待。
- 多个任务共享同一个 AOI 实例，AOI 内部有状态保持逻辑，执行顺序影响结果。
处理原则是：高优先级任务只使用自己独占的标签和例程，不依赖低优先级任务的执行结果。如果必须共享数据，应使用 Produced/Consumed Tag 或 CIP 同步机制，并确保数据更新在任务执行前完成。
程序扫描超时排查流程
当控制器报出“Program Scan Timeout”或“Task Watchdog”时，可按以下顺序排查：
- 定位超时任务：在 Controller Organizer 中右键任务 → Task Properties → Monitor，查看哪个任务的 Max Scan Time 异常。
- 定位超时程序：在 Task Monitor 中展开该任务下的程序，观察各程序的扫描时间占比。通常某个程序的扫描时间会明显高于其他程序。
- 定位超时例程：进入该程序，使用 Routine 的“Scan Time”标签或添加临时 TON 计时器，逐段测量例程执行时间。
- 检查阻塞指令：重点检查 MSG、Motion、PID、AOI 调用。MSG 指令的 .EN 和 .DN 位如果长时间不切换，说明通信阻塞。
- 检查循环结构：梯形图中的 JMP/LBL 循环、ST 中的 WHILE/FOR 循环如果退出条件不满足，会导致单次扫描无限延长。
注意：任务看门狗超时后，控制器会进入 Major Fault 状态，所有输出进入故障安全状态。排查时应先确认安全，再在线查看故障记录（Controller Properties → Fault Log），不要直接清除故障后继续运行。
实用排查检查表
| 检查项 | 正常参考值 | 异常处理 |
|---|---|---|
| 连续任务扫描时间 | 稳定，波动 < 20% | 检查周期任务是否过密，减少高优先级任务数量 |
| 周期任务 Overrun Count | 0 或长期不增加 | 优化任务内逻辑，拆分程序，减少等待指令 |
| 事件任务触发频率 | 与工艺信号变化一致 | 增加输入滤波，调整 COS 阈值，改用周期轮询 |
| 任务优先级配置 | 关键联锁在短周期或事件任务 | 重新分配任务，确保高优先级任务不依赖低优先级数据 |
| MSG 指令 .EN/.DN | 在合理时间内切换 | 检查通信路径、目标控制器状态、CIP 连接数 |
任务与程序结构故障的诊断，核心是建立“优先级—执行时间—资源依赖”三者的关系模型。不要只盯着梯形图逻辑，先看任务调度是否合理，再看程序组织是否清晰，最后才深入到例程内部的指令级排查。这样能避免在错误的层级上浪费时间。