机器视觉产线相机到PLC链路部署与接线实操指南

做机器视觉产线改造的朋友，迟早会撞上这么一堵墙：相机、光源、嵌入式工控机、PLC 各自买回来都能转，但要让它们在一台整机设备里协同工作，信号不乱、时序不错、通信不丢，才是真正考验功力的事。

这篇文章把我这几年在产线上部署“相机到 PLC 整套链路”的方案、接线方式、通信协议和踩过的坑一次性讲清楚。典型场景是：流水线上来一个工件，传感器检测到，PLC 给相机一个触发信号，相机拍照，图像传给嵌入式工控机，视觉软件判 OK 还是 NG，再把结果送回 PLC，PLC 控制气缸把不良品剔除。整个闭环看起来简单，实际部署时每一步都有细节。适合刚接触机器视觉项目的应用工程师、设备集成商，也适合准备往工业视觉方向转的嵌入式开发人员参考。

1. 项目拆解：这条链路到底在解决什么问题

1.1 一个真实的产线场景

以我之前做过的一个手机中框螺丝孔检测项目为例。产线节拍是 3 秒一件，三种型号混线生产，需要检测每个中框上 12 颗螺丝是否锁付到位、有无滑牙漏锁。现场设备：基恩士光电传感器、一台嵌入式工控机、一台黑白工业相机、一组环形光源，以及负责剔除动作的 PLC。

整个动作顺序是这样的：工件沿传送带进入检测工位，光电传感器亮一下，信号进 PLC。PLC 输出一个 24V 脉冲给相机的 IO 触发口，相机曝光拍照，图像通过网线传给工控机。工控机上跑的视觉软件在几百毫秒内完成位置查找、螺丝定位、特征比对，得出 OK/NG 结果。随后工控机通过网口把结果写到 PLC 指定的数据寄存器里，同时拉高一路 IO 信号，PLC 收到后根据结果决定让工件继续流走还是启动气缸剔除。一个循环完成。

这里有两个数据流同时存在。一个是图像流：相机到工控机，特点是数据量大、要求带宽稳定、不能丢包。另一个是控制流：传感器到 PLC、PLC 到相机、工控机到 PLC，特点是数据量小但实时性极高，毫秒级延迟都可能导致误判。部署链路的核心任务，就是让这两条数据流各走各路、互不干扰，同时在时间上严格对齐。

1.2 为什么要把嵌入式工控机放在链路中间

有人问为什么不直接用智能相机，或者干脆用普通电脑。智能相机（一体机）虽然集成了镜头、光源控制和处理单元，但算法扩展性有限，遇到需要深度学习、多相机协同或者频繁换型的需求就很吃力。普通 PC 在产线环境里问题更多：散热风扇进灰、机械硬盘震动坏道、接口松动、系统蓝屏，都是常见故障。

嵌入式工控机在这条链路里的定位是“计算节点 + 通信中枢”。它无风扇、宽温设计、抗震动，适合嵌在设备内部长期运行。更重要的是它的接口配置：多个千兆网口接相机、串口接扫码枪、隔离数字量 IO 接外部信号、PCIe 插槽可以扩展运动控制卡或高速采集卡。一台机器把视觉计算和各种外设的通信都包了，比起分散部署几台设备，维护成本和故障点都少很多。

1.3 适合谁来读这套方案

这套部署方案适合三类人。第一类是机器视觉应用工程师，平时用 VisionPro、Halcon、OpenCV 做算法，但不太清楚相机触发、IO 接线、PLC 通信这些底层衔接。第二类是电气工程师，熟悉 PLC 编程和接线，但对相机 SDK、IP 配置、协议栈比较陌生。第三类是嵌入式开发工程师，想做视觉方向的 Linux/Qt 应用，需要理解整个系统的数据流和控制流是怎么组织的。

2. 硬件选型：从相机到 PLC 每一步都不能将就

2.1 工业相机怎么选

相机选型决定了整个视觉系统的上限。我一般按四个维度去卡：像素分辨率、帧率、靶面尺寸、接口类型。

