企业官网建设流程全解析

先讲一个我亲眼见过的场景：一条汽车零部件装配线，视觉检测工位配好了海康500万像素工业相机，工控机里检测算法也调得能跑了，PLC程序更是早早就写好了，结果联调第一天就翻车——相机偶尔收不到触发信号，PLC又时不时漏掉NG报文，调试工程师在电柜前蹲了两天，最后发现是触发线缆跟电机动力线走了同一个线槽，55kW变频器一加负载，整个IO信号全被干扰了。

这就是典型的“只看单机、不看链路”的代价。机器视觉产线部署，尤其是相机到PLC这整套链路，立项时第一件事不是选相机，也不是调算法，而是把整条链路上的每一个节点、每一根线、每一个协议都想清楚。这篇文章我结合这些年做视觉项目的实际经验，从硬件选型、触发接线、软件配置、通信协议、联调避坑五个层面，把这条链路完整拆一遍。不管你是刚入行的机器视觉工程师，还是做PLC集成的老电气工程师，读完应该能少走几次我走过的弯路。

1. 先看清这条链路的全貌：谁在发令，谁在干活

1.1 三段式链路：取像、处理、执行

整条“相机到PLC”的链路，摊开了其实就是三段：取像段、处理段、执行段。

取像段负责把物理世界变成图像，成员包括工业相机、镜头、光源和触发传感器。处理段是嵌入式工控机上跑的视觉软件，它接收图像、跑算法、输出判定结果。执行段是PLC以及它背后拖动的气缸、电机、机械手，它接收结果并完成分拣、剔除或定位动作。

三段之间靠两种信号衔接：一种是图像数据流，从相机通过GigE或USB3.0接口进工控机；另一种是控制信号流，包括传感器发给相机的触发信号，以及工控机发给PLC的结果信号。很多新手部署时只盯着图像数据怎么传，忽略了触发和结果反馈的时序要求，结果一上产线就出各种灵异问题——其实根本不是什么玄学，是两股信号的时序没理清楚。

1.2 触发链路的时序：传感器、相机与PLC的分工

这条链路的“发令枪”通常不是相机，而是产线上的传感器。一个漫反射光电开关检测到工件到位，输出一个脉冲给相机的Line0触发端口，相机收到脉冲后开始曝光采集，图像通过网线进入工控机，视觉程序跑完得到OK或NG判定，结果再通过数字量输出口或以太网报文发给PLC，PLC收到后驱动气缸完成分拣。

这里面的时序关系是整条链路的灵魂。传感器触发、相机曝光、图像传输、算法处理、结果下发，每一段都有延迟，所有延迟加起来必须小于产线的节拍周期。我见过一个项目，算法在工控机上跑得飞快，单帧只要20毫秒，但产线节拍是10秒一个工件，本来毫无压力；结果实际部署时发现每次触发后相机要等50毫秒才出图，再传图又花了30毫秒，工控机那边再处理20毫秒，一个周期100毫秒看起来也不多，可PLC那边还要求结果必须在工件离开检测位之前返回，而这个窗口只有80毫秒，于是偶尔就会漏判。后来把相机曝光参数和取流方式调优，才把整段压缩到60毫秒以内。这种问题，不在链路层面算一遍时序，是根本发现不了的。

2. 硬件选型：链路稳不稳，选型时就决定了

2.1 嵌入式工控机怎么选：双网口和无风扇是底线

产线用的嵌入式工控机，我现在的选型标准很固定：无风扇、双千兆网口、SSD存储、宽温设计，CPU根据算法复杂度从i5到i7，如果上深度学习就得考虑带GPU或者NPU的型号。

为什么双网口是底线？因为一条链路里至少有两个网络：相机所在的视觉网络，和PLC所在的控制网络。两个网络最好物理隔离。我习惯把网口0接相机，网口1接PLC或者接工厂局域网，IP段也完全分开。这样相机的大流量广播和PLC的实时报文互不干扰，排查问题的时候也清爽：Ping不通PLC就去查网口1的线，相机掉线就去查网口0的线，不会麻绳缠脚。

