4. 定制工程环境搭建与版本管理

Process Model 定制不是“改一个文件”那么简单。一个可用的定制工程通常同时包含模型文件、类型定义、用户界面资源、回调代码、外部依赖库以及编译产物。如果这些内容散落在个人电脑的不同目录里，后续升级 TestStand、切换测试站或多人协作时，几乎必然出现“模型能打开但回调找不到”“类型定义版本不一致”“换台机器就编译失败”等问题。因此本节的核心任务是：先把开发环境固定下来，再建立一个边界清晰的工程目录，最后用源代码控制把模型文件与依赖项一起管起来。

一、开发环境配置：先固定版本与路径

TestStand 的 Process Model 定制对版本非常敏感。模型文件（.seq）由特定版本的 TestStand 引擎创建，回调原型、类型系统和 API 在不同大版本之间可能存在差异。工程开始前应明确三件事：TestStand 主版本（例如 2021 或 2023）、开发语言与编译器（LabVIEW、C#/.NET 或 CVI）、以及操作系统位数。建议在工程根目录放一份 environment.md，记录以下信息，作为团队统一基线：

TestStand 版本: 2023 (32-bit)
开发语言: LabVIEW 2023 (32-bit)
.NET Framework: 4.8
编译器: Visual Studio 2022 (C# 回调)
共享模型路径: C:\ProgramData\National Instruments\TestStand 2023\ModelPlugins

路径规划是环境配置中最容易被忽视的一环。TestStand 在运行时按“搜索目录”顺序查找模型、回调、类型定义和依赖 DLL。如果定制模型放在用户目录，而依赖 DLL 放在系统目录，换一台机器后搜索路径就会失效。推荐做法是：所有与定制模型相关的文件都放在工程目录内，通过 TestStand 的 Search Directories 配置把工程目录加入搜索路径，而不是依赖绝对路径。这样工程目录整体拷贝到另一台机器后，只需重新指定工程根目录即可运行。

二、定制模型工程目录结构

一个可维护的定制模型工程，目录结构应当体现“源文件与产物分离、模型与依赖分离、公共与私有分离”三个原则。下面给出一个经过实践检验的目录模板，适用于基于 LabVIEW 或 .NET 回调的 Process Model 定制：

MyProcessModel/
├─ src/
│  ├─ models/            # 定制模型 .seq 文件
│  ├─ callbacks/         # 回调代码（LabVIEW VI 或 C# 项目）
│  ├─ typedefs/          # 自定义类型定义 .ini / .seq
│  └─ ui/                # 登录、操作员界面等资源
├─ deps/                 # 第三方 DLL、驱动、运行时依赖
├─ build/                # 编译产物（不纳入版本控制）
├─ config/
│  ├─ searchdirs.xml     # 搜索路径配置导出
│  └─ environment.md     # 环境基线记录
├─ docs/                 # 设计说明、变更记录
└─ .gitignore

其中 src/models/ 存放模型主文件，src/callbacks/ 存放回调实现，src/typedefs/ 存放类型定义。把类型定义单独抽出来，是因为它同时被模型和回调引用，一旦版本不一致，模型加载时会出现“类型不匹配”错误。deps/ 用于存放无法通过包管理器获取的依赖，例如特定版本的仪器驱动或 NI 运行时组件。build/ 是编译输出目录，必须排除在版本控制之外，否则每次编译都会产生大量二进制差异，污染提交历史。

三、源代码控制策略：模型文件与依赖项一起管

TestStand 的 .seq 文件本质上是 XML 文本，但其中包含大量 GUID、时间戳和二进制嵌入资源。直接对 .seq 做文本 diff 往往可读性很差，因此团队需要约定提交粒度：每次提交只改一个逻辑单元，并在提交信息中写明“改了哪个回调、影响哪个模型步骤”。对于 LabVIEW 的 .vi 和 C# 的 .dll，它们是二进制文件，Git 无法有效做行级差异，建议使用 Git LFS 管理，或者把编译产物放到制品库（如 Nexus、Artifactory），仓库里只保留源码和构建脚本。

依赖项管理是版本控制中最容易出问题的部分。假设定制模型引用了 deps/InstrumentDriver.dll，而这个 DLL 又依赖某个特定版本的 NI-VISA。如果只把 DLL 提交到仓库，换一台机器后仍然可能因为 VISA 版本不同而加载失败。更稳妥的做法是：在 deps/ 下为每个依赖建立子目录，并附一个 README.md 说明来源、版本号和安装方式；对于可通过包管理器获取的依赖，用 packages.config 或 *.lvproj 中的依赖声明来记录，而不是把安装包直接塞进仓库。

四、从零搭建的实操流程

下面以 Git + LabVIEW 回调为例，给出一次完整的工程初始化过程。假设团队已经确定 TestStand 2023 32 位、LabVIEW 2023 32 位作为基线。

1. 在 Git 服务器上创建空仓库 MyProcessModel，克隆到本地工作目录。
2. 按第二节的目录模板创建 src/、deps/、config/、docs/ 四个顶层目录，并创建 .gitignore，写入 build/、*.lvlps、*.log 等忽略规则。
3. 在 TestStand 中打开 Process Model 文件，另存到 src/models/ 下，命名为 MyProcessModel.seq。注意另存后要检查模型中的回调路径是否仍然指向 src/callbacks/，如果指向了旧路径，需要手动修正。
4. 在 LabVIEW 中创建回调 VI，保存到 src/callbacks/，并在 TestStand 的模型回调配置中把每个回调指向对应的 VI。回调 VI 的输入输出簇必须与模型定义的原型一致，否则运行时会报“回调原型不匹配”。
5. 把模型引用的类型定义文件复制到 src/typedefs/，并在 TestStand 的类型定义管理器中重新加载，确认没有“未解析类型”。
6. 在 TestStand 的 Search Directories 中把 src/models/、src/callbacks/、src/typedefs/、deps/ 加入搜索路径，然后通过 Configure > Search Directories > Export 导出为 config/searchdirs.xml，提交到仓库。
7. 执行一次完整的测试序列，确认模型能正常加载、回调能被调用、类型定义能正确解析。把这次可运行的版本打上 Git 标签，例如 v0.1.0-baseline。

完成上述步骤后，工程就具备了“可克隆、可复现、可追溯”的基本条件。后续每次修改模型或回调，都应当遵循同样的提交粒度，并在提交前用 config/searchdirs.xml 重新导入搜索路径，确保本地环境与仓库记录一致。如果团队成员使用不同的 TestStand 版本，建议在 environment.md 中明确写出“仅支持 2023 32 位”，并在 CI 或构建脚本中加入版本检查，避免用高版本打开低版本模型后产生不可逆的格式升级。

五、常见问题与判断依据

环境搭建和版本管理阶段最常见的问题有三类。第一类是“模型能打开但回调找不到”，判断依据是 TestStand 加载模型时弹出“Callback not found”或“VI not found”，此时应检查搜索路径是否包含 src/callbacks/，以及回调 VI 的文件名是否与模型中的引用完全一致（包括大小写）。第二类是“类型定义版本不一致”，表现为模型加载时报“Type definition mismatch”，此时应对比 src/typedefs/ 中的类型定义与模型内嵌类型是否同源，必要时用 TestStand 的类型定义同步工具重新生成。第三类是“换机器后编译失败”，通常是因为 deps/ 中的依赖没有完整提交，或者依赖的运行时组件没有安装，此时应按照 deps/README.md 逐项核对。

把这三类问题的判断依据固定下来，团队在遇到环境问题时就能快速定位，而不是反复重装 TestStand。环境搭建和版本管理本身不产生测试功能，但它决定了后续所有定制工作能否稳定复现。先把这个基础打牢，再进入模型逻辑的定制，才是工程上更稳妥的顺序。