企业官网建设流程全解析

1. 为什么工业现场总在“反复改配方”，而InoProShop结构体是破局关键

我在汇川PLC项目现场干了八年，从H2U到AM600，再到最新的H5U系列，踩过最多的坑不是通讯中断、不是IO点烧毁，而是——配方管理。客户一句“这个参数明天要调”，工程师就得连夜改程序、下装、测试、签字确认；产线换型时，三套设备的配方参数要手动抄写、核对、录入，出错一次，整批产品报废。去年在东莞一家食品包装厂，他们用Excel表格存着27个产品配方，每次换型靠人工比对PLC寄存器地址，结果把“灌装温度”和“封口压力”的数值填反了，当天损失二十多万。后来我翻遍InoProShop帮助文档，在“数据类型”章节里看到结构体（STRUCT）这个词，像被电击了一样——原来汇川早把工业配方的底层能力藏在这里，只是没人真正用透。

所谓“工业配方”，本质就是一组有逻辑关联、可批量存储/调用/修改的工艺参数集合。比如一条饮料灌装线，每个产品对应：灌装量（REAL）、灌装速度（DINT）、瓶盖扭矩（WORD）、杀菌温度（REAL）、冷却时间（TIME）。如果用传统方式——30个字的DINT寄存器+20个字的REAL寄存器+10个字的BOOL寄存器——光是记住哪个地址对应哪个参数，就足够让新工程师头皮发麻。更别说版本管理、参数校验、权限控制这些刚需。而InoProShop里的结构体，就是把这堆散落的参数，打包成一个有名字、有边界、有类型的“数据盒子”。它不是语法糖，是汇川为工业场景量身定制的数据组织范式。你定义一次ST_PackRecipe，就能在全局DB块、FB功能块、甚至HMI变量表里复用；你给它加个bValid: BOOL字段，就能实现一键启用/禁用配方；你再塞进dtModified: DT时间戳，审计追溯就自动有了。这不是炫技，是把“改参数”这件事，从手工操作变成可编程、可验证、可管控的工程行为。关键词“汇川”“PLC”“InoProShop”“结构体”“工业配方”——它们串起来，指向的是一条从“能用”到“好用”再到“管用”的真实路径。适合谁？不是只写梯形图的初级工程师，而是要交付稳定产线、要应对客户Audit、要支撑未来柔性制造的PLC系统工程师。这篇文章不讲概念，只拆解怎么用结构体把配方功能真正落地——从定义、存储、调用到防错，每一步都带实测截图和可复制代码。

2. 结构体不是“高级语法”，而是工业数据建模的底层思维

很多人一看到“InoProShop结构体”，下意识觉得是C语言或C++的移植，想用typedef struct那一套去套。错了。汇川的结构体设计，根本出发点不是兼容C，而是解决PLC在工业现场的三个硬约束：内存连续性、地址可预测性、调试可视化。我拿最典型的ST_MotorConfig结构体来拆解，这是我在佛山一家电机厂做伺服参数配置时的真实案例：

TYPE ST_MotorConfig : STRUCT bEnable: BOOL; // 启用标志，TRUE=生效 nRatedPower: DINT; // 额定功率（W），范围0~50000 rRatedSpeed: REAL; // 额定转速（rpm），范围0.0~3000.0 rTorqueLimit: REAL; // 扭矩限制（N·m），精度0.01 dtCalibrationTime: DT; // 最后标定时间，系统自动生成 sModelNo: STRING[16]; // 型号字符串，如"MS1H4-0400" END_STRUCT END_TYPE

这段代码背后，藏着汇川工程师对硬件的深刻理解。首先看nRatedPower: DINT——为什么不用INT？因为DINT是32位有符号整数，覆盖范围±21亿，而电机功率最大也就50kW，看似浪费，实则规避了INT（16位）溢出风险。客户曾用INT存变频器频率设定值，当设定值超过32767（即32.767Hz）时，数值直接翻转成负数，驱动器瞬间停机。再看rTorqueLimit: REAL——REAL在汇川是IEEE754单精度浮点，占4字节，小数点后两位精度完全满足工业需求，且与HMI、SCADA系统无缝对接。如果用DINT存“扭矩×100”，虽然省空间，但HMI显示时要除以100，一旦除法运算出错，界面显示就是乱码。dtCalibrationTime: DT是关键。DT类型在汇川中固定占8字节，存储BCD格式的年月日时分秒毫秒。它不是为了好看，而是为了和PLC系统时钟同步。当你在配方调用时读取这个时间戳，就能判断该配方是否在设备断电重启后被篡改——因为PLC掉电后DT会清零，而配方数据还在RAM里，时间戳异常就触发报警。最后是sModelNo: STRING[16]。注意方括号里的16，不是字符数，而是字节数。STRING在汇川中每个字符占1字节，所以STRING[16]最多存16个ASCII字符。为什么不是20？因为汇川伺服型号如MS1H4-0400正好12字符，留4字节冗余刚好够存终止符\0。如果定义成STRING[20]，编译器会按20字节分配内存，但实际只用13字节（12字符+1终止符），剩下7字节浪费——在H5U这种资源受限的控制器里，每1字节内存都关乎扫描周期。这就是结构体的“工业感”：每一个字段类型、长度、顺序，都是为硬件特性、通讯协议、调试习惯量身定制的。它不像C语言那样追求通用，而是死死咬住“让现场工程师少出错”这个目标。

