2. VisionPro开发环境与项目结构

在开始把 VisionPro 接入产线系统之前，必须先厘清一个根本问题：用 QuickBuild 还是用 VisionPro SDK？两者并不是互斥的替代品，而是面向不同交付形态的两条路径。QuickBuild 是图形化的作业编辑与运行环境，适合快速搭建、现场调试、由工艺或调试工程师维护的视觉方案；VisionPro SDK（.NET 程序集，核心命名空间为 Cognex.VisionPro 及 Cognex.VisionPro.QuickBuild 等）则把作业、工具、图像采集全部暴露为可编程对象，适合需要与 MES、PLC、数据库、上位机界面深度耦合的集成项目。实际工程中更常见的做法是：用 QuickBuild 完成算法验证与作业定型，再用 SDK 把定型后的 .vpp 作业加载进自研程序，从而兼顾开发效率与集成灵活性。

判断选型的核心依据可以归纳为三点：一是交付形态——若最终交付的是一个独立运行的视觉检测站，QuickBuild 加运行版授权即可；若视觉只是上位机软件中的一个模块，则必须走 SDK。二是变更频率——工艺参数频繁调整、需要现场人员自行改 ROI 或阈值的场景，QuickBuild 的可视化编辑优势明显。三是数据闭环要求——需要把每个工具的测量值、通过/失败状态、图像路径写入数据库或回传给 PLC 时，SDK 提供的对象模型访问能力更直接。下表给出一个简明的对照，便于在项目初期快速定位。

接下来是作业与工具的组织。VisionPro 采用两级结构：Job（作业）是顶层容器，对应一次完整的检测任务，它管理图像源、工具集合、作业级输入输出以及运行时的触发与结果汇总；Tool（工具）是作业内的功能单元，例如 CogPMAlignTool（模板匹配定位）、CogBlobTool（斑点分析）、CogCaliperTool（卡尺测量）、CogFindLineTool（找线）等。工具之间存在明确的数据依赖：定位工具输出的位姿（Pose）通常作为后续测量工具的坐标系输入，因此工具在作业中的排列顺序本质上反映了数据流方向，而不是随意的列表。

一个稳健的组织习惯是：把作业划分为“定位—测量—判定”三个逻辑段。定位段放置模板匹配或找线工具，输出稳定的坐标系；测量段在该坐标系下执行卡尺、斑点、几何测量；判定段用表达式或脚本把多个测量结果与公差比较，输出统一的 Pass/Fail。这样组织的好处是，当产品换型时只需替换定位模板，测量工具因绑定在定位坐标系上而自动跟随，维护成本大幅降低。

图像源配置是作业能否稳定运行的前提。VisionPro 的图像源可以是相机（GigE Vision、USB3 Vision 等）、图像文件、图像数据库或内存中的 CogImage 对象。在 QuickBuild 中通过 Image Source 节点选择采集方式；在 SDK 中则通过 CogAcqFifoTool 或直接给作业的 Inputs 赋值。配置时需要关注几个关键点：触发模式（软触发/硬触发）、曝光与增益、像素格式（Mono8 还是 RGB24），以及是否需要在采集后立即做图像预处理。若使用文件回放做离线调试，应保证文件路径与产线实际图像的分辨率、位深一致，否则定位参数会失真。

集成项目初始化则把上述内容落到代码层面。一个典型的 SDK 初始化流程是：引用 VisionPro 程序集 → 创建 CogJob 或 CogJobManager → 加载 .vpp 作业 → 绑定图像源 → 注册运行完成事件 → 启动作业。下面是一段示意代码，参数为教学示例，实际项目中需按相机型号与作业路径替换。

using Cognex.VisionPro;
using Cognex.VisionPro.QuickBuild;

// 1. 加载已定型的作业
CogJob job = (CogJob)CogSerializer.LoadObjectFromFile(@"D:\Vision\Job\Detect.vpp");

// 2. 创建作业管理器并加入作业
CogJobManager jobManager = new CogJobManager();
jobManager.Jobs.Add(job);

// 3. 绑定图像源（示例：使用作业内已配置的采集工具）
//    若为文件回放，可在此处替换为 CogImageFileTool

// 4. 注册运行完成事件，读取结果
jobManager.UserData.SetValue("StationId", "ST-01");
jobManager.RunStatusChanged += (s, e) =>
{
    if (e.Status == CogJobManagerRunStatusConstants.Ready)
    {
        // 读取作业输出，例如定位得分与测量值
        double score = (double)job.Outputs["PMAlign1.Score"].Value;
        bool pass = (bool)job.Outputs["Inspection.Pass"].Value;
    }
};

// 5. 启动
jobManager.Start();

初始化阶段最容易出问题的地方有三处：一是作业路径与权限，产线电脑上 .vpp 文件若放在受保护目录，运行账户可能无读取权限；二是图像源未就绪，作业启动后第一次触发拿不到图像，导致首件误判，应在启动后等待采集工具进入就绪状态再放行；三是结果读取时机，必须在运行完成事件中读取输出，若在触发后立即读取，拿到的仍是上一次的结果。把这三条纳入初始化检查，可以避免大量现场“偶发误判”的排查时间。

把这张图与前面的说明对照，可以看到一条清晰的主线：图像源提供数据，作业容器按“定位—测量—判定”组织工具，作业管理器负责加载与运行，结果最终流向生产系统。QuickBuild 与 SDK 的选用，本质上是在这条主线的不同环节选择不同的操作方式——前者在作业编辑与调试环节效率更高，后者在加载、触发、结果回传环节更可控。集成项目初始化要做的，就是把这条主线在代码中稳定地建立起来，并用初始化检查清单守住那几个最容易出错的边界条件。