视觉检测分拣设备中欧姆龙NX1P2总线PLC应用要点解析

做自动检测机的朋友应该都有同感：真正让设备头疼的往往不是检测算法本身，而是“怎么把运动、视觉、逻辑判断和节拍捏合在一起”。我去年完成的一个视觉检测分拣项目，就差点栽在控制器的选择上——一开始想用传统PLC加一堆继电器和脉冲模块，后面发现轴数、相机通信、数据追溯全挤在一起，光是配线就够让人焦虑。最后换成欧姆龙NX1P2系列总线PLC，整套系统才理顺。这篇就围绕这个项目，说说NX1P2在自动检测机里到底怎么用、为什么值得用，以及调试中那些文档里不会写的细节。

1. 检测机为什么非要总线型PLC：先把需求盘明白

1.1 自动检测机的控制需求到底长什么样

自动检测机首先是一台“生产设备”，其次才是一台“检测设备”。它要做的事情通常不外乎四件：把被测工件送到指定位置，触发相机或传感器采集信号，根据结果完成分拣或打标，最后把检测数据传出去。听起来简单，但现场一叠加就复杂了——尤其是节拍要求高、判级结果要跟具体工件绑定、还要做到不停机连续运行的场合。

我当时做的是一台直线式外观检测机，检测流程是：进料传送带送入被测件，到位后由伺服机构把工件推上检测工位，工位上两个视觉工位分别拍正面和侧面，拍完判定OK/NG，NG件由后端推料气缸吹出，OK件继续流到包装段。生产节拍要求每件3.5秒以内，包含推送、两次拍照、判定、出料全程。

这类设备对控制系统的核心要求有三条：

• 运动控制精准：推料伺服要走多段定位，而且每次定位不能累积偏差，否则视觉检测坐标会跑偏。
• 触发时序严格：拍照触发必须和传送位置严格同步，触发早了或晚了，拍出来的图像就是废的。
• 数据能对号入座：每个工件的检测结果要能对应到它的物理位置，不能出现“前面那件被判NG，结果后面那件被打掉”的串位。

这第三条最容易被人忽略。很多用普通PLC的项目，视觉检测结果通过IO点传给PLC，几个IO就代表OK/NG，但如果产线上同时有多个工件在流转，怎么知道这个NG信号属于哪个工件、该由哪把推料气缸动作？这时候依靠总线通信、把每个相机的检测结果打包成数据帧传给PLC，再由PLC内部建立追踪模型，才是正路。

1.2 传统PLC方案为什么吃力

传统方案不是不能用，而是用起来很别扭。先说配线：普通PLC加扩展模块，数字量输入输出点一多，柜子的接线量立刻膨胀。视觉系统通过IO点交互，一个相机至少占用五六个IO点去传结果码和触发状态；再加上每个伺服轴要接脉冲方向信号、编码器反馈，一台双相机加两轴伺服的检测机，控制柜里光信号线就得上百根。而且信号线一长，干扰问题就来了——脉冲线、相机信号线、气缸阀线扎在一起，偶尔误触发一次，排查难度极高。

再说同步性。普通PLC的扫描周期和运动控制的插补周期是两个体系，视觉触发、伺服移动、逻辑判断之间的时序全靠程序里写延时来实现。延时方案看似可行，但节拍一变、机械磨损后电气特性一变，延时就不准了。检测机最怕的就是“时序不准导致误判”，一旦发生误判，设备商的售后就要被客户反复催。

所以我当时的结论很明确：这个项目要上总线型PLC，而且运动控制最好就在同一个控制器里完成，不要搞“PLC加独立运动控制器”的双脑架构。双脑架构又要做两套程序，联调时两边工程师互相等，效率极低。

2. 系统架构设计：总线拓扑和硬件选型怎么落地

2.1 NX1P2在检测机里的角色划分

NX1P2系列本质上是一台“内置运动控制功能的紧凑型PLC”。它的定位是给规模不大的自动化设备提供“一台搞定”的控制方案，通过EtherCAT总线和EtherNet/IP总线把伺服、远程I/O、视觉系统、HMI全部串起来，省掉大量物理接线。