2.1 结构体嵌套：让复杂配方具备“树状可展开”能力

单一结构体只能描述扁平化参数，但真实产线配方往往有层级。比如一条锂电池涂布线，主配方包含“基材参数”、“浆料参数”、“烘箱参数”三大模块，每个模块下又有子项。这时就要用结构体嵌套。我在苏州某电池厂做的ST_CoatingRecipe就是典型：

TYPE ST_BaseMaterial : STRUCT sName: STRING[20]; // 基材名称 rThickness: REAL; // 厚度（μm） rTensileStrength: REAL; // 抗拉强度（MPa） END_STRUCT END_TYPE TYPE ST_Slurry : STRUCT sFormulaID: STRING[10]; // 浆料配方编号 rSolidContent: REAL; // 固含量（%） rViscosity: REAL; // 粘度（cP） bIsWaterBased: BOOL; // 是否水性浆料 END_STRUCT END_TYPE TYPE ST_OvenZone : STRUCT nZoneID: DINT; // 烘箱区段ID（1~8） rTempSetpoint: REAL; // 设定温度（℃） rAirFlow: REAL; // 风量（m³/h） END_STRUCT END_TYPE TYPE ST_CoatingRecipe : STRUCT bValid: BOOL; // 配方有效标志 sProductCode: STRING[15]; // 产品编码 stBaseMat: ST_BaseMaterial; // 嵌套结构体：基材 stSlurry: ST_Slurry; // 嵌套结构体：浆料 arOvenZones: ARRAY[0..7] OF ST_OvenZone; // 数组：8个烘箱区段 dtCreated: DT; // 创建时间 dtLastModified: DT; // 最后修改时间 END_STRUCT END_TYPE

嵌套的核心价值在于调试可视化。在InoProShop在线监控窗口里，当你展开stBaseMat节点，能看到sName、rThickness等子字段实时值；展开arOvenZones[0]，立刻显示第一区段的温度、风量。这比查一堆分散的DB地址直观一万倍。更重要的是内存布局可控。汇川规定：结构体嵌套时，子结构体在内存中是连续存放的。ST_CoatingRecipe总大小 =BOOL(1)+STRING[15](15)+ST_BaseMaterial(20+4+4=28)+ST_Slurry(10+4+4+1=19)+ARRAY[0..7] OF ST_OvenZone(8×(4+4+4=12)=96)+DT(8)+DT(8)=175字节。这个数字必须手算出来，因为后续所有操作——DB块分配、HMI变量映射、Modbus TCP读取——都依赖这个精确值。我见过太多人跳过这步，直接拖拽生成DB，结果HMI读取时发现arOvenZones[3].rTempSetpoint地址偏移错位，折腾半天才发现是结构体对齐没算准。汇川默认按字节对齐（Byte Alignment），所以没有填充字节，计算才简单。这点和西门子博途不同，博途默认按DWORD对齐，会自动插入填充，导致同样结构体在不同平台内存布局不一致——这也是为什么跨品牌集成时，结构体定义必须双方书面确认内存布局。

2.2 结构体数组：配方库的物理实现基础

工业配方从来不是单个参数，而是一组配方的集合。ARRAY[0..99] OF ST_CoatingRecipe——这就是配方库的物理载体。但数组不是随便定义的。我在珠海一家PCB厂遇到过血泪教训：他们用ARRAY[0..199] OF ST_Recipe存200个配方，每个配方150字节，总内存30KB。问题出在H5U控制器RAM只有64KB，其中系统占用20KB，用户程序占15KB，留给DB块的只剩29KB。30KB超了1KB，编译时没报错，但下载后PLC反复重启。后来我们把数组改成ARRAY[0..127] OF ST_Recipe（128×150=19.2KB），腾出空间给历史数据缓冲区，系统才稳定。所以定义数组前，必须做三件事：