无风扇设计看着不起眼，实际在产线里特别重要。电柜里灰尘大、温度高，有风扇的机器用一年风扇就堵死了，轻则CPU降频掉帧，重则直接过热关机。工控机最好选支持DIN导轨安装的，直接卡在电柜里，比平放节省空间，也方便固定。存储这块别省钱，必须用工业级SSD，产线设备频繁断电，机械硬盘在这种场景里寿命很玄学。

2.2 工业相机、镜头与光源的匹配

相机选型要确定的参数很多，但产线视觉检测最关键的其实是三件事：分辨率够不够、能不能硬触发、用什么接口传输。

分辨率跟精度的关系很简单粗暴：精度约等于视野除以分辨率。比如你的视野是100mm宽，相机是500万像素（约2592×1944），那每个像素对应的物理尺寸大约是0.038mm，一般取3到5个像素作为稳定检测的精度下限，也就是能稳定保证约0.1mm的检测精度。如果你要求0.01mm的精度，那这个组合就不够，得上千万像素或者缩小视野。

接口方面，产线我首选GigE Vision接口的相机。一根网线最长能拉100米，还能通过PoE供电，组多相机系统也方便。USB3.0虽然带宽高，但线缆超过5米就容易出问题，产线电柜里相机和工控机隔个十几米是常事，USB3.0在这时候就很尴尬。

镜头和光源的选择往往被低估。镜头的焦距要根据工作距离和视野来算，公式是焦距等于工作距离乘以传感器靶面宽度除以视野宽度。光源的选择要看检测目标，打光的目的不是“照亮”，而是“制造对比度”。表面缺陷检测常用环形光，轮廓尺寸测量常用背光，字符识别用条形光配合暗场，光源颜色也要配合被测物和背景，比如检测金属表面拉丝，蓝光往往比白光更能凸显纹理差异。光源选错了，算法怎么调都白搭。

2.3 PLC侧的准备：端口、IP与IO点

PLC侧的准备工作贯穿整个选型阶段。首先确认PLC支持哪种以太网通信协议，这决定了工控机怎么跟它说话。西门子S7-1200/1500支持S7协议，三菱FX5U/ iQ-R系列支持MC协议，台达、欧姆龙、施耐德这些绝大多数支持ModbusTCP。如果手里是一台老掉牙的、只有串口的PLC，那就需要考虑加装以太网模块，或者直接用ModbusRTU走串口——但串口通信速率低、距离短，能用以太网尽量以太网。

除了通信协议，还要预留物理IO点。很多时候结果下发会直接用硬接线，也就是工控机数字量输出OK、NG信号给PLC输入点，速度比协议传输快，也不依赖网络状态。这时候PLC侧至少要有2个输入点用来接OK和NG，再加一个输入点接触发信号或心跳信号。PLC的IP地址、端口号也要提前规划好，比如西门子S7-1200以太网的默认端口是102，ModbusTCP默认端口是502，这些在配置通信参数时一个都不能错。

3. 软件与协议配置：把工控机变成产线的一部分

3.1 相机SDK与视觉开发环境的搭建

相机驱动的安装没什么好说的，海康用MVS、Basler用pylon，一路下一步就行。但有几个细节值得提前处理：一是相机SDK的安装目录不要带中文，否则一些老版本SDK的例子工程编译不过去；二是安装完SDK后，最好把相机的IP固定下来，在海康MVS或者Basler IP Configurator里把相机IP设置成静态IP，和工控机网口0保持在同一个网段，否则相机每次上电都可能重新申请IP，你的程序里写死的相机IP就找不到设备了。

开发环境的搭建，我讲一下常见组合。C++配海康MVS SDK和OpenCV，性能最好，适合复杂算法；C#配海康SDK，开发速度快，适合业务逻辑多的项目；Python配pylon或MVS的python接口，适合原型验证和算法实验。不管用哪种语言，都要把相机SDK的依赖库和运行环境一起打包好，不然换一台工控机部署，光环境就配半天。另外别忘了加密狗授权这个问题，很多商业视觉软件是用加密狗授权的，部署时加密狗必须插在工控机上，还要注意远程桌面时别让授权服务被session卡住，否则半夜掉线再重连时，视觉软件可能就变成未授权状态了。

