#WorkBuddy# 当 AI 助手遇上博图 Openness：SCL 一键导入-编译流水线实战（附完整踩坑清单）

#WorkBuddy# 当 AI 助手遇上博图 Openness：SCL 一键导入-编译流水线实战（附完整踩坑清单）

背景：电气工程师，西门子 S7-1200 / TIA Portal V16 / SCL。 本文记录我用 WorkBuddy（腾讯 AI 办公工作台）搭建一套"TIA Portal Openness 自动化工具箱"的完整过程： 从三个前置门槛、程序集加载、两个反直觉的 API 硬知识，到最终"导入 SCL → 生成块 → 编译 → 建实例 DB → 保存"一键流水线，以及实测效率数据。全部结论本机实测，可直接复现。

一、为什么不用模拟点击，而用 Openness

PLC 日常开发里最重复的循环是：改 SCL → 导入 → 编译 → 看报错 → 再改。手点博图一轮下来又慢又容易漏。西门子官方提供了 TIA Portal Openness API，可以在 .NET（本项目用 PowerShell）里程序化操作博图——不模拟鼠标键盘，全部走官方接口，稳定且可复现。

WorkBuddy 在这里的角色：让它读西门子官方文档、直接迭代维护这个几百行的 PowerShell 脚本（TiaOpenness.ps1），我只需要下指令"导入这两个源文件并编译"，它自己调 API、解析 JSON 结果、根据报错改脚本。人只负责验收和拍板。

工具形态很简单：