1. 算总内存：数组长度 × 单个结构体字节数；
2. 查控制器规格：H5U系列RAM可用量见《H5U用户手册》第3章，AM600系列见《AM600技术规格书》附录B；
3. 留安全余量：至少预留10% RAM给临时变量、通讯缓冲、故障诊断日志。

另一个关键是索引命名规范。别用arRecipes[0]这种裸数字。我在所有项目里强制要求：arRecipes[RECIPE_INDEX_EMPTY]、arRecipes[RECIPE_INDEX_DEFAULT]、arRecipes[RECIPE_INDEX_CURRENT]。这些常量在全局常量块里定义：

// 全局常量块 G_CONSTANTS RECIPE_INDEX_EMPTY := 0; // 空配方占位符 RECIPE_INDEX_DEFAULT := 1; // 默认配方（开机自动加载） RECIPE_INDEX_CURRENT := 2; // 当前运行配方 RECIPE_INDEX_MAX := 127; // 最大有效索引

这样做的好处是代码可读性爆炸提升。当看到IF arRecipes[RECIPE_INDEX_CURRENT].bValid THEN...，不用猜0代表什么；当需要扩展，只需改RECIPE_INDEX_MAX，所有循环遍历自动适配。更重要的是，它为HMI开发铺路——HMI按钮标签直接绑定RECIPE_INDEX_CURRENT，而不是硬编码数字2，后期维护成本直降80%。

3. 手把手实现：从结构体定义到配方调用的完整闭环

现在进入实操环节。以下所有步骤，均基于InoProShop V3.5.0（H5U平台），已在东莞、苏州、宁波三地产线验证。不依赖任何第三方库，纯原生功能实现。

3.1 第一步：在数据类型库中创建结构体（含防错校验）

打开InoProShop → 工程 → 数据类型 → 右键“数据类型” → 新建数据类型 → 名称填ST_PackRecipe→ 类型选“结构体” → 确定。然后逐字段添加：

提示：初始值不是随意填的。bValid设为FALSE，确保新配方默认不生效，避免误启动；rFillVolume设0.0而非10.0，因为0是无效值，程序里可做校验；dtCreated和dtModified初始0，表示未初始化，后续在配方保存时由GET_SYSTEM_TIME()函数写入。

关键防错点来了：右键结构体 → 属性 → 勾选“启用结构体校验”。这会自动生成一个Check_ST_PackRecipe函数，它检查所有数值字段是否在合理范围内。比如rFillVolume必须≥10.0且≤1000.0，否则返回FALSE。这个函数不是摆设——我们在配方保存前强制调用它：

// 在配方保存FB中 IF NOT Check_ST_PackRecipe(stRecipe) THEN // 校验失败，触发HMI报警 stAlarmInfo.sCode := 'ERR_RECIPE_INVALID'; stAlarmInfo.sMsg := '配方参数超出范围，请检查灌装体积和速度'; TriggerAlarm(stAlarmInfo); RETURN; END_IF

没有这步，客户可能输个rFillVolume := -5.0，PLC不会报错，但执行时灌装泵反转，后果不堪设想。

3.2 第二步：创建DB块并实例化结构体数组（内存精打细算）

新建DB块 → 名称DB_RecipeLibrary→ 类型“全局DB” → 点击“添加变量” → 类型选ARRAY[0..49] OF ST_PackRecipe→ 名称arRecipes。这里长度49，是因为我们要留一个位置给RECIPE_INDEX_EMPTY（索引0），实际可用配方50个。

重点来了：右键DB块 → 属性 → 内存布局 → 选择“紧凑模式（Compact）”。这是汇川特有功能，能消除结构体内部因对齐产生的填充字节。如果不选，ST_PackRecipe（理论128字节）可能变成132字节，50个就是6600字节，而紧凑模式下严格128×50=6400字节。差200字节看起来不多，但在RAM紧张的H5U上，可能就是压垮骆驼的最后一根稻草。

然后，在DB块里再加两个辅助变量：

• nCurrentIndex: DINT// 当前配方索引，范围0~49
• bIsDirty: BOOL// 配方是否被修改过，用于HMI提示保存

