2. VisionPro软件架构

VisionPro 的软件架构可以理解为“一个运行时内核 + 两套开发/调试入口 + 三层作业组织模型”。理解这套架构，直接决定了后续做项目时，代码应该写在哪一层、参数应该配在哪一层、调试时应该看哪个界面。很多初学者把 QuickBuild 当成“画流程图的地方”，把 VisionPro Explorer 当成“另一个 QuickBuild”，结果在交付阶段出现“QuickBuild 里调通了，C# 里跑不通”的典型问题。根源就在于没有分清这两套入口各自面向什么、Job 与 Tool 又是如何被组织和执行的。

一、两套入口：QuickBuild 与 VisionPro Explorer 的分工

QuickBuild 是面向“作业设计与验证”的图形化环境。它的核心工作单元是 Job，一个 Job 内部可以包含多个 Tool，Tool 之间通过图像、终端、坐标等数据连接形成处理链。QuickBuild 的价值在于：可以在不写一行代码的前提下，把取像、定位、测量、检测、通信等环节串起来，并立即看到中间图像和结果。它适合做算法验证、参数整定和作业原型。

VisionPro Explorer 则是面向“运行时对象浏览与诊断”的工具。它连接的是已经加载到进程中的 VisionPro 运行时对象树，可以看到当前进程里有哪些 Job、每个 Job 下挂了哪些 Tool、每个 Tool 的输入输出终端当前是什么值。它不负责“设计”，而负责“观察”和“干预”。在交付现场，当 C# 程序已经调用 VisionPro 运行时，Explorer 是排查“为什么这个 Tool 没出结果”的第一现场。

两者的关系可以概括为：QuickBuild 产出 Job 文件（.vpp），运行时由应用程序加载该文件并实例化出 Job 对象；Explorer 则挂接到这个已实例化的运行时对象树上进行查看。设计态与运行态分离，是 VisionPro 架构的基本约定。

二、Job 与 Tool 的组织方式

一个 Job 是“一次完整检测任务”的封装，它至少包含三部分：取像配置、工具组（ToolGroup）和结果输出。取像配置决定图像从哪里来——可以是 GigE 相机、Camera Link 采集卡，也可以是本地图片文件夹；工具组决定图像进来之后做什么；结果输出决定把哪些终端值暴露给外部程序。

Tool 是真正干活的算法单元。VisionPro 的 Tool 种类很多，常见的有：CogPMAlignTool（模板匹配定位）、CogBlobTool（斑点/连通域分析）、CogFindLineTool（找边）、CogCaliperTool（卡尺测量）、CogOCVMaxTool（字符验证）等。每个 Tool 都有输入终端和输出终端，例如 CogPMAlignTool 的输入是 Image，输出是 Results 中的 Pose、Score、Found 等。Tool 与 Tool 之间通过终端连接传递数据，比如把 PMAlign 的 Pose 输出接到 Blob 的 Region 输入上，就实现了“先定位、再在定位区域内做斑点分析”。

ToolGroup 是 Tool 的容器，它解决两个问题：一是执行顺序，二是条件分支。默认情况下 ToolGroup 内的 Tool 按添加顺序依次执行；但可以通过设置 Tool 的 Enabled 属性或使用 CogToolGroup 的条件执行机制，让某些 Tool 只在特定条件下运行。例如：只有当 PMAlign 的 Score 大于 0.7 时才执行后续测量，否则跳过并输出 NG。这种“定位失败就不测量”的逻辑，在产线上非常常见，用 ToolGroup 表达比在 C# 里写 if-else 更直观，也更容易在 QuickBuild 里验证。

三、运行时环境与对象模型

在运行时，应用程序通过 CogJobManager 管理一个或多个 Job。典型流程是：创建 CogJobManager → 通过 JobManager.Job(0) 获取 Job → 调用 Job.Run() 或 Job.RunOnce() 执行 → 从 Tool 的输出终端读取结果。CogJobManager 还负责相机连接、触发源配置和作业切换。如果项目有多个工位，可以创建多个 Job，每个 Job 对应一个工位，由 JobManager 统一调度。

这里有一个容易踩的坑：QuickBuild 里看到的“图像”是设计态缓存的图像，而运行时 Job.Run() 会重新取像。如果相机没连接、触发没配置、曝光时间不对，QuickBuild 里调好的参数在运行时可能完全失效。因此交付前必须在运行态用 Explorer 确认：Job 是否成功加载、Tool 是否执行、输出终端是否有值。

四、一个可参考的 Job 组织示例

假设一个连接器端子检测工位，需求是：先定位连接器本体，再检测每个端子的有无和位置偏移。可以按如下方式组织：

在 C# 中读取结果的示意代码如下（示例参数，非实测值）：

CogJobManager jobManager = new CogJobManager();
jobManager.Job(0).Run();
CogPMAlignTool pm = jobManager.Job(0).VisionToolGroup(0)["CogPMAlignTool1"] as CogPMAlignTool;
double score = pm.Results[0].Score;
bool found = pm.Results[0].Found;
if (found && score > 0.7)
{
    // 继续读取 Blob 与 Caliper 结果
}

这段代码的关键在于：Tool 是通过名称从 ToolGroup 中索引出来的，名称必须与 QuickBuild 中一致。如果 QuickBuild 里改了 Tool 名称而代码没同步，运行时就会取到 null。这也是交付阶段最常见的低级错误之一。

五、设计态与运行态的边界

总结来说，QuickBuild 负责“把作业搭出来并验证算法可行”，VisionPro Explorer 负责“看运行时到底发生了什么”，Job 负责“封装一个工位的完整任务”，Tool 负责“执行具体算法”，ToolGroup 负责“组织执行顺序和条件”。四者各司其职，边界清晰。交付工程师需要建立的习惯是：在 QuickBuild 里调通只是第一步，必须在运行态用 Explorer 复核一遍，确认 Job 加载、Tool 执行、终端取值三个环节都正常，才算真正完成一个工位的交付。