在这个检测机项目里，我把它划分成三个层次来用：

这种划分最大的好处是：运动、设备、信息三个层面的数据可以在同一个PLC程序里直接访问。伺服当前的位置、视觉检测的结果、远程I/O的状态，在程序里都是“变量”，写逻辑的时候不需要考虑“这数据是从哪个模块来的”，编程体验和思路都清爽很多。

2.2 硬件配置的具体清单和理由

我实际用的是NX1P2-1040DT1这个型号。选它的原因很朴素：内置数字量I/O数量够用、带高速计数输入和脉冲输出、支持EtherCAT主站，而且尺寸紧凑，装在600mm×600mm的控制柜里不占地方。

具体配置清单供参考：

• CPU单元：NX1P2-1040DT1，内置数字量输入输出，晶体管输出型
• 伺服：EtherCAT伺服驱动器两台，分别驱动推料滑块和旋转分度机构，配合增量编码器伺服电机
• 远程I/O：一个EtherCAT从站模块，扩展16点输入16点输出，用于接气缸磁性开关、料位传感器、吹气阀
• 视觉：两台工业智能相机，内置EtherNet/IP通信，通过交换机接到PLC的EtherNet/IP口
• HMI：触摸屏通过EtherNet/IP连接，显示工位状态、节拍统计、停机报警
• 编程软件：Sysmac Studio，完整的运动控制加逻辑编程都在里面完成

有一点需要特别提醒：NX1P2-1040DT1这种型号内置的I/O是晶体管输出，不能直接驱动大电流的电磁阀，中间必须加继电器或者用阀岛。这个坑我见过不少同行踩：晶体管输出直接带阀，通电瞬间电流一冲击就烧点。虽然NX1P2的输出有保护，但长期高频率动作还是建议老老实实加中继，可靠性完全不同档次。

2.3 总线网络调试时的几个“开机前检查”

EtherCAT总线刚上电时最容易出的问题就是“从站找不到”。根据经验，调试顺序千万别乱：

1. 先用网线把PLC和每个从站单独连一遍，确认单独通信都正常。
2. 再把所有从站串起来，在每个从站上设置好节点地址，地址不能冲突。
3. 上电后在Sysmac Studio里做一次EtherCAT配置识别，看拓扑结构是否和实际一致。
4. 最后才做PDO映射和应用编程，不要急着写运动程序。

有一点值得说一下，EtherCAT对网线质量非常敏感。检测机现场往往有很多电机、变频器，网线如果屏蔽层没处理好，总线偶尔会掉站。我项目里一开始用的是普通超五类成品网线，现场跑一段时间就出现从站丢失报警，后来全部换成了带金属屏蔽头的工业级别线，同时把总线电缆和动力电缆分开走线槽，问题才彻底解决。

3. 从检测到分拣：运动控制与判定逻辑的同步实现

3.1 推料伺服和视觉触发之间的“电子凸轮”玩法

检测机里运动控制最核心的要求不是跑得快，而是“该停的地方停得住、该触发的时候不晚”。在NX1P2上，除了常规的定位运动，我用了电子凸轮功能来处理推料机构和相机触发之间配合的问题。

简单解释一下电子凸轮的概念：传统凸轮靠机械形状决定运动时序，电子凸轮则是用软件建立一个主位置和从位置之间的映射表。在这个项目里，我把传送带的编码器位置作为主轴，推料机构的运动作为从轴，通过电子凸轮建立“传送带走多少，推料滑块就跟到什么位置”的关系。

这样做有几个实际好处：

• 推料动作和传送带速度自动同步。传送带速度即使小幅波动，推料滑块也不会错位。
• 视觉触发位置变得非常精准。我在电子凸轮表里设置了几个特定的主位置点，当编码器位置到达这些点时，PLC直接通过高速输出触发相机拍照，不需要用PLC扫描周期去轮询，触发延迟基本可以忽略。
• 换型方便。产品尺寸变化时，只需要修改电子凸轮表里的映射曲线，不用动机械结构。