分辨率由检测精度和视野大小决定。比如视野要看到 200mm×150mm 的区域，精度要求 0.1mm，那么横向至少需要 200/0.1=2000 个像素，再留 2 到 3 倍的余量用于算法稳定性和覆盖偏差，实际选型就会落在 500 万到 600 万像素左右。如果精度要求 0.05mm，那就直接奔 1200 万像素去。

传感器类型要看被测物是否运动。静止拍照（工件到位停住）可以用卷帘快门 CMOS，成本低；运动拍照（飞拍）必须用全局快门，否则图像会果冻变形。

接口类型是容易被忽略但实际影响很大的选择：

我自己做通用产线项目时，90% 的情况会选 GigE 接口的黑白面阵相机，全局快门，500 万到 1200 万像素。原因很实在：网线便宜，交换机可选范围大，工控机自带网口就能用，调试时用一根网线连笔记本电脑也能临时顶上。而且 GigE Vision 协议在丢包重传、多相机同步方面有标准方案，稳。

2.2 镜头、光源与控制器配套

镜头选型核心是和相机靶面匹配。镜头的像面尺寸要大于等于相机靶面对角线，否则边缘会发暗或模糊。焦距方面，先量好工作距离和视野大小，再用公式 f = 工作距离 × 靶面宽度 / 视野宽度 算一个初始值，最后用变焦或定焦镜头实测微调。

光源更影响检测稳定性。表面缺陷检测一般用环形光或条形低角度光，字符识别用同轴光，轮廓尺寸测量用背光。光源控制器尽量选带频闪模式（strobe）的型号，让光源只在相机曝光期间点亮，能显著延长 LED 寿命，也减少环境光影响。频闪信号可以直接由工控机 IO 或相机闪光输出口控制，这一点在接线设计时要提前规划，不然后期想加频闪却发现没有控制线，就得返工。

2.3 嵌入式工控机的配置怎么定

工控机的配置不是越高越好，而是按链路需求倒推。三个影响配置的因素：相机数量和分辨率、算法复杂度、外设接口需求。

以一个 500 万像素 GigE 相机的项目为例：图像原始数据约 5MB 一帧，做螺丝检测这种中等复杂度算法，处理时间要求 500ms 内完成。CPU 用 Intel 赛扬 J6412 或酷睿 i3-1115G4 级别绰绰有余，配 8GB 内存，系统盘 256GB SSD。如果后续要上深度学习模型，比如做表面划伤检测，那就得换 i7 或更高，内存 16GB 起，最好再加一块 NVIDIA 显卡或 Intel 神经计算棒，因为纯 CPU 跑 CNN 推理很难满足产线节拍。

接口一定要数清楚。至少两个千兆网口：一个接相机，一个接 PLC 或上层 MES 系统，避免图像数据和协议数据抢带宽。RS232/RS485 串口至少两个，用于接扫码枪、称重仪表或者老式 PLC。数字量 IO 至少 4 进 4 出，用于触发信号采集和结果输出。PCIe 插槽留一两个做扩展备用。

系统选择方面，如果团队熟悉 Windows 生态，用 Win10/11 IoT Enterprise LTSC，相机 SDK、视觉库兼容性最好。如果追求长期稳定和免授权，用嵌入式 Linux 配 Qt 做上位机界面，算法用 OpenCV 或 C++ 库。这么说吧：你有多大的 Linux 驱动和网络调试能力，决定了你能不能把 Linux 方案用好；否则 Windows 是最稳妥的。

2.4 PLC 侧预留接口

PLC 侧要确认三件事：CPU 上有没有以太网口、串口是否空闲、数字量 IO 模块有没有多余的输入输出点。现在主流的西门子 S7-1200/1500、三菱 FX5U/Q 系列、台达 DVP 系列都标配以太网口，走 Modbus TCP 或者西门子 S7 协议都很方便。老设备如果只有串口，就走 RS485 加 Modbus RTU，速度慢一点但稳定。IO 点至少留 1 个输出给相机触发、1 个输入收工控机结果、1 个输入收工控机“读取完成”的应答，这是最低配。

