2. CODESYS开发环境基础

CODESYS 的自动化构建与测试能力,建立在对开发环境本身的准确理解之上。如果只把 CODESYS 当作一个“写梯形图的编辑器”,后续的脚本编译、CI 流水线、单元测试注入都会遇到障碍。本节从安装配置、工程结构、设备树、编程基础与常用组件五个层面,建立可被自动化工具识别和操作的工程认知。

一、安装配置:版本、组件与路径

CODESYS 采用“主开发环境 + 插件组件”的安装模式。安装时最关键的三项决策是:版本选择、组件勾选、安装路径。版本方面,CODESYS V3.5 SP 系列是当前主流,SP 号越高,对 Git、命令行编译、测试框架的支持越完善。组件方面,至少需要勾选 CODESYS Development System、目标设备描述文件(Device Description)、以及后续要用的编译器插件。

安装路径建议保持默认,避免中文和空格,因为后续脚本调用 CODESYS.exe 或 CODESYSControl 时,路径中的空格会带来转义问题。安装完成后,可通过命令行验证环境是否可用:

CODESYS.exe --profile="CODESYS V3.5 SP19" --noUI --runscript="build.py"

其中 --profile 指定配置文件,--noUI 表示无界面运行,--runscript 指向自动化脚本。这三者组合,正是后续 CI 构建的基础调用形式。

建议在安装后立即记录版本号、SP 号、已安装组件清单,并纳入版本管理。自动化构建对版本差异非常敏感,同一工程在不同 SP 下可能编译结果不同。

二、工程结构:从 .project 到编译产物

CODESYS 工程以 .project 文件为核心,内部采用类似 XML 的树形结构存储。一个典型工程包含:设备对象、应用对象、POU(程序组织单元)、任务配置、库引用、可视化对象等。理解工程结构的意义在于:自动化脚本需要按路径定位对象,例如 Device.Application.PLC_PRG。

工程编译后会产生 .compileinfo、.app、.bootproject 等文件。其中 .app 是下载到控制器的应用文件,.bootproject 是掉电保持的启动工程。自动化测试通常关注编译日志和 .app 的生成结果。

三、设备树:硬件与逻辑的映射

设备树是 CODESYS 工程中最具辨识度的结构。它把真实控制器、总线、IO 模块、轴、网关等硬件对象,以树形层级映射到工程中。根节点通常是 PLC 设备,其下挂载应用、任务、IO 映射、总线主站、从站模块等。

设备树不仅是配置界面,也是自动化脚本的“寻址空间”。例如,要批量修改某个 IO 模块的参数,脚本需要沿 Device.EtherCAT_Master.Slave_1 这样的路径访问。设备树中的每个节点都有类型、名称、参数和连接关系,这些信息在工程文件中以结构化形式保存。

CODESYS 工程结构与设备树映射 工程文件结构 (.project) Device (PLC 设备) Application (应用) PLC_PRG (主程序 POU) Task Configuration Library Manager Visualization 编译产物: .app / .bootproject 设备树 (Device Tree) PLC 控制器 (根节点) EtherCAT 主站 从站 1: 数字量输入模块 从站 2: 数字量输出模块 从站 3: 模拟量输入模块 IO 映射 (输入/输出变量) 轴 / 运动控制对象 映射

四、PLC 编程基础:IEC 61131-3 与 POU

CODESYS 遵循 IEC 61131-3 标准,支持五种编程语言:梯形图(LD)、功能块图(FBD)、顺序功能图(SFC)、结构化文本(ST)、指令表(IL)。其中 ST 语言最适合自动化测试,因为它是文本形式,便于脚本生成、差异比对和静态分析。

POU 是程序组织单元,分为程序(PRG)、功能块(FB)、函数(FUN)三类。程序是任务调度的基本单位,功能块可保持状态,函数无状态。自动化测试通常针对功能块和函数编写测试用例,因为它们输入输出明确、易于隔离。

FUNCTION_BLOCK FB_MotorControl
VAR_INPUT
    Start : BOOL;
    Stop  : BOOL;
END_VAR
VAR_OUTPUT
    Running : BOOL;
END_VAR
VAR
    State : INT;
END_VAR
// 状态机逻辑
IF Start AND NOT Stop THEN
    Running := TRUE;
ELSIF Stop THEN
    Running := FALSE;
END_IF
END_FUNCTION_BLOCK

任务配置决定 POU 的执行周期和优先级。自动化构建时,任务配置的变更会直接影响实时行为,因此测试用例需要覆盖不同任务周期下的逻辑正确性。

五、常用组件与自动化关注点

CODESYS 工程中常用的组件包括:库管理器、可视化、报警配置、配方管理、跟踪(Trace)、PLCopen 运动控制库等。这些组件在自动化构建中各有对应的脚本接口和测试关注点。

组件 作用 自动化关注点
库管理器 管理标准库与自定义库引用 版本锁定、依赖检查、编译前库解析
任务配置 定义任务周期、优先级、看门狗 周期参数校验、任务与 POU 绑定关系
可视化 HMI 画面与变量绑定 变量引用完整性、画面元素批量检查
报警配置 报警定义、分组、确认机制 报警 ID 唯一性、文本完整性
Trace 运行时变量采样与记录 采样配置导出、测试数据采集
PLCopen 运动库 轴控制功能块 轴参数配置、运动指令测试

六、常见误区与复盘

误区一:忽略设备树路径的稳定性。设备树节点名称在手动重命名后,脚本中的硬编码路径会失效。建议在自动化脚本中使用对象 GUID 或统一命名规范。

误区二:把编译成功等同于逻辑正确。CODESYS 编译只检查语法和类型,不验证业务逻辑。自动化测试必须补充单元测试和集成测试。

误区三:库版本不锁定。不同机器安装的库版本不一致,会导致“本地能编译、CI 编译失败”。应在工程中显式记录库版本,并在 CI 环境中预装相同版本。

复盘来看,CODESYS 开发环境基础的核心不是“会点按钮”,而是理解工程对象之间的层级关系、路径寻址方式和版本依赖。只有把这些结构化的信息纳入自动化脚本的管理范围,后续的自动构建、自动测试和持续集成才有稳定的基础。