2. In-Sight软件环境与项目结构
在开始配置第一个视觉任务之前，必须先弄清楚 In-Sight 的软件环境由哪些部分组成、作业（Job）与任务（Task）之间是什么关系、以及这些内容最终以什么形式保存在相机或本地磁盘上。很多初学者在调试时反复"丢配置"或"找不到文件"，根源往往不是算法问题，而是对项目结构理解不清。
一、两代软件环境：In-Sight Explorer 与 In-Sight Vision Suite
In-Sight 的 PC 端配置软件经历了从 In-Sight Explorer 到 In-Sight Vision Suite 的演进。两者面向的相机固件版本不同，但核心概念一脉相承。
In-Sight Explorer 是较早期的集成环境，主要面向 In-Sight 5xxx、7xxx 等经典系列。它的界面由几个固定区域组成：左侧是 Application Steps（应用步骤） 面板，按"开始—图像—定位—检测—通信—结果"的顺序排列工具；中间是 Spreadsheet（电子表格） 视图，这是 In-Sight 最具特色的编程方式——每个单元格既可以放图像、也可以放函数、还可以放结果；右侧是 Palette（工具调色板） 与 Results（结果） 面板；底部是 Filmstrip（胶片条），用于回放已采集的图像序列。
In-Sight Vision Suite 是新一代平台，面向 In-Sight 2xxx、8xxx、D900 等新硬件，采用更现代的界面：顶部为功能区（Ribbon），左侧为 Job/Task 浏览器，中间为 Vision Viewer 与 Spreadsheet 双视图，右侧为 Properties（属性） 面板。它把"作业"和"任务"的概念显式地做成了树形结构，这也是本节要重点讲清的部分。
二、Job 与 Task：容器与执行单元的关系
这是最容易混淆的一对概念，可以用一句话概括：Job 是容器，Task 是容器里的执行单元。
一个 Job（作业） 对应相机内存中的一份完整配置，它包含：图像采集参数（触发方式、曝光、增益）、标定数据、Spreadsheet 逻辑、通信与 I/O 设置、以及一个或多个 Task。Job 是"保存/加载"的最小单位——当你点击 Save Job 时，保存的是整个 Job，而不是单个 Task。
一个 Task（任务） 是 Job 内部一次完整的"取像—处理—输出"流程。在 Vision Suite 中，一个 Job 可以包含多个 Task，例如：Task1 负责定位并输出坐标，Task2 负责字符识别，Task3 负责与 PLC 通信。多个 Task 可以共享同一份标定和同一路图像源，但各自拥有独立的触发条件与结果输出。这样设计的好处是：当产线需要增加一项检测时，不必推翻整个 Job，只需新增一个 Task。
需要特别注意的是：Task 不能脱离 Job 单独存在。删除 Job 会连带删除其下所有 Task；而删除某个 Task 不影响同 Job 内的其他 Task。理解这一点，就能解释为什么"只改了 Task 却要保存整个 Job"。
三、文件存储结构：Job 到底存在哪里
In-Sight 的 Job 文件以 .job 为扩展名，本质是一个包含图像、标定、Spreadsheet 逻辑和通信配置的复合文件。它有两个存放位置：
- 相机内存：相机内部有非易失存储区，通常可保存多个 Job。通过 Sensor → Job → Load/Save 可以在相机内存与 PC 之间搬运。相机断电后内存中的 Job 不会丢失，但固件升级可能要求重新加载。
- 本地磁盘：在 In-Sight Explorer 中，Job 默认保存在
C:\Users\Public\Documents\In-Sight\Jobs\或用户指定目录；Vision Suite 则默认在D:\In-Sight\Jobs\下按项目名建子文件夹。建议按"产线—工位—版本"三级目录管理，例如D:\Jobs\LineA\Station3\V2.1.job。
除了 .job 主文件，实际项目中还会产生几类配套文件：标定文件（.cal）、参考图像（.bmp 或 .png）、以及日志文件（.log）。这些文件不嵌入 Job，而是以相对路径引用。因此拷贝 Job 时必须连同配套文件一起拷贝，否则加载后会出现"标定丢失"或"参考图找不到"的报错。
.job 文件复制到另一台电脑，结果打开后标定数据为空、参考图显示为红色叉号。正确做法是使用软件自带的 Export Job 功能打包导出，或手动复制整个项目文件夹。四、版本管理的基本约定
由于 Job 是二进制复合文件，无法像文本代码那样做逐行 diff。实际项目中推荐以下约定：
| 管理项 | 推荐做法 | 示例 |
|---|---|---|
| 命名规则 | 产线_工位_日期_版本 | LineA_ST3_20250612_V2.1.job |
| 版本递增 | 小改 +0.1，大改 +1.0 | V2.0 → V2.1 → V3.0 |
| 备份频率 | 每次现场调试后立即导出 | 导出到 NAS 或 Git LFS |
| 变更记录 | 同目录放 README.txt | 记录改了什么、为什么改 |
如果团队使用 Git 管理，建议只把 .job 和配套文件放入仓库，并配合 .gitattributes 标记为二进制，避免自动合并导致文件损坏。每次提交时在 commit message 中写清"改了哪个 Task、调整了什么参数、验证结果如何"，这样即使无法 diff 文件内容，也能通过提交历史追溯变更。
理解 Job 与 Task 的容器关系、以及 Job 文件的存储与引用方式，是后续所有配置操作的基础。当你能清楚地回答"这个设置属于 Job 还是 Task""这个文件存在相机还是 PC"这两个问题时，调试效率会明显提升。