我遇到过一种尴尬情况：PLC 的以太网口被触摸屏占用，没有交换机，结果只能让工控机再插一块网卡，物理直连 PLC 的编程口，同时把触摸屏挪到另外一个网段。所以在项目启动前，一定先画清楚 PLC、HMI、工控机、相机的 IP 和物理连接拓扑，别等设备都到现场了才设计网络。

3. 物理连接与接线：链路稳定性的第一道关

3.1 相机到工控机：网络连接与 IP 规划

GigE 相机和工控机之间最简单的方式是网线直连，不经过交换机。相机出厂 IP 一般是 192.168.1.101 这类固定地址，把工控机对应网卡改成同网段就行。比如相机是 192.168.1.101，工控机网卡就设 192.168.1.10，子网掩码 255.255.255.0。注意工控机有两个网口时，一定要在操作系统里把网卡重命名，比如“CAM1”“PLC1”，否则调试时搞不清哪个口对应哪台设备，非常容易混乱。

千兆网的设置上，建议在网络适配器高级属性里把网卡双工模式强制为 1.0Gbps 全双工，禁止自动协商。自动协商有时候会在现场电磁干扰下回退到百兆模式，帧率直接掉一倍并且毫无征兆。另一个关键设置是开启 Jumbo Frame（巨帧），也就是把 MTU 调到 9000 字节左右。GigE Vision 是面向数据报传输的，图像数据会被拆分到多个包，巨帧能减少拆包数量，降低 CPU 占用和丢包概率。这一项对高分辨率相机尤其有用。

相机供电有两种方式：支持 PoE（Power over Ethernet）的相机，只需要一根网线同时解决供电和传输，接线最少；不支持 PoE 的，相机需要独立 12V 电源，电源线建议用带屏蔽的双芯线，和网线分开走，避免电源纹波干扰图像信号。

3.2 硬触发接线：传感器、PLC 与相机 IO 之间

相机触发有三种方式：软触发（软件指令触发）、硬触发（外部 IO 触发）、连续采集（free run）。产线场景，我强烈建议用硬触发，特别是节拍稳定、工件位置由传感器确定的场合。硬触发的核心优势是时间确定性高，微秒级响应，不受工控机系统负载和调度延迟影响。

硬触发的信号路径有两种方案。第一种是传感器信号直接进 PLC，PLC 再输出一路给相机 IO。这种方案的好处是 PLC 可以做逻辑判断，比如传感器亮但机械手还没到位时不让相机拍照；坏处是多了一道 PLC 扫描周期延迟，对 PLC 型号而言一般是几毫秒到十几毫秒，静态拍照一般没问题。第二种是传感器信号分一路直接给相机 IO，图像采集完全不经过 PLC，PLC 只负责收结果。这种方案最快，但需要传感器输出信号电平与相机 IO 匹配，还要加中间继电器或光耦隔离。

接线时最核心的问题：NPN 和 PNP 要分清。NPN 传感器输出低电平信号（负载接正极），PNP 传感器输出高电平信号（负载接负极）。海康、Basler 的 IO 输入端口普遍支持光耦隔离，既可以接 NPN 也可以接 PNP，但接法不同：正负极接线要按说明书接，接反了信号检测不到，运气差还会烧输入端。我用过一个口诀：先确认传感器的输出类型，再查相机 IO 手册里对应的公共端极性，最后用万用表量一下无信号时和触发时引脚电平变化，确认逻辑正确再接到相机上，别上来就凭感觉插线。

3.3 工控机输出结果到 PLC：IO 方式最实在

工控机把检测结果告诉 PLC，有 IO、串口、网口三种路径。我按可靠性排序，IO 最高，其次网口协议，再次串口。原因很简单：IO 信号是硬件电平，不存在协议解析失败的问题，延迟几乎可以忽略。具体实现上，用工控机自带的隔离数字量输出，或者扩展一张 PCIe GPIO 卡。结果输出一般用两路：一路 OK，一路 NG。PLC 的输入模块接收到电平后，通过上升沿或电平保持判断当前结果。