具体到NX1P2的编程实现，就是在Sysmac Studio里添加“凸轮”类型的运动轴，把主轴的编码器位置作为输入，然后定义从轴的位置曲线表。曲线表可以用程序里的点阵数据填写，也可以直接用软件自带的凸轮编辑器生成。实测下来，用这种方式的定位重复精度比普通“定位完成后触发拍照”的方式提高了不少，周期也节省了约0.2秒。

3.2 分拣动作的状态机：防止“串位”才是硬功夫

视觉检测之后的分拣行动是整个设备里最容易出Bug的地方。因为从拍照到推料气缸执行，中间隔着传送带继续走动、工件可能存在打滑或者偏移，如果只在PLC里写“拍到NG就立刻推料”，几乎必然会出现“把好的推掉、把坏的放走”的情况。

我用的办法是把“工件追踪”建模成一组先进先出的状态队列。具体逻辑是：

• 每一步进脉冲过来，PLC把传送带偏移量累加，当成每个工件的“虚拟坐标”。
• 相机检测完成后，把结果连同拍照时的主位置坐标一起写进PLC的一个结构体数组。
• 每个数组元素记录工件的唯一编号、拍照时的坐标、检测结果、是否已处理。
• 当某个工件的坐标到达推料气缸位置时，PLC先检查它的检测结果，再决定是否输出吹料信号。

这个模型在NX1P2上实现并不复杂，因为变量支持结构体类型，数组操作也很方便。每个工件的记录就像一张“身份证”，从拍照到分拣完成，整个流转路径都清晰可查。实际操作中我把数组长度设为32个工位的长度，相当于能同时追踪32个在途工件，完全覆盖了产线长度。

这里有一个注意点：工件在传送带上偶尔会打滑，导致实际位置和理论位置偏差。为了补偿，我在推料气缸前加了一个对射传感器，工件经过时会触发一次“位置校正”，把数组里对应工件的虚拟坐标刷新为实际坐标。这个细节看似简单，但对分拣准确率影响极大。

3.3 运动程序里的小心机：回原点方式要选对

检测机设备的回原点方式直接影响效率。很多设备每次开机都要手动把各轴回到机械原点，检测工位重新标定，一套流程下来要好几分钟。

NX1P2支持多种回原点方式，包括原点传感器加Z相、限位信号、数据设置型等。在这个项目里，我用了“Z相搜索+原点传感器”的组合方式：先快速找原点传感器，再退出传感器后低速找Z相脉冲。这个方式的好处是，每次回原点的重复精度都能保证在编码器单圈以内，相当于每圈内的绝对位置都一致。

另一个提高效率的小技巧是把回原点动作做的“懒一点”：如果推料机构上次断电位置和原点距离很近，程序可以判断后直接执行近原点恢复，而不必每次全行程回扫一遍。这种细节在单机设备上看起来微不足道，但在每天开停机多次的产线上，节省的时间相当可观。

4. 视觉与PLC的数据交互：触发时序和结果处理的细节

4.1 相机接入方式：EtherNet/IP和Socket哪个更省心

检测机上视觉系统和PLC的数据交互有两种常见方式：一种是通过视觉控制器自带的IO点直接传输几个开关量，另一种是用网络通信把检测结果以数据帧形式发给PLC。

IO点方案简单直接，但信息量有限，只能传“OK/NG”这种一级结论，一旦涉及多个检测项、不同缺陷类型，IO点数就不够用了。而且IO触发和结果反馈存在时间差，PLC很难判断结果具体属于哪个工件。

网络通信方案能传输的信息量就大多了。我当时用的是EtherNet/IP的标签数据链接方式。视觉做完检测后，将结果写入一组标签变量，PLC在同一个网络里直接读取这些标签值。标签内容包括：工件编号、OK/NG结论、缺陷类型代码、测量值、相机内部处理耗时。PLC拿到这些数据后，再做分拣和统计。

在实际配置时，EtherNet/IP这种方式比纯Socket通信省心很多。Socket通信需要两边都写收发程序、处理分包粘包、还要考虑超时重发，而EtherNet/IP标签链接在Sysmac Studio里配置好协议后，数据是周期性自动交换的，PLC侧看起来就跟读内置变量一样。

