2. 罗克韦尔PLC与Studio 5000基础

在开始学习AOI（Add-On Instruction，附加指令）封装之前，必须先建立对罗克韦尔自动化平台的整体认知。AOI本质上是一种封装了逻辑与数据的“指令容器”，它运行于ControlLogix/CompactLogix控制器之中，开发于Studio 5000环境之内。如果对硬件平台、软件工程结构、控制器扫描模型缺乏清晰理解，后续的AOI设计将无从落地。本节将围绕四个核心维度展开：硬件平台选型、Studio 5000软件界面与工程结构、控制器组织模型（任务/程序/例程/标签）、以及AOI在控制器组织中的定位。

2.1 硬件平台：ControlLogix与CompactLogix选型逻辑

罗克韦尔自动化当前主流的PAC（可编程自动化控制器）平台是ControlLogix系列与CompactLogix系列。两者共用Studio 5000编程环境，但在硬件形态、扩展能力、性能等级和应用场景上存在显著差异。理解这些差异是AOI设计的前提——因为AOI的扫描时间、内存占用、通信带宽需求必须与目标硬件匹配。

核心原理：硬件架构与性能边界

ControlLogix 5580控制器采用模块化机架式设计，支持最多多机架扩展，CPU模块独立于电源、通信模块和I/O模块。其背板总线（ControlBus）提供高带宽数据交换，适合大型生产线、过程控制或需要大量运动控制轴的应用。CompactLogix 5380则采用紧凑型一体化设计，CPU、电源、通信和I/O集成在较小体积内，适合分布式控制或设备级控制。

从AOI封装的角度看，硬件平台决定了以下关键约束：

• 内存容量：ControlLogix 5580提供2MB至20MB的用户内存，而CompactLogix 5380通常为1MB至3MB。AOI实例数量越多，占用的标签内存越大。
• 任务执行周期：ControlLogix支持最小0.5ms周期任务，CompactLogix通常为1ms。AOI内部逻辑复杂度直接影响任务实际执行时间。
• 通信能力：ControlLogix支持EtherNet/IP、ControlNet、DeviceNet等多种网络，CompactLogix以EtherNet/IP为主。AOI若需与远程I/O或第三方设备通信，必须考虑网络带宽。

判断方法：如何选择硬件平台

1. 统计I/O点数：少于256点且控制逻辑相对简单，优先考虑CompactLogix；超过512点或需要高速运动控制，选择ControlLogix。
2. 评估扫描周期要求：若需要低于1ms的确定性控制，必须使用ControlLogix 5580并配置协处理器模块。
3. 考虑扩展需求：未来3年内可能增加I/O机架或通信模块，选择ControlLogix的模块化架构更灵活。
4. 计算AOI实例内存：每个AOI实例约占用100-500字节标签内存（取决于参数数量），结合预计实例数评估总内存需求。

2.2 Studio 5000软件界面与工程结构

Studio 5000是罗克韦尔统一的编程与组态环境，其界面设计围绕“控制器组织”树形结构展开。理解这个树形结构是高效开发AOI的基础，因为AOI的创建、编辑、测试和部署都嵌入在这个结构之中。

核心原理：工程结构的层次化组织

Studio 5000的工程浏览器（Controller Organizer）采用树形视图，从上到下依次为：控制器（Controller）、任务（Tasks）、程序（Programs）、例程（Routines）、标签（Tags）、I/O配置（I/O Configuration）以及AOI（Add-On Instructions）。这种层次结构反映了PLC扫描执行的逻辑顺序：控制器配置 → 任务调度 → 程序调用 → 例程执行 → 指令（包括AOI）运行。

在工程结构中，AOI位于“Add-On Instructions”文件夹下，与Tasks、Programs等平级。每个AOI定义包含：参数定义（Parameters）、局部标签（Local Tags）、逻辑例程（Logic Routine）和文档信息。当AOI被创建后，它就像内置指令一样，可以被拖拽到任何例程的梯形图或结构化文本中。

操作流程：创建第一个AOI工程

1. 新建工程：打开Studio 5000，选择“New Project”，输入工程名称，选择控制器型号（如1756-L83E）。
2. 配置I/O：在I/O Configuration中右键添加本地机架、电源、通信模块和数字量/模拟量模块。
3. 创建AOI：右键点击“Add-On Instructions”，选择“New Add-On Instruction”，定义名称（如AOI_MotorControl）、版本号和描述。
4. 定义参数：在Parameters标签页添加输入参数（如StartCmd、StopCmd）、输出参数（如Running、Fault）和输入输出参数（如SpeedRef）。
5. 编写逻辑：在Logic Routine中编写AOI内部逻辑，可以使用梯形图或结构化文本。
6. 测试调用：在MainRoutine中拖入该AOI，关联实际标签，下载到仿真器或实际控制器进行验证。

2.3 控制器组织：任务、程序、例程与标签

控制器组织是Studio 5000的核心逻辑框架。AOI虽然独立定义，但最终必须被某个例程调用才能执行。因此，理解任务调度、程序调用和例程执行的关系，是AOI正确部署的前提。

核心原理：扫描模型与调度机制