IO 接线要注意电平转换和公共端。工控机卡的 DO 输出如果是 NPN 型，输出低电平有效，PLC 输入侧公共端就要接正极；如果工控机卡是 PNP 型，输出高电平有效，PLC 输入侧公共端就要接负极。这块特别容易出错，我曾经因为工控机卡的输出类型和 PLC 输入公共端不匹配，烧坏了一个输入模块的通道，教训惨痛。确认方法很简单：看硬件说明书上的等效电路图，确认输出管是 NPN 还是 PNP，然后按图接公共端。宁可多花十分钟读手册，不然后面排查信号不稳定要花整整一天。

3.4 接地与线缆布线的几个规矩

工业现场干扰是链路不稳定的头号元凶，表现是图像偶尔花屏、通信偶发超时、IO 误触发。我的经验是，接地和布线做好了，这些问题能消掉八成。

首先，工控机外壳、相机外壳、光源控制器外壳都要接大地（PE）。机壳接地可以让高频干扰泄放到地，但注意是单端接地：信号线的屏蔽层只在 PLC 那端或者工控机那端接地，不要两端同时接，否则会形成接地环路，产生更严重的干扰电流。

其次，信号线和动力线必须分开走线。220V 或者伺服电机驱动线电流变化大，会产生强电磁场，即使隔 20 厘米也可能耦合到未屏蔽的信号线上。我的做法是信号线全部用屏蔽双绞线，并且走独立的线槽，和动力线至少保持 30 厘米以上距离。交叉处必须垂直相交，不能平行走。

第三，IO 线尽量短。相机触发线控制在 3 米以内，如果超过，改用带屏蔽的专用线并考虑加光电耦合器放大信号。我见过一个项目把触发线走了 10 多米，结果相机触发信号衰减导致偶发漏拍，最后改成 PLC 本地输出继电器转接才解决。

4. 通信协议与软件配置：让设备“说同一种语言”

4.1 相机侧配置：从 IP 到触发模式

拿到相机后，先在 Windows 上装官方 SDK。海康机器视觉相机用 MVS（Machine Vision Software），Basler 用 pylon Viewer。装好后第一步是改 IP。以海康为例：打开 MVS，进入设备管理，选中相机，右键修改 IP，改成你规划的地址，比如 192.168.1.101。如果搜不到相机，先用 SDK 自带的 IP 配置工具强制设一个和相机同网段的 IP，再回去刷新。

第二部是设置触发源。在海康 MVS 里，设置 → 采集控制 → 触发选择，帧触发。触发源选择 Line0（一般是外部 IO 输入口），触发模式选上升沿或下降沿，根据接线逻辑确定。同时把触发超时设成 1 到 2 秒，防止现场触发信号异常时相机进入死等状态。Basler pylon 的设置逻辑类似，触发模式（Trigger Mode）开、触发源（Trigger Source）选 Line1，然后设置触发激活方式。

第三是设置曝光时间和帧率。曝光时间由现场光照和工件运动速度决定。静止拍照，曝光 500 微秒到 2 毫秒都常见；运动拍照，曝光时间要短到能冻结运动模糊，一般不超过 200 微秒，同时光源要给足。这一项要配合光源控制器一起调，不是单独定死的。

4.2 工控机到 PLC 的通信方案：Modbus TCP 是最快路径

工控机和 PLC 通信，我最常用 Modbus TCP，理由有三：几乎所有带网口的 PLC 都支持或者能用程序实现 Modbus TCP；协议简单，报文内容肉眼可读，排错方便；工控机端无论是用 C#、C++、Python 都有成熟的库，几行代码就能跑通。

Modbus TCP 采用主从模型：工控机当主站（Client），PLC 当从站（Server）。PLC 侧要做的，是建立 Modbus TCP 服务器并开放一个保持寄存器区。工控机侧周期性写结果。以台达 DVP 系列为例，通过 ISPSoft 组态，以太网模块设置端口号默认 502，寄存器地址从 40001 开始映射。工控机写 40001 这个地址，PLC 里就对应 D0。

