4. GX Works3工程结构
在GX Works3中，一个工程并不是“一个程序文件”那么简单，而是由项目树统一承载、由程序组织单元（POU）分层组织、由任务决定执行顺序、由程序块/功能块/函数承担不同复用职责的完整体系。理解这套结构，是后续结构化编程、调试与多人协作的基础。
一、核心原理：从“工程”到“可执行程序”的层级
GX Works3的工程结构可以按“容器—组织—执行—复用”四个维度理解：
- 项目树：工程的最外层容器，管理CPU参数、模块配置、程序、FB库、全局标签、软元件注释等所有资源。
- 程序组织单元（POU）：工程中可独立编辑、编译和调用的逻辑单元，包括程序块、功能块（FB）、函数（FUN）。
- 任务：决定POU在PLC运行时的执行时机与顺序，如初始任务、扫描任务、固定周期任务、事件任务。
- 程序块：直接挂到任务下、按扫描或事件执行的“主程序”单元，通常对应一个控制功能或设备单元。
- 功能块与函数：被程序块或其他FB调用的复用单元，FB有内部状态，函数无内部状态。
一句话记忆：项目树是“仓库”，POU是“零件”，任务是“生产节拍”，程序块是“工位”，FB/FUN是“标准件”。
二、项目树：工程资源的统一入口
项目树按“导航窗格”方式呈现，典型节点包括：
- CPU参数：PLC型号、运算周期、软元件设置等。
- 模块配置：主基板、扩展模块、智能功能模块的插槽与参数。
- 程序：按任务分组的程序块列表，可新建、删除、设置执行类型。
- FB/FUN库：已定义的功能块与函数，可被多个程序块调用。
- 全局标签/软元件：跨POU共享的变量与注释。
项目树的价值在于“一处修改、全局生效”。例如修改某个FB的接口，所有调用它的程序块都会在编译时被检查，避免遗漏。
三、任务、程序块、FB与函数的关系
任务位于程序块之上，是执行调度的入口。一个任务可以挂多个程序块，程序块内部再调用FB或函数。其关系可概括为：
- 任务 → 程序块：决定“什么时候执行”。
- 程序块 → FB/FUN：决定“执行什么逻辑”。
- FB：带背景数据（实例DB），有记忆，适合电机、阀门、PID等设备控制。
- 函数：无背景数据，相同输入必得相同输出，适合换算、限幅、报警判断等纯计算。
下面用一张结构关系图直观展示项目树、任务、程序块、FB与函数之间的层级与调用关系：
四、案例：一条输送线的程序组织
假设一条输送线包含“启动停止、电机控制、速度换算、报警判断”四个功能，可按如下方式组织：
任务：扫描任务（Scan）
└─ 程序块：Main_Conveyor
├─ 调用 FB：Motor_Ctrl（实例 DB_Motor1）
├─ 调用 FB：Motor_Ctrl（实例 DB_Motor2）
├─ 调用 FUN：Speed_Scale（输入Hz，输出m/min）
└─ 调用 FUN：Alarm_Check（输入温度、电流，输出报警位）其中Motor_Ctrl是FB，因为它需要记住“运行/停止/故障”状态；Speed_Scale和Alarm_Check是函数，因为只做纯计算，不需要记忆。这样组织后，新增一台电机只需再实例化一次FB，不必复制逻辑。
五、常见误区与复盘
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 把所有逻辑写在一个程序块里 | 难以复用、调试定位慢 | 按设备或功能拆分为多个程序块 |
| 用函数保存设备状态 | 状态丢失、输出异常 | 需要记忆的逻辑改用FB |
| 多个程序块共用一个FB实例 | 状态互相干扰 | 每个设备使用独立实例DB |
| 任务与程序块执行顺序随意 | 扫描周期内逻辑竞争 | 按“输入→运算→输出”顺序分配任务 |
调试时可在项目树中逐级展开任务与程序块，结合“程序监视”观察FB实例的当前值，快速判断是逻辑错误还是状态未保持。
修改FB接口后必须重新编译全部调用它的程序块，否则可能出现参数不匹配或旧实例数据残留。
掌握项目树、POU、任务、程序块、FB与函数的关系后，就能在GX Works3中把复杂控制拆成可管理、可复用、可调试的单元，为后续结构化编程打下稳定基础。