ControlLogix/CompactLogix采用“任务-程序-例程”三级调度模型。任务（Task）定义执行周期和优先级，程序（Program）是任务下的逻辑分组，例程（Routine）是实际代码的载体。控制器按任务优先级调度，每个任务内按程序顺序执行，每个程序内按例程调用顺序执行。

AOI在例程中被调用时，相当于执行一段封装好的子程序。但与传统子程序不同，AOI拥有独立的参数接口和内部标签存储，每次调用都会创建独立的实例数据空间。这意味着同一个AOI可以被多个例程调用，且各实例之间互不干扰。

判断方法：AOI在控制器组织中的正确位置

• 任务选择：如果AOI需要高速响应（如伺服控制），应放置在周期任务（Periodic Task）中，并设置合适的周期时间；如果AOI是普通逻辑（如阀门控制），可放置在连续任务（Continuous Task）中。
• 程序划分：建议按功能域划分程序（如“ConveyorControl”、“ProcessControl”），每个程序内放置相关的AOI调用。
• 例程组织：每个程序至少包含MainRoutine和FaultRoutine。AOI调用应放在MainRoutine中，故障处理逻辑可放在FaultRoutine中。
• 标签作用域：AOI实例的输入/输出参数必须关联到控制器作用域或程序作用域的标签。控制器作用域标签全局可见，程序作用域标签仅限本程序内使用。

2.4 实战案例：基于AOI的电机控制单元封装

以下通过一个完整的电机控制案例，展示AOI在控制器组织中的实际应用。该案例包含硬件配置、AOI设计、任务分配和调试过程。

案例背景与目标

某包装机械厂需要控制4台交流电机，每台电机需要实现启动、停止、过载保护、运行状态反馈和故障复位功能。传统做法是每台电机编写一段梯形图逻辑，导致程序冗余且维护困难。目标是通过AOI封装，实现“一次编写、四次复用”，并确保各电机独立运行。

关键输入数据与约束

• 控制器：CompactLogix 5380（1769-L33ERM），内存2MB
• I/O配置：本地数字量输入模块（1769-IQ32）和输出模块（1769-OB32）
• 电机参数：4台电机，额定电流分别为2.5A、3.2A、4.0A、5.5A
• 控制要求：启动信号保持2秒后输出运行接触器；过载信号触发后立即停止并锁存故障；复位信号清除故障锁存

AOI设计与实现

// AOI名称：AOI_MotorControl
// 输入参数：
//   StartCmd : BOOL  // 启动命令
//   StopCmd  : BOOL  // 停止命令
//   Overload : BOOL  // 过载信号
//   ResetCmd : BOOL  // 故障复位
// 输出参数：
//   Running  : BOOL  // 运行状态
//   Fault    : BOOL  // 故障状态
// 输入输出参数：
//   MotorRun : BOOL  // 接触器输出

// 内部逻辑（结构化文本）：
IF ResetCmd THEN
    Fault := FALSE;
END_IF;

IF NOT Fault THEN
    IF StartCmd AND NOT StopCmd THEN
        MotorRun := TRUE;
        Running := TRUE;
    ELSIF StopCmd THEN
        MotorRun := FALSE;
        Running := FALSE;
    END_IF;
END_IF;

IF Overload THEN
    MotorRun := FALSE;
    Running := FALSE;
    Fault := TRUE;
END_IF;

控制器组织配置

1. 任务配置：创建Periodic Task，周期10ms，优先级10，用于执行电机控制逻辑。
2. 程序划分：创建“MotorControl”程序，归属于上述周期任务。
3. 例程调用：在MotorControl程序的MainRoutine中，拖入4个AOI_MotorControl实例，分别命名为Motor1至Motor4。
4. 标签关联：为每台电机创建输入/输出标签（如Motor1_StartCmd、Motor1_Overload等），并连接到实际I/O地址。

结果对比与复盘

采用AOI后，程序代码量减少约70%，调试时间缩短50%。4台电机的控制逻辑完全一致，仅参数不同。后续若增加第5台电机，只需复制一个AOI实例并关联新标签即可。复盘发现，AOI内部逻辑中未考虑启动超时保护，后续版本增加了“启动超时报警”功能，通过修改AOI定义即可自动更新所有实例。

2.5 常见误区与总结复盘

在AOI开发与部署过程中，以下误区需要特别警惕：

• 误区一：将AOI当作全局变量存储区。AOI的局部标签仅对实例内部可见，不能直接通过外部标签访问。如果需要跨AOI共享数据，应通过输入/输出参数显式传递。
• 误区二：忽略任务周期对AOI执行时间的影响。如果AOI内部逻辑复杂（如大量浮点运算），在高速周期任务中可能导致任务超时。建议在AOI内使用计时器或计数器时，考虑任务周期的影响。
• 误区三：在AOI中直接使用I/O地址。AOI应设计为与具体I/O地址解耦，通过参数传递I/O标签。这样AOI才能在不同硬件配置中复用。
• 误区四：不进行版本管理。AOI定义修改后，所有调用实例会自动更新。如果修改了参数接口，可能导致原有调用点出现连接错误。建议在修改AOI前导出备份，并记录变更日志。