寄存器怎么规划很重要。我的习惯是最少定义五个：

握手信号的设计在第 4.4 节详细讲。这里先强调一个常见坑：不同厂商对 Modbus 地址的表示方式不一致。台达、西门子、三菱对寄存器定义不同，有的从 0 开始，有的从 1 开始，有的显示为 40001 实际报文里是 0。写程序的时候，一定要先确认上位机库函数的地址是“0 起始”还是“1 起始”，用 Modbus Poll 这类工具先测试读写，确认能读到数据再写进正式程序里。别问我怎么知道的，我在现场用错了地址，对着一堆“通信异常”查了三个小时，最后发现是地址偏移一位。

4.3 西门子、三菱、基恩士等各家 PLC 怎么对接

如果是西门子 S7-1200/1500，最直接的是用 S7 协议通信，工控机端用 Snap7 这个开源库，不需要在 PLC 侧做任何 Modbus 配置，直接读写 DB 块。Snap7 的读写速度比 Modbus TCP 更快，因为协议开销小。但要注意 S7 协议要开放 PLC 的 PUT/GET 访问权限，在博途的防护设置里把“允许来自远程对象的 PUT/GET 通信访问”勾上。遇到过客户担心安全问题不让开 PUT/GET，那就退回 Modbus TCP 方案，用博途自带的 Modbus TCP 库（MB_CLIENT）组态。

三菱 PLC 走 MC 协议，Ethernet 模块支持，工控机端用 TCP 直接发 MC 协议的二进制帧。相比 Modbus，MC 协议的报文稍微复杂，但三菱老用户用得顺手。基恩士 PLC 很多型号只支持自家的 KV 协议和 EtherNet/IP，其中 EtherNet/IP 是一个工业以太网协议，工控机端要装支持 CIP 的库，会复杂一些。总体原则就一句话：小项目直接选 Modbus TCP 或 S7 协议，别为了用某个高级协议给自己找麻烦。

4.4 握手与超时机制：避免漏判和误判

这一节是通信逻辑设计里最容易被忽视但最重要的。如果工控机和 PLC 之间只单向发结果，没有任何握手，实际运行一定出问题。典型的场景：工控机在处理图像的同时，PLC 又来了下一颗料，结果工控机把上一次的 NG 结果写到 PLC 里，PLC 再结合新料号做出错误判断，产生批量误判。

握手逻辑是这样的：PLC 先给工控机写“触发请求”（寄存器 40004=1，代表工件已到位准备检测）。工控机收到请求后开始采集和处理，处理完成后把结果写到寄存器 40001，再把寄存器 40002 填上当前工件流水号，然后把 40001 置为有效。PLC 轮询到 40001 被更新后，读回结果，业务处理完成，再写 40004=0，表示当前循环结束。工控机看到 40004=0 就知道 PLC 已经消费完结果，可以接受下一个请求。这样每个结果都有明确的确认过程，不会因为时序错乱导致误判。

超时机制也要写死在程序里。工控机收到触发请求后，如果 3 秒内没有完成检测，要主动向 PLC 写一个“检测超时”的状态位，PLC 收到后走异常处理流程。PLC 如果发出请求后 5 秒内没有收到结果，也要报警停机，不要无限等待。我见过有设备因为缺了超时机制，一次相机掉线导致整条线卡死，操作工谁都没发现，直到堆料堆到冒烟。

5. 联调流程与常见问题排查实录

5.1 联调步骤：从单模块到全链路

分享一套我实际用的联调顺序，按这个顺序走，出了问题能快速定位到哪一环：

第一步：相机单机测试。只连相机和工控机，用 SDK 软件软触发拍照，确认图像清晰、曝光合适、视野和目标匹配。

第二步：软触发跑通后，测硬触发。用一根导线短接相机的触发输入（模拟 IO 信号），看相机是否能在导线短接的瞬间采集一帧。这一步验证相机 IO 配置正确。

第三步：接入真实传感器或 PLC 触发信号。接好线后，用 PLC 手动强制输出一个脉冲，看相机是否触发了。同时用万用表在相机触发引脚量电压，确认信号确实到了。

