1. TestStand适配器架构总览
TestStand 本身并不直接执行 LabVIEW VI 或 C# 方法，它扮演的是测试执行引擎与序列调度器的角色：负责解析序列文件、管理步骤流程、记录结果、处理报表与并行测试。真正“干活”的代码——无论是 LabVIEW 的 VI、C# 的类库方法，还是 DLL、Python 脚本——都通过适配器（Adapter）这一中间层被调用。理解适配器架构，是掌握 LabVIEW 与 C# 混合集成开发的第一道门槛。
适配器在 TestStand 中的角色
可以把适配器理解为“翻译官 + 接线盒”。TestStand 的步骤（Step）在序列文件中只保存通用描述信息，例如步骤类型、模块路径、参数列表、调用配置等；而具体“如何加载目标代码、如何传参、如何取回返回值、如何报告错误”这些与语言相关的细节，全部由适配器实现。TestStand 引擎在运行到某个步骤时，会查询该步骤绑定的适配器，把控制权交给适配器，由适配器完成与外部代码的交互，再把执行状态（成功、失败、错误码、耗时）回传给引擎。
这种设计带来三个直接好处：其一，序列文件与具体编程语言解耦，同一套序列框架可以调用不同语言编写的模块；其二，新增语言支持只需开发新适配器，无需改动引擎；其三，参数传递、错误处理、资源释放等共性逻辑被适配器统一封装，测试开发者只需关注业务逻辑本身。
LabVIEW 与 C# 适配器的定位差异
TestStand 出厂自带多个适配器，其中最常用的两个正是本节关注的重点：LabVIEW 适配器与.NET 适配器（C# 代码通常编译为 .NET 程序集，因此走 .NET 适配器路径）。二者定位有明显区别：
- LabVIEW 适配器：直接调用 VI。它理解 LabVIEW 的数据类型（数值、布尔、字符串、数组、簇、波形等），能够自动完成 TestStand 属性与 VI 前面板控件/指示器之间的映射。适合测量采集、信号处理、仪器驱动等图形化编程场景。
- .NET 适配器：调用 .NET 程序集中的类与方法。它通过反射加载程序集，按方法签名匹配参数，支持静态方法与实例方法。适合复杂算法、数据库访问、业务逻辑封装、已有 C# 资产复用等场景。
两者并非互斥。实际项目中常见做法是：用 LabVIEW 完成硬件交互与实时采集，用 C# 完成数据处理与上层逻辑，再由 TestStand 序列把二者串联成完整测试流程。
序列调用外部代码的机制
无论使用哪种适配器，调用过程都遵循一条共同的信号链：序列步骤 → 适配器 → 目标代码 → 返回值/错误 → 引擎记录。以调用一个 LabVIEW VI 为例，TestStand 引擎执行到该步骤时，LabVIEW 适配器会：
- 根据步骤中记录的 VI 路径加载 VI（若已加载则复用）；
- 读取步骤的参数字段，把 TestStand 变量按名称映射到 VI 的输入控件；
- 以配置的调用方式（如“按引用调用”）运行 VI；
- VI 执行完毕后，把输出指示器的值写回步骤的参数字段或局部变量；
- 根据 VI 的错误簇判断步骤状态，写入结果记录。
调用 C# 方法时机制类似，区别在于 .NET 适配器需要通过程序集路径 + 类名 + 方法名定位目标，并按方法参数类型做类型转换。若方法签名与步骤参数不匹配，适配器会在加载阶段报错，而不是等到运行时才失败——这一点对调试非常关键。
整体集成路线
从工程落地角度看，LabVIEW 与 C# 适配器集成通常遵循以下路线：先确定哪些功能用 LabVIEW 实现、哪些用 C# 实现；再分别准备好 VI 与 .NET 程序集，确保接口清晰、参数类型明确；然后在 TestStand 中创建序列，为每个步骤选择合适的适配器并配置模块路径与参数映射；最后通过单步调试验证每个模块的输入输出，再串联成完整测试序列。
下面这张图展示了 TestStand 引擎、两类适配器与外部代码之间的整体架构关系，以及序列步骤调用外部代码时的数据流向。
从图中可以清楚看到两条并行的调用路径：左侧绿色序列文件通过适配器绑定，分别进入橙色 LabVIEW 路径和紫色 .NET 路径，最终到达各自的代码实体；执行完成后，返回值与错误信息沿虚线回传，由引擎统一记录。这种“引擎—适配器—代码”的三层结构，正是 TestStand 能够灵活集成多种语言的根本原因。
在实际配置时，需要特别关注几个关键点：LabVIEW 适配器要求 VI 的输入输出控件命名与步骤参数一致，否则映射会失败；.NET 适配器要求程序集路径、类名、方法名完全匹配，且方法参数类型需与步骤参数兼容。建议在集成初期先用最简单的“加法 VI”和“加法方法”做连通性验证，确认适配器配置无误后，再逐步替换为真实业务模块。这样可以把适配器层面的问题与业务逻辑问题分开定位，避免混在一起难以排查。