📚 课程目录第1章课程导入与架构总览

1. 课程导入与架构总览

在开始学习 Studio 5000 Logix Designer 的编程之前，很多初学者会直接打开软件、新建一个项目、拖入一条 XIC 指令，然后下载运行。这样做虽然能点亮一个输出点，但当程序规模扩大、需要多任务并行、需要按设备单元划分逻辑、需要控制扫描周期时，就会陷入混乱：为什么这段逻辑有时执行、有时不执行？为什么修改一个子程序会影响另一个设备的动作？为什么周期任务和连续任务的表现完全不同？这些问题的根源，几乎都指向同一个知识框架——控制器、任务、程序、例程的层级架构。

本节的目标不是立刻写出复杂逻辑，而是先建立一张“地图”。只有知道自己在哪一层、每一层负责什么、层与层之间如何调用与传递数据，后续学习标签、AOI、运动控制、安全逻辑时才能各归其位。本节需要掌握三件事：第一，说清 Controller、Task、Program、Routine 四层的定义与职责边界；第二，理解任务类型（连续、周期、事件）对执行时机的影响；第三，能够为一个典型设备画出合理的架构划分，并知道在软件中如何落地。

四层架构：从控制器到例程

Logix 控制器的项目结构是一个严格的树形层级，自上而下依次为：控制器（Controller）→ 任务（Task）→ 程序（Program）→ 例程（Routine）。每一层都有明确的归属关系，一个控制器下可以有多个任务，一个任务下可以有多个程序，一个程序下可以有多个例程，但反过来，一个例程只能属于一个程序，一个程序只能属于一个任务。

控制器是整个项目的根节点，它对应一台真实的物理 CPU，例如 CompactLogix 5380、ControlLogix 5580 等。控制器层定义了通信路径、CPU 型号、固件版本、控制器标签（Controller Tags）以及全局的故障处理策略。控制器标签在整个项目内全局可见，任何任务、程序、例程都可以访问，因此它适合存放跨设备共享的状态、报警汇总、配方索引等数据。

任务是控制器内的执行调度单元，它决定了“什么时候执行”和“以什么优先级执行”。Logix 支持三种任务类型：连续任务（Continuous）、周期任务（Periodic）和事件任务（Event）。连续任务在后台循环运行，没有固定周期，只要 CPU 有空闲时间就执行；周期任务按设定的时间间隔触发，例如每 10 ms 执行一次；事件任务由特定事件触发，例如某个标签变化、某个指令完成或消费标签到达。每个任务都有一个优先级，数值越小优先级越高，高优先级任务可以抢占低优先级任务。

程序是任务内的逻辑组织单元，它把完成某一设备或某一功能的相关例程、程序标签、故障例程打包在一起。程序标签（Program Tags）只在程序内部可见，不同程序之间默认不能直接访问，这种隔离机制正是模块化设计的关键。例如，可以把“1号灌装机”“2号灌装机”“公用报警”分别建成三个程序，各自维护自己的标签，互不干扰。

例程是实际编写梯形图、功能块图、结构化文本或顺序功能图的地方，是程序的最小执行单位。一个程序通常包含一个主例程（Main Routine）和若干子例程（Subroutine），主例程负责调用子例程，子例程负责具体逻辑。例程之间通过 JSR（跳转到子例程）、RET（返回）指令建立调用关系。

任务类型与执行时机

理解任务类型，是理解“程序什么时候跑”的关键。连续任务是默认任务，一个项目只能有一个连续任务，它没有周期设定，CPU 在完成所有周期任务和事件任务后，用剩余时间执行连续任务。周期任务按设定间隔触发，例如 10 ms、20 ms、100 ms，适合对时间确定性要求较高的控制回路。事件任务由事件触发，例如标签上升沿、指令完成、消费标签更新，适合处理突发报警或高速响应。

优先级决定了抢占关系。假设周期任务优先级为 5，连续任务优先级为 10，当周期任务触发时，它会打断连续任务的执行，执行完毕后再回到连续任务。如果两个任务同时触发，优先级数值小的先执行。这里有一个实践要点：不要把大量逻辑全部塞进高优先级周期任务，否则低优先级任务可能长期得不到执行，表现为“程序好像卡住了”。合理的做法是把关键控制放在周期任务，把非实时逻辑放在连续任务。