第四步：视觉算法独立测试。用已经拍好的测试图片，在工控机上跑算法，批量验证 OK/NG 判断准确率。不要把算法调试和链路调试混在一起，否则问题定位会非常痛苦。

第五步：工控机到 PLC 的通信测试。用 Modbus Poll 或自己写的小工具，先手动读写几个寄存器，确认地址和数据类型都正确。然后打通握手流程，工控机写结果、PLC 读取并应答。

第六步：全链路时序测试。传感器实际触发，PLC→相机→工控机→算法→结果→PLC →剔除执行，完整走一遍。用示波器或者逻辑分析仪抓几个关键信号的电平变化，确认整个过程的时序严格符合预期。

第七步：连续运行老化。按产线节拍连续跑至少 2 小时，重点看通信是否偶发中断、相机是否偶发漏拍、工控机内存是否持续增长。我习惯同时在工控机上写一个计数器日志，记录触发次数、拍照次数、结果输出次数、PLC 应答次数，四者必须一致。

5.2 高频问题排查速查表

5.3 单机时间不准确的处理方案

热词里有人专门提到“没有联网的工控机（单机）时间不准确怎么处理”，这确实是个非常现实的坑。产线上的工控机一般不连外网，很多还不会配置局域网 NTP 服务器，时间就会慢慢漂。结果就是：相机拍的照片文件名时间戳不对，追溯系统查不到记录；MES 系统比对超时；甚至有些软件授权因为时间校验失败直接罢工。

处理办法有三层。最基础的是检查主板上的纽扣电池（CR2032），电量不足就换掉，保证关机不丢时间。第二层是在局域网里找一台稳定的设备当 NTP 服务器，最方便的是用 PLC 的以太网口或路由器充当，或者直接在工控机上装一个 NTP 服务，其它设备从它校时。第三层是让工控机每次启动时通过 PLC 读取一个心跳计时，写一个简单的校时功能。总之，时间同步看起来是小事，但是追溯系统的命根子，一定要在联调阶段就纳入测试范围，别等客户查批次记录的时候才发现图片时间对不上。

5.4 排查工具清单

调试链路，物理层、网络层、应用层都要有工具。

万用表必备，量电压、查通断。网线测试仪也必备，产线上上百根网线，线序错、接触不良的问题太多了。Wireshark 是网络排查神器，能看 TCP 握手是否成功、Modbus 报文内容对不对、有没有大量重传包。Modbus Poll 是验证 PLC 寄存器读写最方便的工具，不用写代码就能手动读写任意寄存器。各个相机 SDK 自带的诊断工具，比如海康 MVS 里能看相机温度、帧率、丢包计数，Basler pylon 也有类似功能。还有一个小工具建议常备：一个带 LED 显示的 IO 信号测试盒，能直观看到 IO 信号有没有到达，省得拿万用表一根根点。

工控机上建议做一个简单的实时状态面板，显示四个状态灯：相机连接状态、触发计数、最近一次检测结果、PLC 握手状态。这面板不需要多华丽，Qt 或者 C# 写个窗口就行，但它能让维护人员一眼看出问题出在链路前段、中段还是后段，省掉大量盲目排查时间。

写在最后

整套链路说到底，就是“信号怎么进、图像怎么传、结果怎么出”三件事。每件事都不难，但工业现场最怕的就是每一环都差一点点，累积起来变成莫名其妙的偶发故障。我个人在做这类视觉项目时都会严格按联调流程来，每验证完一个环节就在文档里打个勾，全链路通了再让设备上线。这套笨办法看上去慢，实际上是最快的路，因为出了问题你永远知道去哪里查。

最后再分享一个小习惯：所有 IO 接线、IP 地址、寄存器映射表，一定画成一张 A4 纸的连线图贴在机柜门上。半年后设备出问题，接线的人可能已经离职了，但图纸还在，维护人员就不会两眼一抹黑。视觉项目交付不是代码跑通了就算完，能让客户自己稳定维护，才是一个项目真正落地。