📚 课程目录第2章 VisionPro软件架构与多相机支持机制

2. VisionPro软件架构与多相机支持机制

VisionPro 的软件架构可以理解为“三层容器 + 两类资源”的组织方式：最外层是项目（Project），它把一次视觉检测任务所需的相机、作业、工具、标定数据和脚本打包在一起；中间层是作业（Job），它对应一个独立的检测工位或一个检测节拍；最内层是工具组（ToolGroup），它承载真正执行图像处理的工具链。两类资源则是相机（Camera）与工具（Tool），前者负责取像，后者负责计算。理解这套层级关系，是设计多相机平台的前提。

项目、作业与工具组的层级关系

在 VisionPro 中，一个 .vpp 项目文件是部署与备份的最小单位。项目内部可以包含多个 Job，每个 Job 又可以包含多个 ToolGroup。这种“一对多”的嵌套结构，正是多相机支持的根基：一台工控机可以运行一个项目，项目内为每台相机分配一个 Job，每个 Job 内再按检测逻辑划分 ToolGroup。

需要特别区分 Job 与 ToolGroup 的职责。Job 是调度与同步单位，它决定“什么时候取像、什么时候触发、结果如何汇总输出”；ToolGroup 是计算单位，它决定“图像进来之后做哪些处理”。一个 Job 可以只含一个 ToolGroup，也可以含多个并行或串行的 ToolGroup。例如双相机检测同一工件时，可让 Job 同时触发两台相机，各自进入独立 ToolGroup，最后在 Job 层做结果合并。

相机管理：从物理设备到逻辑资源

VisionPro 通过 CogFrameGrabber 系列接口管理相机。实际工程中，相机接入后并不会自动出现在项目里，需要先在 Image Acquisition 配置中完成三步：识别设备、设置取像参数、绑定到 Job。以三台 GigE 相机为例，典型配置如下：

相机1  IP: 192.168.1.11  触发: 硬件Line0  曝光: 8000us  增益: 6dB
相机2  IP: 192.168.1.12  触发: 硬件Line0  曝光: 6000us  增益: 4dB
相机3  IP: 192.168.1.13  触发: 软件触发   曝光: 10000us 增益: 8dB
网卡   双口千兆，Jumbo Frame = 9014，相机与网卡同网段

这里的关键是触发方式与 Job 的对应。相机1、相机2 使用同一路硬件触发信号，意味着它们在同一时刻取像，适合检测同一工件的不同面；相机3 使用软件触发，由 Job 内部逻辑在需要时单独调用。若把三台相机都塞进同一个 Job，取像时序会互相牵制，反而降低节拍。因此推荐“一相机一 Job”或“同触发相机共 Job”的划分原则。

Job 与 ToolGroup 的组织策略

ToolGroup 的划分应遵循“功能内聚、数据独立”的原则。一个常见的三相机检测平台可以这样组织：

Job 1（上表面检测）：ToolGroup 1-1 用 CogPMAlignTool 定位基准，CogCaliperTool 测量边距；ToolGroup 1-2 用 CogBlobTool 检测表面污点。
Job 2（下表面检测）：结构与 Job 1 对称，但标定参数独立，因为镜头与工作距离不同。
Job 3（侧面字符检测）：ToolGroup 3-1 先做字符区域定位，再调用 OCR 工具读取批次号。

每个 ToolGroup 内部的工具按数据依赖顺序排列：先标定（CogCalibCheckerboard），再定位（CogPMAlignTool），再测量或检测，最后用 CogFixtureTool 把结果统一到同一坐标系。这样做的目的是让下游工具只依赖上游的输出，而不是依赖图像像素位置，便于换型时只改定位工具。

实践提示：多相机项目中，建议为每台相机单独保存一份标定文件，并在 Job 属性中显式指定标定文件路径。若共用一份标定文件，相机更换或镜头调整后会导致所有 Job 的测量结果同时偏移，排查成本很高。

多相机同步与结果汇总

多相机平台的核心难点不在单台相机的处理，而在同步与结果汇总。VisionPro 提供两种典型同步方式：

第一种是硬件同步。由 PLC 或运动控制卡发出同一路触发脉冲，同时接入多台相机的触发输入。此时各 Job 独立运行，但取像时刻一致。适合检测同一工件的多个面，或需要多视角拼接的场景。

第二种是软件同步。由一个主 Job 通过 CogJob 的 Run 方法依次或并行调用其他 Job，再收集各 Job 的输出结果。这种方式灵活，但要注意线程安全：VisionPro 的 Job 默认不是线程安全的，若多个线程同时调用同一 Job，需要加锁或使用 Job 的独立实例。

结果汇总通常在 Job 层完成。每个 ToolGroup 的输出可以通过 Outputs 集合暴露给 Job，Job 再把这些结果映射到通信接口（如 PLC 的 I/O 点或 TCP 报文）。例如：

Job1.Outputs["Pass"]  →  PLC 输入点 I0.0
Job2.Outputs["Pass"]  →  PLC 输入点 I0.1
Job3.Outputs["Code"]  →  TCP 字符串发送至 MES
综合判定 = Job1.Pass AND Job2.Pass AND Job3.Pass

这里要特别注意：综合判定逻辑应放在 Job 层或外部 PLC，而不是塞进某个 ToolGroup。ToolGroup 只负责“我这一路是否合格”，跨相机的逻辑判断属于调度层职责。这样划分后，增加或减少相机时，只需调整 Job 层的汇总逻辑，不必改动各 ToolGroup 内部工具链。

项目结构设计中的常见误区

第一个误区是把所有相机放进一个 Job。这样做的直接后果是取像时序耦合，任何一台相机延迟都会拖慢整个节拍；同时 ToolGroup 数量膨胀，调试时难以定位是哪一路出了问题。

第二个误区是ToolGroup 划分过细。每个工具单独建一个 ToolGroup，会导致 Job 内部调用链过长，中间结果传递开销增加。合理的粒度是“一个功能模块一个 ToolGroup”，例如“定位与测量”合为一组，“缺陷检测”单独一组。

第三个误区是忽略标定与坐标系的统一。多相机系统中，若各相机坐标系未统一到工件坐标系，测量结果无法直接比较。正确做法是在每个 Job 内先用 CogCalibCheckerboard 建立像素到物理单位的映射，再用 CogFixtureTool 把结果转换到工件坐标系，最后在 Job 层汇总时所有数值都处于同一物理坐标系下。

注意：修改项目层级结构（如增删 Job 或 ToolGroup）后，务必重新检查各 Job 的触发源和输出映射。VisionPro 不会自动迁移已绑定的 I/O 点，遗漏会导致产线误判。

掌握项目、Job、ToolGroup 与相机之间的映射关系后，多相机平台的设计就变成了一个可分解的工程问题：先确定相机数量与触发方式，再划分 Job，最后在 Job 内组织 ToolGroup 和工具链。这套结构一旦稳定，后续增加相机或更换检测项都只是局部调整，而不会牵动整个项目。