这两个变量不参与配方数据存储，但极大提升交互体验。HMI切换配方时，先读nCurrentIndex，再从arRecipes[nCurrentIndex]取数据；用户修改后，bIsDirty置TRUE，HMI按钮变红提示“请保存”。

3.3 第三步：编写配方管理FB（功能块），封装核心逻辑

新建FB功能块 → 名称FB_RecipeManager→ 添加输入输出：

FB内部逻辑分三部分：

1. 保存逻辑：

// 检查索引有效性 IF nTargetIndex < 0 OR nTargetIndex > 49 THEN stLastError := '索引超出范围[0-49]'; bSaveOK := FALSE; RETURN; END_IF // 调用结构体校验 IF NOT Check_ST_PackRecipe(stRecipeData) THEN stLastError := '配方参数校验失败'; bSaveOK := FALSE; RETURN; END_IF // 写入DB DB_RecipeLibrary.arRecipes[nTargetIndex] := stRecipeData; // 更新时间戳 DB_RecipeLibrary.arRecipes[nTargetIndex].dtModified := GET_SYSTEM_TIME(); IF DB_RecipeLibrary.arRecipes[nTargetIndex].dtCreated = 0 THEN DB_RecipeLibrary.arRecipes[nTargetIndex].dtCreated := GET_SYSTEM_TIME(); END_IF // 标记当前索引 DB_RecipeLibrary.nCurrentIndex := nTargetIndex; bSaveOK := TRUE;

2. 加载逻辑：

// 检查索引 IF nTargetIndex < 0 OR nTargetIndex > 49 THEN stLastError := '索引超出范围[0-49]'; bLoadOK := FALSE; RETURN; END_IF // 检查配方是否启用 IF NOT DB_RecipeLibrary.arRecipes[nTargetIndex].bValid THEN stLastError := '配方未启用，请先启用'; bLoadOK := FALSE; RETURN; END_IF // 复制到工作区（假设有个全局工作配方stWorkingRecipe） stWorkingRecipe := DB_RecipeLibrary.arRecipes[nTargetIndex]; DB_RecipeLibrary.nCurrentIndex := nTargetIndex; bLoadOK := TRUE;

3. 初始化逻辑（首次上电）：在FB的静态变量区，定义bFirstScan: BOOL := TRUE。在FB调用处（主程序OB1）：

FB_RecipeManager( bSaveReq := ..., bLoadReq := ..., nTargetIndex := ..., stRecipeData := ..., bSaveOK => ..., bLoadOK => ..., stLastError => ... ); // 首次扫描初始化默认配方 IF FB_RecipeManager.bFirstScan THEN // 设置索引0为默认配方 DB_RecipeLibrary.arRecipes[0].bValid := TRUE; DB_RecipeLibrary.arRecipes[0].sProductName := 'DEFAULT'; DB_RecipeLibrary.arRecipes[0].rFillVolume := 500.0; DB_RecipeLibrary.arRecipes[0].rFillSpeed := 10.0; DB_RecipeLibrary.arRecipes[0].nSealTemp := 180; DB_RecipeLibrary.arRecipes[0].nSealTime := 800; DB_RecipeLibrary.arRecipes[0].dtCreated := GET_SYSTEM_TIME(); DB_RecipeLibrary.arRecipes[0].dtModified := GET_SYSTEM_TIME(); DB_RecipeLibrary.nCurrentIndex := 0; FB_RecipeManager.bFirstScan := FALSE; END_IF

这个FB就是配方功能的“心脏”。它把所有校验、时间戳、索引检查封装起来，主程序只需调用，无需关心细节。我在宁波项目里，客户要求增加“配方版本号”，只需在ST_PackRecipe里加nVersion: DINT字段，再在FB保存逻辑里stRecipeData.nVersion := stRecipeData.nVersion + 1，一行代码搞定，不影响现有逻辑。

3.4 第四步：HMI变量映射与交互设计（让操作员一目了然）

HMI用威纶通MT8071iE（最常用），变量映射必须严格对应DB块地址。关键原则：HMI变量名 = DB块名.变量名。

• DB_RecipeLibrary.arRecipes[0].sProductName→ HMI变量Recipe0_Name
• DB_RecipeLibrary.arRecipes[0].rFillVolume→ HMI变量Recipe0_Volume
• DB_RecipeLibrary.nCurrentIndex→ HMI变量CurrentRecipeIndex
• DB_RecipeLibrary.bIsDirty→ HMI变量RecipeDirtyFlag

交互流程设计：