3.2 通信协议选型：S7、ModbusTCP还是IO硬接线

工控机跟PLC通信，选协议之前先想清楚一个事：这路信号到底要传什么。

如果是OK/NG这类简单判定结果，优先级最高，响应时间要求最快，我建议用IO硬接线，不经过协议栈，数字量输出直接给PLC输入点，延迟在毫秒级，且不受网络波动影响。

如果是数值结果，比如测量值、判定置信度、图片编号，那就要走协议。针对西门子PLC，用S7协议直接读写DB块，自由度最高；针对其他品牌PLC，基本都支持ModbusTCP，读写保持寄存器或线圈。协议传输的结果信息量大、便于做数据追溯，但代价是需要考虑超时、重连、心跳这些网络可靠性问题。

实际项目里常用的是混合方案：OK/NG结果走硬接线，测量数据和统计信息走以太网协议。这样既保证了分拣动作的实时性，又能把详细数据传给PLC或者MES系统做记录。两条路并行，互不干扰，是我目前觉得最稳妥的架构。

3.3 IP规划、防火墙与网络隔离：开工前必须做对的杂事

IP规划这个事看起来不起眼，做错了一次能让你在产线上多待三天。

我的习惯是这样：视觉网段和控制网段完全隔离。比如工控机网口0的IP设成192.168.1.20，相机设成192.168.1.10，网口1的IP设成192.168.2.20，PLC设成192.168.2.30。两个网段物理隔离，中间不接路由，工控机就是唯一的“翻译官”。这样做的好处是：相机在视觉网段里怎么发广播都不会影响控制网段的PLC通信，而且任何一个网段断了，另一个网段还能正常工作，至少能保证PLC侧的急停和安全逻辑不受影响。

防火墙经常被忽视。Windows系统的工控机默认会开启防火墙，分分钟把你的PLC连接请求给拦了。部署时要么在防火墙里放行对应端口（S7的102，ModbusTCP的502），要么干脆在专用的工控机上禁用防火墙，但要保证这台机器不接办公网络，只接产线设备。我见过同行把工控机连到工厂办公网，中了勒索病毒，产线直接瘫痪好几天的案例，所以网络隔离不只是为了通信稳定，更是为了安全。

4. 核心链路打通：从触发到结果回传的完整实操

4.1 硬触发接线与相机参数配置

先说接线。产线上最推荐的方式是硬触发，也就是用传感器直接触发相机，不经过工控机中转，响应最快，可靠性也最高。

以海康工业相机为例，机身自带一个12pin的Hirose接口，其中Line0可以配置成触发输入，支持光耦隔离，抗干扰能力比直接接相机GPIO要好。传感器的输出信号接到Line0的正负极对应引脚上，注意传感器的NPN和PNP输出接法不一样，这个接错会导致相机永远收不到触发，而且通常不会烧设备，就是让你查半天。我建议每次新项目接线时，先用万用表量一遍触发信号的电平，确认触发时有没有一个干净的上升沿或者下降沿，再往相机上接。

相机SDK里的参数配置对应关系是这样的：TriggerMode设为On，TriggerSource选Line0，TriggerActivation根据你的传感器类型选RisingEdge或FallingEdge。把这三项设对，硬触发链路就算通了一半。剩下的关键参数是曝光时间和触发延时（TriggerDelay）。曝光时间要根据产线速度和运动模糊来定，公式很简单：曝光时间内物体移动的距离就是运动模糊量，一般控制在0.01mm以内就基本不影响测量精度。比如产线速度0.5m/s，曝光时间10ms，物体移动0.005mm，没问题；但如果产线速度到2m/s，还是10ms曝光，那就是0.02mm的模糊，尺寸检测可能就不准了。

4.2 视觉程序主流程与结果判定逻辑

工控机里视觉程序的主流程，我习惯写成这样的循环：初始化相机和PLC连接，进入待触发状态，等待相机的取流回调或者轮询新图像，图像到位后开始跑算法，算法得出结果，紧接着把结果写入PLC或置输出位，最后回到待触发状态继续等下一帧。

