📚 课程目录第2章 iQ-F工程环境与版本对象识别

2. iQ-F工程环境与版本对象识别

在三菱iQ-F系列PLC的日常维护与改造中，真正需要纳入版本管理的，并不是一个单一的“程序文件”，而是GX Works3工程内部一整套相互关联的对象集合。如果只备份一个.gx3工程文件，看似完整，实际上在多人协作、设备替换或跨版本升级时，仍可能因为标签定义、参数设置或FB/FC接口的差异导致运行结果不一致。因此，本节的核心任务是：先看清GX Works3工程里到底有哪些对象，再判断哪些对象会随版本变化、哪些对象一旦变化就必须记录。

一、GX Works3工程的基本结构

GX Works3采用“工程（Project）—导航窗口树—各类对象”的层级组织方式。一个典型的iQ-F工程在导航窗口中通常包含以下主要节点：

PLC参数：包括系统参数、CPU参数、模块参数、内置以太网参数、内置RS-485参数等，决定CPU的硬件动作与通信行为。
程序：按执行类型分为初始程序、扫描程序、中断程序、待机程序；每个程序下又包含若干程序块（Program Block）。
FB/FUN：用户自定义功能块（FB）与函数（FUN），可被多个程序块调用。
标签：全局标签、局部标签、结构体定义、数组定义，是程序可读性的基础。
软元件注释：对X/Y/M/D等软元件的说明，影响程序可维护性。
设备/模块配置：CPU型号、扩展模块、智能功能模块的排列与型号信息。

这些对象并非彼此独立。例如，一个全局标签的类型一旦从WORD改为DWORD，所有引用它的程序块、FB接口都可能需要同步修改；一个FB的内部实现变化，会影响所有调用它的程序块。因此，版本管理必须覆盖“对象本身”和“对象之间的引用关系”。

二、哪些对象必须纳入版本管理

判断一个对象是否需要版本管理，可以用一个简单标准：它的变化是否会导致PLC的运行行为、通信行为或对外接口发生改变。按这个标准，iQ-F工程中的对象可以分为三类。

对象类别	典型内容	是否纳入版本管理	原因
PLC参数与模块配置	CPU型号、扩展模块排列、以太网IP、RS-485通信格式	必须	直接决定硬件动作与通信能否建立
程序块	初始/扫描/中断程序中的梯形图或ST代码	必须	直接决定控制逻辑
FB/FUN定义	FB接口变量、内部逻辑、FUN返回值	必须	接口变化会传播到所有调用处
标签与结构体	全局标签、局部标签、结构体成员、数组维度	必须	类型或地址变化会影响程序正确性
软元件注释	X/Y/M/D的说明文字	建议	不影响运行，但影响可维护性
工程显示设置	窗口布局、字体大小、交叉引用显示方式	不纳入	纯个人偏好，与设备行为无关

三、版本对象的识别方法

在实际操作中，可以借助GX Works3自带的功能快速识别“哪些对象发生了变化”。常用手段有三种：

交叉引用（Cross Reference）：对某个标签或软元件执行交叉引用，可以看到它在哪些程序块、哪些FB中被引用。如果该标签被修改，这些位置就是需要同步检查的范围。
程序块列表与属性：在导航窗口中查看每个程序块的“属性”，可以看到其创建时间、修改时间、执行类型。修改时间发生变化的程序块，就是本次版本变更的候选对象。
工程校验（Rebuild / Check）：执行工程校验后，GX Works3会报告标签未定义、FB接口不匹配、软元件重复使用等问题。校验通过与否，可以作为版本是否可发布的判断依据。

一个实用的习惯是：每次修改前先记录当前工程的“对象清单”——包括程序块名称、FB名称及版本、全局标签数量、CPU参数摘要。修改后再对照清单，就能快速定位本次变更涉及了哪些版本对象。

四、版本对象清单示例

下面给出一份可直接参考的iQ-F工程版本对象清单模板。字段按“对象类型、对象名称、当前版本标识、变更影响范围”组织，适用于改造前后的对照记录。

iQ-F 工程版本对象清单（示例）
工程名称：FX5U_Line1_Control
CPU型号：FX5U-32MT/ES
记录日期：2025-06-10

[参数类]
对象            当前值                影响范围
系统参数        运算周期10ms          整机扫描
以太网参数      IP 192.168.1.10       上位机通信
RS-485参数      9600/8/N/1            变频器通信

[程序块类]
程序块          执行类型    最近修改    调用FB
INIT           初始        2025-05-20  FB_PowerOn
MAIN           扫描        2025-06-08  FB_Conveyor, FB_Alarm
INT_01         中断        2025-04-11  无

[FB/FUN类]
FB名称          接口版本    内部逻辑版本  被调用位置
FB_Conveyor     V1.2        V1.2          MAIN
FB_Alarm        V1.0        V1.1          MAIN, INT_01

[标签类]
全局标签数量    48
结构体数量      3（ST_Motor, ST_Alarm, ST_Para）
最近变更        G_Start 由 WORD 改为 BOOL（2025-06-08）

这份清单的价值在于：当设备出现“程序下载后动作不对”的问题时，可以逐项比对清单中的参数、程序块和FB版本，快速判断是哪一个对象的版本与现场不一致。例如，若现场CPU的以太网IP与清单中记录的192.168.1.10不同，则上位机通信失败的原因就非常明确。

五、常见误区

误区一：只备份.gx3文件就算完成版本管理。工程文件虽然包含全部对象，但无法直观看出“本次改了什么”。没有对象清单和变更记录，回退和比对仍然困难。
误区二：只记录程序块，忽略参数和标签。参数变化同样会改变设备行为，标签类型变化会导致编译通过但运行异常。
误区三：把FB当成“内部细节”不记录版本。FB接口一旦变化，所有调用它的程序块都需要重新确认，属于必须记录的版本对象。

综上，iQ-F工程的版本管理对象应以“参数、程序块、FB/FUN、标签”四类为核心，以软元件注释为辅助，以工程显示设置为排除项。识别方法上，交叉引用用于查影响范围，程序块属性用于查修改时间，工程校验用于查一致性。只有把对象识别清楚，后续的版本号编制、变更记录和回退策略才有可靠的落脚点。