1. 课程导入与协同架构总览

在智能制造与柔性产线中，机器视觉负责“看”，PLC 负责“动”，而真正决定产线节拍与稳定性的，往往是两者之间的协同效率。传统方案里，视觉系统通常由工控机加独立视觉软件完成，检测结果通过 I/O 硬线、串口或私有协议交给 PLC，PLC 再驱动气缸、伺服、机器人执行分拣或定位补偿。这种结构能跑通，但存在明显短板：视觉与控制的时钟不同步、结果传递延迟不可控、参数修改要停机、诊断信息分散在两套系统里。PLCnext 平台的价值，正是把“视觉决策”和“实时控制”放进同一个工程化框架中，让数据流、时间基准和诊断信息统一起来。

PLCnext 是菲尼克斯电气推出的开放式自动化平台。它并非简单的“PLC 加几个网口”，而是在实时控制内核之上，允许并行运行 Linux 侧的应用程序、容器、高级语言程序（如 C++、Python）以及 IEC 61131-3 标准程序。对机器视觉协同而言，这意味着三件事：第一，视觉算法或视觉结果处理可以直接在控制器内完成，减少一层工控机与通信环节；第二，PLC 程序与视觉程序可以通过共享内存、OPC UA、Profinet、TCP/IP 等多种方式交换数据，且交换周期可配置；第三，所有数据都能进入统一的变量空间，便于 HMI、SCADA 和上层 MES 读取。理解这一点，是理解后续所有协同模式的基础。

机器视觉与 PLC 协同的典型场景，可以按“视觉输出什么”来划分。最常见的是结果型协同：视觉输出 OK/NG、坐标偏移量、角度偏差、字符识别结果等离散或小数据量信息，PLC 根据这些结果执行分拣、剔除、贴标或纠偏。第二类是参数型协同：PLC 根据配方或产品型号，向视觉系统下发曝光时间、ROI 区域、模板编号、阈值等参数，视觉系统切换检测方案。第三类是触发型协同：PLC 在工件到达工位的精确时刻发出硬触发或软触发信号，视觉系统在指定延时后采图，保证每次拍摄位置一致。第四类是状态型协同：视觉系统把相机温度、帧率、丢帧计数、光源亮度、算法耗时等健康状态上报给 PLC，PLC 据此判断是否降速或报警。这四类场景往往同时存在，只是侧重点不同。

从系统组成看，一个典型的 PLCnext 视觉协同工位包含以下对象：PLCnext 控制器（如 AXC F 2152 或 AXC F 3152）、工业相机（GigE Vision 或 USB3 Vision）、光源与光源控制器、视觉处理程序（可运行在控制器 Linux 侧或外部工控机）、执行机构（气缸、伺服、机器人）、传感器（接近开关、编码器）、HMI 以及交换机。它们之间的连接关系和数据流向，是本节最需要建立的整体图景。下图给出了一种典型的协同架构：相机采集图像，视觉程序输出结果，PLCnext 控制器内的实时程序读取结果并驱动执行机构，同时把状态写入统一变量空间供 HMI 和上层系统使用。

理解这张架构图后，需要进一步明确数据流中的时间关系。视觉协同最怕“结果来晚了”。假设产线节拍为 60 件/分钟，即每件 1000 ms，其中留给视觉检测和 PLC 反应的时间可能只有 300 ms。如果相机曝光 5 ms、图像传输 20 ms、算法处理 80 ms、结果通信 10 ms、PLC 扫描周期 4 ms，那么从触发到执行机构动作的总延迟约为 119 ms，看起来充裕。但若算法处理时间波动到 200 ms，或者通信采用非实时 TCP 且遇到重传，延迟就可能突破 300 ms，导致漏抓或错抓。因此，在方案设计阶段就要把各环节耗时列出来，并留出至少 30% 的余量。PLCnext 的优势在于，视觉程序与 PLC 程序可以运行在同一硬件内，通过共享内存交换数据时，延迟可压缩到微秒级，且不受外部网络抖动影响。

对于初学者，建议按以下路径逐步深入。第一步，先建立“触发—采图—处理—输出—执行”的完整链路概念，能画出自己工位的信号流图。第二步，掌握 PLCnext 的基本工程结构，包括实时程序、Linux 应用和变量空间的关系，知道视觉结果以什么变量类型、什么方向传递。第三步，动手实现最简单的结果型协同：用一个布尔量表示 OK/NG，PLC 读取后驱动一个气缸。第四步，加入参数型协同，让 PLC 根据配方号向视觉程序写入模板编号和曝光时间。第五步，引入状态监控和异常处理，例如视觉超时、丢帧、结果置信度低时，PLC 如何降级运行或报警。第六步，再考虑多相机、多工位和与 MES 的数据追溯。这个顺序不是固定的，但符合“先通链路、再调参数、后做优化”的工程习惯。