3. 控制器级故障诊断
当一台 ControlLogix 或 CompactLogix 控制器出现异常时，最先能反映问题位置的往往不是编程软件，而是控制器面板上的状态指示灯。Studio 5000 的在线诊断能力再强，也必须建立在控制器本身仍能维持基本运行的前提上。因此，控制器级故障诊断的第一步，是学会从硬件指示灯读出“控制器当前处于什么状态”，再结合故障代码、任务属性和内存占用，判断问题属于电源、程序、通信、任务配置还是资源耗尽。
一、CPU 状态指示灯的含义与判读
以常见的 1756-L8x 系列控制器为例，面板上通常有 RUN、OK、FORCE、I/O 等指示灯。RUN 灯常绿表示控制器处于运行模式并正在执行任务；RUN 灯熄灭表示处于编程模式或已停止执行。OK 灯常绿表示控制器健康；OK 灯红色闪烁通常表示存在可恢复故障，例如电池电量低或非致命故障；OK 灯红色常亮则往往表示不可恢复的硬件或固件故障。FORCE 灯黄色常亮表示有强制 I/O 被启用，这在排障时极易被忽略，却可能直接导致现场动作异常。
判读时应遵循“先看 OK，再看 RUN，最后看 FORCE 与 I/O”的顺序。若 OK 灯异常，优先怀疑控制器本体；若 OK 正常而 RUN 熄灭，问题多半在程序执行条件或模式切换；若两者都正常但设备不动作，则应转向 I/O 与通信层。指示灯只能给出方向，不能给出具体原因，因此必须结合故障代码进一步定位。
二、故障代码的读取与分类
在 Studio 5000 中，控制器故障分为 Major Fault（重大故障）和 Minor Fault（轻微故障）。重大故障会强制控制器进入故障状态并停止执行任务，轻微故障则允许继续运行但会在日志中记录。读取故障代码的常用路径是：在 Controller Organizer 中右键控制器 → Properties → Major Faults 选项卡，或通过 Controller Properties 的 Fault 标签查看当前故障代码与描述。
故障代码通常以“类型 + 代码”的形式呈现。例如类型 01 多与看门狗超时相关，类型 02 涉及电源或电池，类型 03 指向 I/O 模块，类型 04 与程序或任务配置有关，类型 05 表示内存不足，类型 06 涉及通信或固件。实际项目中，一个故障往往由多个代码叠加，因此应优先记录全部代码，再按“先硬件后软件、先致命后轻微”的顺序逐项排除。
三、看门狗超时的识别与处理
看门狗超时是控制器级故障中最常见的一类。其本质是某个任务在规定的扫描周期内没有完成执行，控制器判定该任务失控并触发重大故障。典型原因包括：程序中存在死循环或长耗时循环、任务优先级配置不当导致高优先级任务长期占用 CPU、通信指令在无响应时阻塞、以及大量浮点运算或字符串处理集中在同一扫描周期内。
识别看门狗超时的关键参数是任务属性中的 Watchdog 时间。以示例参数为例，某连续任务扫描周期设为 20 ms，看门狗时间设为 100 ms，若实际执行时间持续超过 100 ms，就会触发类型 01 故障。处理时不应简单调大看门狗时间，而应先定位耗时任务。可在 Task Properties 中查看任务的实际执行时间与最大执行时间，结合程序中的 FOR、WHILE 循环和 AOI 调用进行排查。
示例：任务属性中的关键参数
Task: MainTask
Type: Continuous
Period: 20 ms
Watchdog: 100 ms
Priority: 10
Actual Scan Time: 18 ms（正常）
Max Scan Time: 132 ms（异常，已超过看门狗）若确认是某段逻辑导致超时，可将其拆分到不同任务中，或降低该任务的优先级，避免阻塞关键控制逻辑。对于通信指令，应设置合理的超时和重试次数，避免因等待响应而拖垮整个任务。
四、内存与任务冲突的识别
内存问题通常表现为类型 05 故障，或在下载程序时提示内存不足。ControlLogix 控制器的内存分为程序内存、标签内存和通信缓冲区。当标签数量过多、数组过大或字符串标签频繁使用时，内存占用会显著上升。可在 Controller Properties → Memory 选项卡中查看已用内存与剩余内存。若剩余内存低于总内存的 10%，应引起警惕。
任务冲突则更多体现在任务优先级与执行周期上。例如两个任务被配置为相同优先级且周期相近，可能导致 CPU 调度抖动；或者一个高优先级任务频繁触发，使低优先级任务长期得不到执行。识别方法是观察各任务的 Actual Scan Time 是否稳定，以及是否存在任务未按预期周期执行的情况。处理方式包括：合理划分任务优先级、将非关键逻辑移入低优先级任务、避免在多个任务中同时操作同一组标签。
五、从指示灯到故障代码的完整排查路径
综合来看，控制器级故障诊断应形成一条清晰的路径：先观察面板指示灯确定故障层级，再通过 Studio 5000 读取故障代码，接着结合任务属性、内存占用和程序逻辑定位根因，最后在记录完整信息后执行修复并验证。修复后应重新下载或切换运行模式，观察 OK 灯与 RUN 灯是否恢复正常，并确认任务扫描时间回到合理范围。只有形成“观察—读取—定位—修复—验证”的闭环，才能避免同类故障反复出现。