& "$env:SystemRoot\System32\WindowsPowerShell\v1.0\powershell.exe" `
  -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\.workbuddy\tia-openness\TiaOpenness.ps1" `
  -Action deploy-scl -Mode Visible -TiaVersion V16 `
  -ProjectPath "D:\PLC\项目1\项目1.ap16" `
  -SourceFile "FB_xxx.scl;DB_xxx.scl" -SourceName "FB_xxx;DB_xxx" `
  -InstanceDbName "DB_xxx" -InstanceDbTypeName "FB_xxx" -SaveProject

二、三个前置门槛（按顺序排查，缺一不可）

1. 权限组必须注销重登才生效。 把账号加入本地组 Siemens TIA Openness 后立即调用仍然报 EngineeringSecurityException——Windows 进程令牌在登录时生成，改组不刷新已有令牌。两个高频误区，都是我实测踩出来的：

• "重开博图就好了"——错。同一登录会话里启动的任何进程都继承旧令牌，重启进程无效；
• 判断标准不是 groupInSam，而是令牌里的 groupInToken。另外 TiaPortal.GetProcesses()（status）在无权限时也能跑通，不能拿它判断权限已生效。

正确顺序：加组 → 注销重登 → 从新会话开博图 → 再附着。

2. API 版本必须与本机 Portal 安装目录同名。 每个 Portal 的 PublicAPI\ 下都带着多个旧版 API 文件夹（给旧 AddIn 兼容）。必须用与 Portal 同名的那份，判据是文件版本号（V16 = 1600.x）。如果脚本图省事"取最高版本"，会错抓到别的新版 API，与实例类型不兼容。

3. 宿主必须 64 位。 用 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe（PS 5.1 Desktop），判据 [IntPtr]::Size -eq 8。

三、程序集加载：ReflectionTypeLoadException 的根因链

只 Add-Type 主程序集必炸。排查过程：

1. PublicAPI\V16\ 里只有 Siemens.Engineering.dll 和 .Hmi.dll，但主程序集还依赖 Siemens.Engineering.Contract.dll、Siemens.Engineering.ClientAdapter.Interfaces.dll；
2. 这两个不在 PublicAPI\V16\，而在 <PortalRoot>\Bin\PublicAPI\；
3. GAC 里没有注册任何西门子程序集，指望不上自动解析；
4. PowerShell 脚本块做 AppDomain.AssemblyResolve 处理器不可靠（可能在没有 runspace 的线程上被调用，取不到闭包变量）。

最终解法：探针目录预加载 + 按报错迭代补齐。预加载 PublicAPI\V<x>、Bin\PublicAPI 等目录里全部小体积 DLL，再加载主程序集；若仍抛异常，从 LoaderExceptions[].Message 用正则抽出缺失程序集简单名（注意报错里是全角引号，正则别写死引号字符），按 <名>.dll 找到并加载，最多重试 6 轮。实测预加载 6 个程序集后一次通过。

四、两个反直觉的 API 硬知识

1. 编译要走 GetService<ICompilable>()，而不是 GetService<CompileProvider>()。

用反射 dump 全量元数据可以证实：ICompilable 是 public 接口，唯一实现者 CompileProvider 却是 internal。业务对象（Device / PlcSoftware）谁都不直接实现 ICompilable——编译是"取服务"模式，服务按接口契约注册，拿 internal 实现类当服务键永远返回 null。V16 实测 Device 和 PlcSoftware 两级提供编译服务（PowerShell 下用反射 MakeGenericMethod 调泛型 GetService）。

2. V16 不能给 SCL 的 FB 建实例 DB。

西门子官方文档原文：V16 起仅支持 ProDiag，V17 起才扩展到 LAD/FBD/STL/SCL/Graph。对 SCL 的 FB 调 CreateInstanceDB 必然报 The action "Create" can only create instance DBs from 'ProDiag'.

V16 的正确做法：把实例 DB 写成单独的源文件走"从源文件生成块"：

DATA_BLOCK "DB_PoleTypeParse"
{ S7_Optimized_Access := 'TRUE' }
"FB_PoleTypeParse"
BEGIN
END_DATA_BLOCK

两条硬规则（实测）：FB 与它的实例 DB 不能写在同一个源文件里（GenerateBlocksFromSource 一次性解析整份文件，生成 DB 时 FB 还没进块容器，报"无法找到类型"）；DB 段显式写优化访问属性可少一条提示。

五、一键流水线与实测数据

deploy-scl 把全链路压进同一次博图会话：[-CleanFirst 干净重建] → 按序导入源文件组 → 编译整设备 → 有错中止 → 校验/生成实例 DB → 再编译 → 编译 0 错才保存。任何一步失败都不落盘，项目保持原样——这是刻意设计的保守策略。

实测数据（TIA V16，同一项目）：

三个结论值得记住："导入税"其实很小——热迭代一轮 2.4 s，比在 GUI 里点开一个块还快；外部源是"导入那一刻的快照"——改了磁盘 .scl 不重新导入，重新生成照样用旧快照（用探针故意改坏源文件验证过），所以改完必须重导；"博图内直接写"这条路在 API 上不可自动化——PlcBlockComposition 全量扫描后确认没有任何方法能接收 SCL 源码文本，这就是自动化方案只能走"外部编辑 + 导入"形态的根本原因。

还有个体验细节：界面跟随（ShowInEditor）实测是纯后台切换（探针证实调用前后前台窗口进程不变），配合"绝不抢焦点"策略——博图最小化就不还原、用户在用别的软件就不弹窗，切回博图时界面已经切好。自动化与人工可以同屏共存。

六、WorkBuddy 在整个过程中的价值

坦率说，上面每个坑单拿出来都不难查，但组合起来的排查是体力活：报错信息晦涩（很多只有一句英文异常）、官方文档分散、试错一次要开关一次博图。WorkBuddy 的价值在于：

1. 把文档查证和脚本迭代合并进对话——我描述现象，它改脚本、跑探针、读 JSON 结果、再改，一轮一轮收敛，我只需要验收结论；
2. 结果全部落盘 JSON，每次运行可复现、可对比，方便它自己"回看"上一次为什么失败；
3. 探针化诊断——比如"编译服务挂在哪一级""外部源是不是快照"这类问题，直接让它写一次性探针实测，不靠猜。

结语

外部编辑 + Openness 导入这条路线，适合程序规模大、要进 Git 做版本管理、要反复迭代交付的场景（盈亏平衡点：同一程序改 2~7 次以上，之后每轮只花 2.4 s）；现场即兴小改当然还是博图里直接敲最快。工程上最实用的混合姿势是：主体用外部编辑写（文本源是唯一真源），落地点用博图内编译校验。

如果你也在用西门子生态 + AI 助手做开发自动化，欢迎交流。文中全部数据出自本机实测，环境为 TIA Portal V16 / Windows PowerShell 5.1 x64。

本文参与 #WorkBuddy #AI办公 话题征集。