这个“结果下发要快”是纯粹的时序经验。有的程序把结果写进数据库，或者打印日志，然后再写PLC，结果几百毫秒过去了，产线上的工件早跑过去了。我的做法是：先置输出信号把结果发出去，再去做记录和日志，哪怕记录失败了，也不影响产线的实时分拣。算法的输出最好直接做成一个整数标志位，比如0表示OK，1表示NG，2表示无法判断需要重测，PLC那边就根据这个标志位做逻辑分支，清晰又不容易出错。

4.3 工控机与PLC通信的代码实现

通信代码我给你一个可用的参考。假设PLC是西门子S7-1200，工控机用Python，通过python-snap7库读写PLC的DB块。

import snap7 from snap7.util import set_int # 连接PLC，参数分别是IP，机架号0，槽号1 plc = snap7.client.Client() plc.connect('192.168.2.30', 0, 1) # 检测结果写到DB1.DBW0，1表示OK，2表示NG data = bytearray(2) set_int(data, 0, 1) # OK结果 plc.write_area(snap7.types.Areas.DB, 1, 0, data) # 读取PLC反馈，比如DB2.DBW0里的复位指令 reading = plc.read_area(snap7.types.Areas.DB, 2, 0, 2) ack = snap7.util.get_int(reading, 0)

这段代码的思路是：工控机作为客户端，PLC作为服务器，每次检测完成后工控机主动写入DB块。PLC侧的程序只要轮询这个DB块，发现值变了就去执行分拣，执行完可以把DB块置0或者写回一个应答值，工控机下次写入前看看应答值是否有效，避免重复触发。这套握手逻辑非常重要，不然可能出现一个OK信号被PLC执行两次，或者同一个工件被处理两次的事故。

如果是ModbusTCP，思路类似。用Python的pymodbus库，写保持寄存器地址比如0x0000，值1代表OK，值2代表NG。关键是功能码别搞错，写单个寄存器用0x06，读用0x03，很多新手一上来就用错功能码导致通信失败，又去怀疑网线有问题。

4.4 NG/OK下发的两种方案与取舍

刚才在协议选型时提了一句混合方案，这里详细讲透。

纯IO方案：工控机用数字量输出模块，OK对应一个输出点，NG对应另一个输出点。PLC的输入点直接接这两个信号。优点是响应时间极短，只有毫秒级，而且不依赖网络，PLC的扫描周期足够捕捉。缺点是你传不了更多信息，想知道每个工件的具体测量值，还是得走协议。

纯协议方案：全部结果通过以太网报文发送，省去了IO接线，信息量也大。但协议通信存在网络延迟和不确定性，万一交换机一根网线松动导致重连，正好有工件过来，结果发不出去，分拣就漏了。

所以我在有分拣动作的项目里，几乎都用混合方案：OK/NG两个信号走硬接线，用来驱动分拣机构；测量数值、置信度、检测时间戳这些走ModbusTCP或S7协议，用来做数据追溯和质量分析。这样硬接线保证了产线的实时性，协议传输保证了数据的完整性，两边各干各的活，反而都稳定。

5. 联调阶段最该做的三件事：标定、报文验证与节拍测试

5.1 相机标定：像素坐标如何变成产线上的真实坐标

如果项目只是判断“有没有缺陷”，其实不一定要做严格标定，图像处理里比对模板就够了。但凡是涉及尺寸测量或者引导机械手定位，标定这关逃不掉。

最常用的是2D平面标定。拿一块棋盘格标定板，格距精确到微米级的那种，放在相机视野里的工作平面上，变换几个姿态多拍几张，然后用OpenCV的calibrateCamera算出相机内参和畸变系数，再做畸变校正。校正后的图像里，一个像素对应多少毫米，用一个标准量块或者标定板上的已知格距就能算出来，这个换算系数直接决定尺寸测量的准确性。误差往往就藏在标定板不平、标定板跟检测平面不平行这些细节里。

如果还涉及到和机器人坐标系的联动，那就要做手眼标定。相机固定在天上照传送带，机械手去抓工件，机器人的坐标系和相机坐标系之间有一个固定的变换关系，这个关系就是通过手眼标定算出来的。用Halcon的手眼标定助手、OpenCV里的solvePnP，都能求解出这个变换矩阵。项目里如果省掉这一步，指望靠机械手“大概对准”去抓视觉定位的工件，大概率是要撞机或者抓歪的。