4.2 拍照触发时序：为什么不能用“扫描到就触发”

这是很多新手调试时容易忽略的关键点：PLC的正常扫描周期和相机拍照时刻是有时间差的。如果程序中写“检测到到位信号，下一扫描周期触发相机拍照”，这个触发时刻其实是不确定的，取决于扫描周期里其他逻辑的执行时间。对于快速移动的工件，触发延迟几毫秒就可能导致图像严重偏移。

解决方案是使用NX1P2的高速输入和中断处理功能，把相机的触发信号直接从快速响应输出端口送出，或者在运动控制程序里通过电子凸轮的主位置条件直接触发。这样触发延迟和PLC扫描周期无关，差不多就是硬件级的响应速度。

我最终采用的是：视觉触发不是由常规程序触发的，而是直接用“凸轮表位置点输出”的方式驱动相机触发信号，同时把当时的编码器位置寄存器一并传给视觉控制器。这样拍出来的每一张图都自带精确的位置信息，返给PLC后还能做位置偏差校验。

4.3 结果回传后的“软握手”设计

相机拍照到结果回传之间需要一段时间。普通IO方案里PLC就干等，结果把节拍拖慢了。我用的方式是“软握手”配合“多缓存”：

• PLC送出触发信号后，把该工件的状态记为“检测中”，不去阻塞等待。
• 相机检测完成后回传一个数据帧，PLC根据帧里的工件编号匹配到对应的在途工件记录。
• 如果工件已经离开视觉工位但结果还没回来，程序会把这个工件标记为“待定”，靠后续的位置校正或缓存处理兜底。

这个设计保证了即使相机偶尔处理超时，整条产线也不会停下来，最多在分拣工位做一个“未知件优先放行”的策略。在实际设备运行中，检测超时发生率很低，但有了这层兜底，调试阶段省了不少“产线卡死”的麻烦。

5. 现场调试中的几个关键问题：实测记录和排查链路

5.1 周期抖动导致视觉误判：从伺服配置查出真相

项目联调阶段遇到一个比较隐蔽的问题：设备空跑的时候一切正常，一旦开始连续生产，偶尔出现“相机报负偏差大”的差错。起初以为是相机标定问题，反复校准了几次都没有改善。

后来我把方向转向通信和运动侧。用Sysmac Studio同时监控伺服的实际位置、编码器计数器、相机触发时刻的寄存器值，发现触发时刻的编码器位置确实存在微小抖动，波动范围大概在0.3mm左右。进一步排查，发现抖动来源于推料伺服在每个循环末尾都有一次微小的位置修正动作，这个修正动作产生的机械振动顺着机架传到了相机支架上，导致拍照瞬间图像发生微小震动。

这个问题最后通过调整伺服的增益参数和控制模式解决：把推料伺服到位后的“保持模式”改为“静止模式”，对伺服位置整定参数做了降增益处理。改动很小，但误判从此基本消失。

这类问题在文档里基本不会看到，只能靠现场抓数据才能发现。建议做检测机调试时，一定不要只盯相机画面，要把PLC、伺服、相机三者的数据放在同一个时间轴上对比，很多“检测问题”其实是运动问题或通信问题。

5.2 EtherCAT掉站：排查要从线缆开始而不是程序

项目交付后一个月，客户反馈设备偶尔出现“EtherCAT从站丢失”报警，复位后又能恢复。第一次遇到这种问题容易一头扎进程序里反复查错，其实总线掉站的第一嫌疑永远是物理层。

我当时的排查链路是：

1. 先看报警记录里掉站的是哪个从站，是固定在同一个从站还是随机多个。
2. 固定单站掉线，重点检查该站的网线接头、端子是否松动、该站的电源供电是否稳定。
3. 随机多点掉线，重点怀疑总线主干线缆的屏蔽和布线路径是否存在干扰源。
4. 用Sysmac Studio查看总线诊断信息里的错误计数和帧错误率，评估链路质量。

