2. iQ-R程序资产盘点

在iQ-R系统中，程序版本治理的第一个动作不是“建库”，也不是“上工具”，而是把需要被治理的对象找全、认准、定名。很多现场在版本失控时才发现：改过的程序文件有备份，但CPU内置的FB库没有备份；参数文件被单独拷走，却不知道它对应哪个程序版本；标签数据库被多人编辑过，却没有任何版本记录。这些问题的根源，都是资产盘点没有做完整。

iQ-R的程序资产并不只是“程序文件”四个字。它至少分布在五个层面：CPU模块本体、程序文件（含主程序与子程序）、FB/FC库、参数文件、标签数据库。它们之间不是并列关系，而是有明确的依赖与承载关系。理解这个关系，是建立版本治理对象清单的前提。

一、CPU模块：版本治理的根对象

CPU模块是iQ-R系统的硬件承载层，也是版本治理的根对象。盘点时不能只记“R08CPU”这个型号，还要记录序列号、固件版本、内置ROM/RAM容量。固件版本尤其关键：不同固件版本对指令集、FB库兼容性、标签数据库格式的支持程度不同。例如，R08CPU固件从某个版本开始才支持某些安全FB，如果程序里用了这些FB，而目标CPU固件版本较低，下载后就会报错。

实际盘点时，建议在GX Works3的“系统监视器”或“CPU诊断”中读取以下信息：CPU型号、序列号、固件版本、程序容量使用率、软元件使用量。这些数据应记录到版本治理对象清单的“CPU模块”行中。如果现场有多台设备使用同型号CPU但固件版本不同，必须分别登记，不能合并。

二、程序文件：执行逻辑的版本载体

iQ-R的程序文件包括主程序、子程序、中断程序，以及按任务类型划分的扫描周期任务和固定周期任务。盘点时，不能只记录“MAIN.prg”这个文件名，还要记录每个程序文件的版本号、最后修改时间、修改人、程序步数、使用的软元件范围。

一个常见的误区是：只备份了主程序，忽略了子程序和中断程序。实际上，子程序往往承载了设备的核心工艺逻辑，中断程序则决定了高速响应的可靠性。如果子程序被单独修改而没有记录，主程序即使没变，整体行为也可能已经改变。因此，程序文件的盘点必须做到“逐个文件登记，逐个版本确认”。

在GX Works3中，可以通过“程序文件属性”查看每个文件的创建时间、修改时间、程序步数、注释数量。建议将这些信息导出为CSV，作为版本治理对象清单的原始数据。对于使用多个程序文件的工程，还应记录程序文件之间的调用关系，避免出现“改了子程序但主程序调用条件没改”的版本错配。

三、FB/FC库：可复用逻辑的版本陷阱

FB（功能块）和FC（功能）是iQ-R程序复用的核心。它们可以来自三菱标准库，也可以是工程师自定义的库。版本治理中最容易出问题的，恰恰是自定义FB/FC库。原因有三：第一，FB/FC库通常被多个程序文件调用，改一处影响多处；第二，FB/FC库的版本号往往没有写入程序注释，时间一长就说不清用的是哪个版本；第三，FB/FC库可能被单独导出为文件，脱离原工程后无法追溯来源。

盘点FB/FC库时，应记录：库名称、库类型（标准/自定义）、版本号、作者、创建日期、最后修改日期、被哪些程序文件调用、接口变量列表。对于自定义FB，建议在FB的头部注释中强制写入版本号和修改记录，例如：

// FB名称: Motor_Start
// 版本: V1.3
// 作者: 张工
// 日期: 2025-06-15
// 变更: 增加过载保护延时参数
// 调用者: MAIN.prg, SUB_02.prg

这样即使FB被单独导出，也能通过注释追溯版本。盘点时，如果发现某个FB没有版本注释，应将其标记为“版本不明”，并优先安排补充注释和版本确认。

四、参数文件与标签数据库：配置支撑层

参数文件包括CPU参数、模块参数、网络参数。它们通常以XML或二进制形式存储在工程中，修改后如果不记录，会导致“程序一样但行为不一样”的诡异现象。例如，CPU参数中的扫描时间设置、中断设置、软元件分配，都会直接影响程序执行结果。盘点时应记录参数文件的名称、对应模块、最后修改时间、修改内容摘要。

标签数据库包括全局标签和局部标签，通常以XML文件形式存在。标签数据库的版本问题在于：它可能被多人同时编辑，且标签名称的变更会直接影响程序的可读性和可维护性。盘点时应记录标签数据库的文件名、标签数量、结构体数量、最后修改时间、修改人。如果标签数据库与程序文件版本不一致，编译时可能报“标签未定义”或“标签类型不匹配”。

五、建立版本治理对象清单

完成上述五类资产的识别后，需要将它们汇总为一份版本治理对象清单。清单的核心字段包括：资产名称、资产类型、存储位置、当前版本、责任人、关联资产、变更记录。其中“关联资产”字段用于记录依赖关系，例如某个程序文件调用了哪些FB/FC库，某个参数文件对应哪个CPU模块。

以下是一个简化的清单示例，供实际盘点时参考：

资产盘点的最终目的，是让每一个可能影响程序行为的对象都有名、有版本、有责任人、有依赖记录。只有清单完整，后续的版本比对、变更审批、回滚恢复才有可靠的基础。如果盘点时发现某个资产“找不到责任人”或“版本不明”，应将其列为高风险项，优先处理。