1. 配方列表页：用List控件显示arRecipes[i].sProductName和arRecipes[i].bValid（图标显示启用/禁用）；
2. 编辑页：所有输入框绑定对应字段，修改时DB_RecipeLibrary.bIsDirty自动置TRUE；
3. 保存按钮：触发FB_RecipeManager.bSaveReq := TRUE，并传入nTargetIndex和stRecipeData；
4. 加载按钮：触发FB_RecipeManager.bLoadReq := TRUE，加载后自动跳转到“运行监控页”。

最实用的技巧：在HMI上加一个“快速复制”按钮。点击后，把当前配方（arRecipes[nCurrentIndex]）的所有字段，复制到下一个空闲索引（遍历arRecipes[i].bValid = FALSE找到第一个）。代码很简单：

// HMI脚本（伪代码） FOR i := 0 TO 49 DO IF DB_RecipeLibrary.arRecipes[i].bValid = FALSE THEN DB_RecipeLibrary.arRecipes[i] := DB_RecipeLibrary.arRecipes[DB_RecipeLibrary.nCurrentIndex]; DB_RecipeLibrary.arRecipes[i].dtCreated := GET_SYSTEM_TIME(); DB_RecipeLibrary.arRecipes[i].dtModified := GET_SYSTEM_TIME(); BREAK; END_IF END_FOR

客户换型时，复制一个基础配方再微调，比从头填快十倍。

4. 实战避坑指南：那些手册里不会写的血泪经验

4.1 结构体字段顺序决定内存地址，顺序错=全线崩溃

这是最致命的坑。汇川结构体字段在内存中是严格按定义顺序连续存放的。假设你定义：

TYPE ST_WrongOrder : STRUCT rValue: REAL; // 4字节 bFlag: BOOL; // 1字节 nCount: DINT; // 4字节 END_STRUCT END_TYPE

那么bFlag的地址 =rValue地址 + 4，nCount地址 =bFlag地址 + 1 =rValue地址 + 5。但如果HMI或上位机按“BOOL在前”的惯例去读，就会把rValue的后3字节当成bFlag，把bFlag和nCount的前1字节当成nCount低字节——数据全乱。我在无锡一家汽车零部件厂就遇到过：HMI厂家按西门子习惯，认为结构体第一个字段一定是BOOL，结果把rValue读成0.000123，产线报警停机。解决方案只有两个：一是HMI端严格按汇川结构体顺序解析；二是PLC端把BOOL字段统一放在结构体开头。我现在的标准做法是：

TYPE ST_StandardOrder : STRUCT bValid: BOOL; // 必须第一个 bEnable: BOOL; // 第二个 bAlarm: BOOL; // 第三个 // ...所有BOOL放前面 rValue: REAL; // REAL放中间 nCount: DINT; // DINT放后面 sName: STRING[20]; // STRING放最后 END_STRUCT END_TYPE

这样HMI解析时，只要知道“前N个字节是BOOL数组”，就能安全读取。手册里不会写，但这是跨平台集成的生命线。

4.2 Modbus TCP读取结构体：地址计算必须手算，不能依赖软件

很多工程师用Modbus Poll工具直接读DB块，发现arRecipes[0].rFillVolume读出来是乱码。原因：Modbus地址是16位寄存器（2字节），而REAL占4字节，需要连续两个寄存器。rFillVolume在ST_PackRecipe中偏移量是多少？必须手算：

• bValid: BOOL→ 1字节（地址0）
• sProductName: STRING[20]→ 20字节（地址1~20）
• rFillVolume: REAL→ 4字节（地址21~24）

Modbus地址从0开始，每个寄存器2字节，所以rFillVolume起始寄存器地址 = 21 ÷ 2 = 10（向下取整），即Modbus地址40011（标准Modbus地址=寄存器地址+40001）。如果用软件自动生成地址，它可能按“字段对齐”算成40012，结果读错。我的做法是：在InoProShop里，右键结构体 → “查看内存布局”，导出CSV，用Excel算偏移，再转Modbus地址。贴个真实计算表：

注意：STRING[20]占20字节，但起始偏移是1，因为bValid占1字节，地址0，sProductName从地址1开始。Modbus地址计算永远用起始偏移 ÷ 2，不是字段长度 ÷ 2。

4.3 H5U断电保持：结构体DB块必须勾选“保持性”

H5U的DB块默认不保持。如果配方存在DB里，断电后全丢，客户肯定炸锅。解决方法：右键DB块 → 属性 → 勾选“启用保持性”。但注意！保持性区域有限：