检查发现，掉站发生的时间基本固定在某个伺服电机加速启动的瞬间。进一步确认是网线从电机动力线旁边经过，伺服加速时动力线的大电流产生了电磁干扰。解决方案就是把总线网线重新走线，避开动力线，并换成带双屏蔽层的工业网线。改完之后几个月内再没有出现掉站报警。

5.3 触摸屏频繁弹出报警的“假故障”处理

设备试运行初期，触摸屏上经常弹“推料气缸动作超时”报警，但实际观察气缸动作速度很快，根本没有卡滞现象。后来查程序才发现，是气缸到位传感器的信号输入滤波时间设置得太长，导致PLC识别到位状态明显滞后于实际到位时刻。检测机这种高节拍设备里，传感器响应时间不能按老思路留太大余量，否则很多报警都是“自己吓自己”。把输入滤波时间从10ms调成2ms，同时给传感器信号加RC滤波电路，报警立刻消失。

6. 数据采集与追溯：总线型PLC带来的隐形收益

6.1 检测记录怎么存：从PLC变量到SQL和CSV

NX1P2一个很实用的功能是通过SD存储卡做数据记录，同时也支持通过EtherNet/IP和上位机交换数据。我在这个项目里做了一个简单的数据追溯方案：每一个工件的检测记录，包括工件编号、检测时间、视觉结果、缺陷类型、位置偏差值，都整理成一条记录写入到上位机数据库里。

PLC侧的做法是定义一个结构体数组，每一件工件完成检测后就把记录填进去，同时通过通信指令把记录发送出去。上位机收到后会写入SQL数据库，这样客户随时可以按日期、批次、工件编号追溯检测历史。

数据追溯这件事在检测项目里越来越成为必须项。很多客户不仅仅是要求设备能判OK/NG，而且要能回答“这批货里一共发现多少个划痕缺陷，分布在哪几个位置上”。没有总线通信的PLC很难做这种精细数据输出，而NX1P2因为本身支持通信协议和各种数据转换函数，处理起来要顺畅得多。

6.2 和上位机对接时的变量规划经验

和上位机对接的变量规划一定要在程序设计阶段就定好，不要等设备做完再补。我习惯的做法是在Sysmac Studio里把所有需要对外交换的数据集中定义成一个全局结构体，里面按“生产信息、检测结果、设备状态、报警信息”四个板块分类。这样无论对接MES系统还是客户自研的平台，都只要针对这一个结构体做映射就可以，不会出现散落一地的标签变量。

有一点容易踩的坑：PLC变量的数据类型和上位机的数据类型需要严格对应。Sysmac Studio里整数型变量有UINT、INT、DINT、UDINT等多种，上位机读取时如果类型对不上，轻则数据溢出，重则通信报错。我建议在变量命名里直接带上类型前缀，比如“w_工件数量”表示WORD型，“d_位置偏差”表示DINT型，对接时一眼就能看懂。

6.3 设备状态监控和远程维护的延伸

总线型PLC给设备商带来的另一个隐形成本节省是远程维护能力。NX1P2支持通过以太网远程连接，只要客户现场网络允许，我可以通过远程软件直接读取到PLC里的监控画面、当前报警、历史数据。遇到客户反馈“设备有点问题”，很多情况下不需要专门跑一趟现场，直接在办公室远程查看程序状态就能定位问题。

远程维护在检测设备上尤其重要，因为检测逻辑往往涉及大量工艺参数，客户现场操作人员不一定能准确描述异常现象。有了远程访问能力，我可以直接看到关键变量是不是在合理区间，判断是视觉误判、机械磨损还是参数漂移，把售后成本大幅降下来。

最后的体会

如果把这次自动检测机项目的经验浓缩成一句话，那就是：NX1P2这种总线型PLC的价值，并不在于某一个点上的性能有多突出，而是把运动控制、逻辑判定、视觉通信、数据追溯这几件事统一在一个平台上，让复杂设备真正变得可控。选型的时候多花点时间把架构想清楚，后面调试和维护能省下大把精力。对于正在做检测机选型的朋友，我的建议是重点评估三件事：轴数扩展余量、视觉通信方式是否灵活、数据追溯能力是否够用。这三点满足后，设备在客户现场的生命力会强很多。