还需要注意任务看门狗（Watchdog）。每个任务都有一个看门狗时间，如果任务执行时间超过看门狗设定，控制器会报故障。例如周期任务设为 10 ms，看门狗设为 5 ms，若某次扫描逻辑过于复杂导致执行超过 5 ms，就会触发 Major Fault。因此在划分任务时，要估算逻辑量，必要时把大程序拆成多个周期任务或降低优先级。

程序与例程的划分原则

程序划分的核心思想是“按设备单元或功能单元隔离”。以一个灌装生产线为例，可以这样划分：连续任务下放“公用报警”“配方管理”“HMI 接口”三个程序；周期任务（10 ms）下放“1号灌装机”“2号灌装机”两个程序；事件任务下放“急停处理”程序。每个程序内部再建主例程和子例程，例如 1号灌装机程序包含 Main、Fill_Control、Alarm_Handler 三个例程。

这种划分带来三个好处：第一，程序标签隔离，1号灌装机的 Fill_Count 不会和 2号灌装机的 Fill_Count 冲突；第二，可以单独禁用某个程序进行调试，不影响其他设备；第三，可以单独设置某个程序的故障例程，实现故障分级处理。需要跨程序共享的数据，例如总产量、总报警，放在控制器标签中，或者使用 Produced/Consumed 标签在控制器之间交换。

划分程序时，先问三个问题：这段逻辑属于哪个设备？它需要多快的执行周期？它的标签是否需要被其他设备访问？答案会直接决定它应该放在哪个任务、哪个程序里。

在软件中落地：一个可参考的架构示例

下面给出一个典型项目的架构配置示例，参数为教学假设值，实际项目需根据 CPU 性能和工艺要求调整。

Controller: CompactLogix 5380 (5069-L320ER)
├── Task: Periodic_10ms (Type=Periodic, Period=10ms, Priority=5, Watchdog=5ms)
│   ├── Program: Filler_1
│   │   ├── Routine: Main (LAD)
│   │   ├── Routine: Fill_Control (LAD)
│   │   └── Routine: Alarm_Handler (LAD)
│   └── Program: Filler_2
│       ├── Routine: Main (LAD)
│       ├── Routine: Fill_Control (LAD)
│       └── Routine: Alarm_Handler (LAD)
├── Task: Continuous (Type=Continuous, Priority=10, Watchdog=500ms)
│   ├── Program: Common_Alarm
│   │   └── Routine: Main (ST)
│   ├── Program: Recipe_Manager
│   │   └── Routine: Main (ST)
│   └── Program: HMI_Interface
│       └── Routine: Main (LAD)
└── Task: Event_EStop (Type=Event, Trigger=Tag, Priority=1, Watchdog=2ms)
    └── Program: EStop_Handler
        └── Routine: Main (LAD)

在这个示例中，周期任务负责两个灌装机的实时控制，连续任务负责报警、配方和 HMI 交互，事件任务负责急停处理。急停任务优先级最高（1），周期任务次之（5），连续任务最低（10）。当急停触发时，它会立即抢占周期任务和连续任务，确保安全响应。周期任务的看门狗设为 5 ms，意味着单次扫描必须在这之内完成，否则报故障；连续任务看门狗设为 500 ms，相对宽松。

建立架构后，可以通过控制器属性中的“Task Monitor”查看各任务的实际扫描时间、执行次数和看门狗余量。如果发现周期任务的实际扫描时间接近看门狗设定，就需要优化逻辑或拆分任务。这是后续调试和性能优化的重要依据。

本节要点回顾

Logix 项目是四层树形结构：控制器 → 任务 → 程序 → 例程，归属关系严格单向。
控制器标签全局可见，程序标签局部隔离，跨程序共享数据需通过控制器标签或 Produced/Consumed 标签。
任务分连续、周期、事件三种，优先级数值越小越高，高优先级可抢占低优先级。
周期任务适合确定性控制，连续任务适合非实时逻辑，事件任务适合突发响应。
程序按设备或功能划分，例程按具体逻辑划分，主例程通过 JSR 调用子例程。
任务看门狗是执行时间的硬约束，架构划分时要估算逻辑量并留有余量。

掌握这张架构地图后，后续学习标签作用域、AOI 封装、运动控制任务配置、安全任务划分时，就能清楚地知道每个对象应该放在哪一层、为什么放在那一层。架构清晰，程序才能稳定、可维护、可扩展。