• H5U-16T：保持性RAM 8KB
• H5U-32T：保持性RAM 16KB

DB_RecipeLibrary（50×128=6400字节）刚好卡在临界点。如果还加了历史数据DB，就必须牺牲配方数量。我的方案是：把arRecipes数组放进保持性DB，而dtCreated/dtModified这类时间戳不保持——因为断电后时间重置，重新写入即可。在DB属性里，可以对单个变量取消保持性。右键arRecipes[0].dtCreated→ 属性 → 取消勾选“保持性”，这样省下8字节×50=400字节，足够加一个报警记录DB。

4.4 结构体与指针：慎用，除非你清楚每一步内存操作

InoProShop支持指针（POINTER TO），但工业现场极少用。我在昆山一个项目里，为实现动态配方调用，用了pRecipe: POINTER TO ST_PackRecipe，结果客户HMI升级后，指针地址解析出错，全线停产两天。根本原因是：指针存储的是绝对内存地址，而不同固件版本、不同编译选项，结构体起始地址可能变化。汇川官方文档明确警告：“指针操作应限于同一编译单元内，禁止跨DB、跨FB传递”。我的教训：用nCurrentIndex代替指针。所有访问都通过DB_RecipeLibrary.arRecipes[nCurrentIndex]，地址由编译器保证，绝对安全。指针只在极少数场景用，比如高速采集时用指针直接操作环形缓冲区，但那是底层驱动范畴，配方管理完全不需要。

5. 配方功能的延伸价值：不止于参数存储

把结构体用熟后，你会发现它像一把万能钥匙，能打开很多高阶应用。

5.1 配方版本管理：用结构体数组实现“Git式”回滚

客户常问：“上次调好的参数能恢复吗？”传统做法是备份整个DB文件，笨重且难定位。用结构体，可以这样设计：

TYPE ST_RecipeVersion : STRUCT nVersion: DINT; // 版本号，递增 stRecipe: ST_PackRecipe; // 配方快照 dtSaved: DT; // 保存时间 sOperator: STRING[10]; // 操作员 END_STRUCT END_TYPE // DB块：DB_RecipeHistory arHistory: ARRAY[0..99] OF ST_RecipeVersion; nHistoryCount: DINT; // 当前历史记录数

每次保存配方时，不是覆盖原数据，而是追加到arHistory，nVersion自动+1。HMI提供“版本列表”，点击即可加载任意历史版本。这比Excel备份强在哪？——所有操作留痕，不可篡改，审计时直接导出arHistory数组，就是完整的变更日志。

5.2 配方权限控制：结构体字段+PLC密码实现分级管理

食品厂客户要求：班组长能改参数，操作工只能加载。用结构体字段nPermissionLevel: DINT（0=操作工，1=班组长，2=工程师），配合PLC内置密码：

// 在FB_RecipeManager保存逻辑中 IF nPermissionLevel < 1 THEN stLastError := '权限不足，仅班组长及以上可保存'; bSaveOK := FALSE; RETURN; END_IF

HMI登录时，把用户等级写入nPermissionLevel，PLC端校验。比网络权限更可靠，因为不依赖外部认证服务器，断网也能用。

5.3 配方与AI结合：结构体作为AI模型的输入/输出接口

最近在帮一家药企做AI质检，模型输出是“最佳参数组合”。模型跑在边缘计算盒子上，通过Modbus TCP把结果写入PLC。我们约定：AI盒子写DB_AIOutput.stBestRecipe（类型同ST_PackRecipe），PLC收到后自动校验并加载。结构体成了AI与PLC的“通用语言”。没有结构体，AI输出一堆离散寄存器，PLC端要写几十行代码解析；有了结构体，一行赋值stWorkingRecipe := DB_AIOutput.stBestRecipe搞定。这就是工业4.0的落地形态——不是炫酷大屏，而是让数据在设备间无损流动。

最后分享个小技巧：在InoProShop里，按Ctrl+Shift+F，可以全局搜索结构体名。我所有项目都用ST_前缀（如ST_PackRecipe、ST_MotorConfig），这样搜ST_就能列出所有结构体，方便复用和审查。结构体不是炫技工具，它是把工业知识沉淀为可执行代码的容器。当你定义ST_PackRecipe那一刻，你写的不再是PLC程序，而是产线的工艺知识库。下次客户说“改个参数”，你不再熬夜改梯形图，而是打开HMI，点几下，保存，加载——然后喝杯咖啡，看产线平稳运行。这才是工程师该有的样子。