5.2 通信报文与异常处理：别等运行半年才查IP

联调时通信验证我建议按这个顺序做，不要跳过。

第一步，物理层。Ping一趟工控机和PLC的IP，Ping通了说明网线、IP、驱动都没问题。Ping不通，先看网线灯亮不亮，再看工控机防火墙有没有拦ICMP，最后才怀疑IP配置。

第二步，端口连通性。IP通不代表端口通。S7的102端口、ModbusTCP的502端口，可以用工具或者自己写个小程序验证一下端口通不通。很多防火墙拦截是拦端口不拦Ping的，这个步骤能逼出不少隐形问题。

第三步，数据读写回环。工控机往PLC写一个数，再立刻读回来，看看数值对不上不对得上。这一步验证的是地址映射关系，尤其在ModbusTCP中寄存器地址的偏移很多资料里差一个1，稍不注意就会读写到错误的存储区。

第四步，异常处理流程。PLC重启了工控机怎么重连、网线断了重插怎么恢复、工控机程序崩溃了PLC侧能否感知。这些都要有预案。我通常会做心跳机制，工控机每隔500毫秒往PLC某个寄存器写一个递增计数，PLC的逻辑里检测到计数长时间不变，就知道视觉系统和工控机掉线了，可以执行报警或者停线，而不是让不合格品继续流到下个工位。

5.3 节拍测试与长时间稳定性验证

链路联调的最后一步是跑节拍和稳定性。先把产线手动跑起来，用秒表统计从传感器触发到PLC收到结果的总时间，减去纯算法耗时，剩下的就是链路损耗。如果链路损耗超过20毫秒，就得查是相机取流缓冲太大、图像传输带宽不足，还是程序里结果下发前做了太多额外操作。

稳定性验证我坚持跑72小时连续空跑加断料测试。空跑是验证设备长时间无人干预时会不会掉线、会不会内存泄漏；断料测试是验证没有工件触发时，程序能不能稳定停在等待状态。这两个测试做完基本就能放心交付了。我在部署中遇到过视觉程序内存泄漏，跑一天内存占用涨到99%，最后系统卡死，产线停了半小时的事故。所以现在我的程序里必写日志，定期记录帧数和内存占用，发给运维，一旦异常可以提前干预。

6. 实战避坑：我在产线上踩过的那些坑

6.1 高频故障速查表

我按出现频率整理了产线视觉项目常见的坑，方便你现场排查时对照。

这个表不能解决所有问题，但覆盖了我遇到的绝大多数字眼上的故障。你只要记住一个原则：链路问题优先查物理层和时序，再查软件和协议，最后才去怀疑算法。

6.2 稳定运行的三条铁律

第一条铁律：所有IO信号和通信链路都要做隔离。传感器线、触发线走屏蔽双绞线，且与动力线分开线槽；工控机与PLC之间如果距离远，加上工业级交换机或者光电转换器，能有效避免地环流干扰。

第二条铁律：程序必须有看门狗和日志。工控机程序要么做成系统服务，要么配置看门狗定时器，崩溃后能自动重启并重新连接PLC。日志一定要落盘，记录每一帧的处理时间、丢帧计数、PLC连接状态，没有日志你排查问题就像闭眼开车。

第三条铁律：现场部署永远多留一套备用方案。相机网线多备一根、工控机多配一个电源模块、PLC通信参数提前写好在文档里，哪天半夜产线报警，你才知道这些东西有多值钱。我自己的习惯是，项目交付时除了程序，一定附一份IP规划表、IO对照表、参数清单，哪怕半年后客户自己换了个PLC模块，拿着表也能自行把链路恢复起来。

最后再分享一个我自己的体会：链路部署这事，靠的不是某一个时刻的灵光一现，而是把每一个环节里不起眼的细节做到位。触发线有没有压紧、IP是不是静态、心跳有没有加、日志有没有落盘，这些小事叠加在一起，才是一条产线能不能连续稳定运行一整年的真正分水岭。下次再有人问视觉项目好不好做，你先问问他那套从相机到PLC的链路，扛不扛得住变频器启动那一下的干扰。