☰
三菱PLC与雅马哈四轴机械手在线检测收料项目实战解析
2026/10/20 15:46:35 网站建设 项目流程

做这套三菱PLC加雅马哈四轴机械手的在线检测收料项目,是在某次设备改造里被客户追着要求"必须一次调试成功"的情况下赶出来的。整套东西包含CAD电气图纸、PLC程序和人机界面,属于典型的"中小型单机自动化标准配置"。我把它完整拆开讲一遍,从IO表设计、程序状态机、机械手握手协议,到HMI画面布局和现场踩坑,全部按实际做过的方案来写,希望能帮到正在做同类项目的朋友少走弯路。

1. 项目定位与架构选型:一张IO表看懂整套设备的工作逻辑

1.1 工艺需求拆解:检测什么、如何分拣、节拍多少

这套设备的原始需求并不复杂:产品在流水线上流过来,经过某个检测工位,系统在线判定OK还是NG,然后由四轴机械手把产品分别抓取到OK料箱和NG料箱,同时要有计数、满料报警和异常停机功能。

但"不复杂"三个字往往意味着实际做起来的复杂度都藏在细节里。我先和客户确认了几个关键参数:产品来料间隔最快2.5秒一件,检测工位允许停留时间上限1.2秒,OK和NG的比例大概是85%对15%,NG料箱容量只够装30件。这几个数字直接决定了整个方案的架构走向——节拍2.5秒意味着PLC扫描周期、机械手动作时间、检测反馈延时都得压进一个严格的时序窗口里;NG比例高且料箱小,意味着满料报警和人工清料动作不能只做成指示灯,必须纳入自动流程。

检测环节采用了视觉系统加两个传感器的方式:一个漫反射光电传感器用来检测产品到位,一个对射式传感器用来防呆防叠料,视觉系统负责真正的尺寸和外观判定,结果通过IO点直接反馈给PLC。选IO对接而不是串口/TCP通信,是考虑到视觉厂商的通信协议各有差异,IO点对接在调试现场最省时间,也最容易排查问题。

1.2 硬件选型与通讯架构

主控选择的是三菱FX5U-80MT/ES,理由很实际:这个项目需要的IO点大约70多个,FX5U的80点本体加上一个16点扩展模块刚好够用;它自带的以太网口和RS485口在调试时非常好用,GX Works3软件也支持仿真,程序在电脑上初步验证过再下载,能节省大量现场时间。

机械手选择的是雅马哈四轴水平多关节机器人,控制器是RCX340。这个型号在小型搬运分拣领域优势很大,重复定位精度能做到±0.02mm,而且RCX340内置了CC-Link总线从站功能,和三菱PLC直连非常顺。通讯架构我最终选的是硬线IO握手加CC-Link总线同时存在的双通道方案——IO握手作为主控制逻辑,CC-Link用来传输较多数据比如产品编号、检测数据和机械手状态字。

这里要解释一下为什么不用纯总线:机械手在调试初期动作还没完全定型时,硬线IO点排查问题非常直观,万用表一搭就知道信号到没到;而CC-Link传输的数据在GX Works3和RCX340的软件里看波形和监控,二次开发时也方便。等到运行稳定后,IO线可以直接保留作为安全冗余,总线数据用于报表统计,各干各的活。

1.3 IO分配表和信号流向规划

IO表是这个项目的灵魂。我把所有信号按功能分成四类:安全类、检测类、机械手交互类、指示类。

信号分类信号名称方向说明
安全类急停回路反馈DI全系统常闭串联,断开即停机
安全类安全门开关DI开门时禁止自动运行
检测类产品到位传感器DI漫反射光电,检测产品流入检测工位
检测类防叠料传感器DI对射式,防止双层产品进入
检测类视觉系统OK输出DI视觉判定合格信号,常开
检测类视觉系统NG输出DI视觉判定不合格信号,常开
机械手类取料请求DOPLC给机械手控制器的启动信号
机械手类取料完成DI机械手抓取完成并离开检测工位后反馈
机械手类释放完成DI机械手将产品放入对应料箱后反馈
机械手类机械手异常DI控制器报警输出
指示类三色灯塔输出DO运行/待机/报警三色指示

这张表在画CAD图纸前就必须敲定。很多人喜欢先画图纸再整理IO表,结果到编程时发现信号乱成一团,回头改图纸更痛苦。我习惯把IO表作为唯一的"信号宪法",GX Works3里的软元件注释、CAD图纸上的端子号、HMI里的监控地址全部以这张表为基准,这样后期任何环节出问题都能快速反查到源头。

电气图纸设计时,我把这些IO信号分成三个页面来绘制:PLC输入模块接线图、PLC输出模块接线图、机械手控制器IO接线图。每页图纸右上角标注对应的IO表编号段,方便施工时对照。

2. 电气图纸里的安全红线:主回路、急停与PLC信号隔离的设计要点

2.1 主回路电源分配与开关电源容量计算

CAD电气图纸里最容易出错的反而不是复杂的控制回路,而是看似简单的主回路电源分配。这套设备里一共有5路需要供电的设备:PLC本体及模块(约50W)、视觉控制器(约80W)、机械手控制器RCX340(峰值约1.5kW带刹车)、传送带电机(0.4kW)、HMI触摸屏(约30W)。

机械手控制器和传送带电机必须走动力回路,用断路器加接触器控制,接触器线圈由PLC输出点控制。视觉控制器和HMI走控制回路,由开关电源统一供电。我在图纸上画了两个断路器:QF1负责总进线保护,QF2负责机械手控制器单独供电,这样机械手检修时可以单独断电而不影响PLC和HMI继续运行,非常实用。

开关电源容量计算是很多图纸里的隐藏雷区。这套设备选的是24V 6.5A的开关电源,我按照"统计控制回路负载总和再留20%余量"的方式算了一遍:PLC约1.2A,HMI约1.3A,传感器类8个约0.5A,继电器线圈12个约2.4A,视觉IO电源约0.3A,总和约5.7A,6.5A的电源刚刚好。要注意的是继电器线圈的瞬间吸合电流通常比保持电流大3到5倍,所以不能精确计算,必须留足够余量。

2.2 安全回路:急停按钮、安全门与机械手互锁

安全回路的设计原则是"失效导向安全",也就是任何一根线断了或者任何一个安全器件坏了,系统都必须停机。我这套设备里急停按钮用了两个,一个装在操作面板前,一个装在机械手围栏门旁边,全部是常闭触点串联在一起,形成一个完整的回路。

这个回路不是直接进PLC的DI点就完了,而是先接一个安全继电器,安全继电器的输出再分成两路:一路给PLC的急停DI点,一路串在机械手控制器的急停输入端子回路里。这样做的好处是:急停时机械手控制器本身也直接收到断链信号,机械手会立刻进入紧急停止状态,而不是等PLC处理后再转发。机械手紧急停止的响应时间是毫秒级直接切断伺服使能,这比任何程序层面的停机都可靠。

安全门开关还要再叠加一个互锁逻辑:安全门打开时,禁止机械手自动运行,同时PLC输出给气缸的电磁阀必须断电。这里有个细节容易被忽略——气缸的电磁阀如果用的是单线圈弹簧复位型,断电就会自动复位,但如果是双线圈自锁型电磁阀,断电后阀芯会保持在原位置,存在安全隐患。我在图纸上特意标注了所有参与动作的电磁阀一律选用单线圈型,同时PLC程序里做了开门断电保护。

2.3 PLC接线端子分配与信号隔离注意事项

FX5U的输入端是漏型/源型可切换的,但接线时必须统一。我按漏型输入来接,也就是传感器三线制棕蓝黑接法,黑色信号线接PLC输入端子,公共端COM接0V。这个选择在图纸上必须前后一致,不然调试时传感器死活不给信号,查了半天发现是电源极性接反了,这种低级错误在实际项目中出现频率非常高。

输出端我全部用继电器中转,继电器线圈由PLC输出点驱动,继电器触点再控制负载。原因很简单:PLC输出点的晶体管或继电器触点容量有限,而且PLC输出点烧了换起来非常麻烦;继电器中转后,PLC输出点只承担几十毫安的线圈驱动电流,负载端的过流损伤都由继电器本体吸收,坏了换继电器就行,成本也低。图纸上每个继电器线圈两端都并接了续流二极管,触点端根据负载类型选择RC吸收或压敏电阻,这些细节能少烧一堆触点。

机械手控制器的IO端子接收的是24V电平信号,但它内部的IO端子和PLC并不共地。我在图纸上加了一个中间继电器隔离层,所有PLC到机械手的信号都经过继电器触点转换,电气上完全隔离。刚开始有人觉得多余,后来机械手控制器维修时有人不小心把外部24V短路了,因为有了隔离层,PLC一侧毫发无损,这就值回所有成本了。

3. PLC程序骨架:状态机驱动的检测判定与收料分流

3.1 程序整体结构:Main轮询加STL状态机

FX5U的程序用GX Works3编写,我没有把全部逻辑堆在一个主程序里,而是分成四个独立程序块:初始化程序、自动运行程序、手动调试程序、报警处理程序。自动运行程序是核心,采用STL步进梯形图指令编写状态机,这也是三菱PLC做顺序控制最经典的方式。

STL的好处在于每个状态之间逻辑清晰,不会出现多个状态同时激活的问题。我把整个自动流程划分为以下状态:

  • S0:初始状态,等待启动条件满足
  • S10:启动传送带,产品入料等待
  • S20:产品到位检测,触发视觉拍照
  • S30:等待视觉结果,判定OK/NG
  • S40:发送取料请求给机械手,等待取料完成
  • S50:根据判定结果选择放置指令,等待机械手释放完成
  • S60:空闲等待下一个产品

每个状态都有对应的超时时间,任何状态停留超过设定时间都直接跳转到报警状态S99,触发报警停机。这种设计让程序在异常情况下永远不会"卡死"在某一步,设备调试和生产中遇到故障,操作人员看触摸屏上的当前状态号就能快速定位问题环节。

3.2 在线检测流程的STL步进实现

检测流程是这个程序最核心的部分。S20状态检测到产品到位后,我做了三个动作:先延时200ms让产品在检测工位上完全静止,然后置位视觉触发输出,同时启动一个500ms的等待计时器。

这里为什么先延时200ms?因为传送带输送产品到检测位时,产品不会立刻完全停止,可能存在微小滑移或抖动。视觉系统对图像稳定性要求很高,如果产品还没停稳就触发拍照,得到的图像可能是模糊或偏斜的,直接影响检测准确性。200ms这个值是我在调试现场根据实际传送带停止特性试出来的,客户后来想改为100ms,结果NG率立刻上升,说明这个延时值是必要的。

视觉系统触发后,OK和NG信号并不会立刻有效。视觉软件的处理时间大约在200到400ms之间。我在S30状态里写了一个分支判断指令:

LD M100 (视觉OK) SET S40 LD M101 (视觉NG) SET S45

S40是OK处理分支,S45是NG处理分支。双分支的好处是不管视觉结果是哪个,程序都能立刻响应,不需要先统一到一个状态再判断。同时我加了一个"视觉超时"保护:触发输出ON之后1000ms内OK和NG都没有任何一个有效,则认为视觉系统异常,直接报警停机。这样视觉死机或者通信中断时设备不会傻等。

3.3 收料分流逻辑:计数、满料与超时保护

收料分流逻辑的关键在于区分"产品属于哪一批"和"这一批要送到哪个料箱"。我为每一件产品维护了一个数据寄存器D100,用来存储当前产品的判定结果,1代表OK,2代表NG。S30状态判定完成后立刻写入D100,后续机械手交互状态只需要读取这个值,不需要再关心判定过程。

机械手完成一次搬运后,程序里对OK和NG分别计数,C10存OK数量,C11存NG数量。满料检测分两层:第一层是C11计数达到设定值(NG料箱容量30件),程序置位满料报警输出并暂停自动运行;第二层是料箱光电传感器检测到物理满料,这个信号直接进PLC的DI点,优先级更高。因为计数和实际可能存在偏差(比如机械手抓空或者产品掉落),光电传感器作为物理兜底非常必要。

超时保护在收料环节也发挥了很大作用。机械手从取料请求发出到取料完成反馈,正常情况大约需要800ms;从收到放置指令到释放完成反馈,正常情况大约需要600ms。我在程序里给这两个环节分别设定了2000ms的超时计时器,超时即报警停机。这个2000ms不是随便拍的——机械手高速运行时的速度曲线、抓取动作、放置动作都需要时间,我把正常节拍乘上2.5倍余量作为超时阈值,既不会误报警,也能在机械手意外卡住时迅速暴露问题。

3.4 与机械手的"握手协议"程序段

握手协议是PLC和机械手两个独立控制器之间最重要的配合逻辑。机械手是高速运动设备,PLC是逻辑控制设备,两者扫描周期不同,机械手控制器的工作节拍比PLC快得多,所以不能靠"发一个信号等固定时间"这种朴素方式,必须设计一套完整的握手时序。

握手协议分两轮:

第一轮:取料握手。PLC置位取料请求信号Y20。机械手读到Y20为ON后,开始执行取料动作程序,动作完成后机械手输出取料完成信号给PLC的DI点X30。PLC收到X30后,复位Y20。机械手看到Y20从ON变为OFF后,复位X30。整个握手完成。

第二轮:放料握手。PLC根据D100的判定结果置位放OK请求Y21或放NG请求Y22。机械手读到对应请求后执行放料动作,完成后输出释放完成信号X31。PLC复位请求信号,机械手复位完成信号。

这套握手协议的关键在于每一轮都要求"请求方先撤信号,完成方再撤反馈信号",形成一个闭环。如果哪一方没有撤信号,下一次握手就无法开始,设备会停在当前状态并触发超时报警。调试时我把这个逻辑用GX Works3的软元件监控功能分开观察,发现握手信号偶尔出现"粘滞"现象——后来查出是机械手控制器里的IO扫描周期比PLC慢导致的,在PLC程序里把请求输出加了50ms的脉冲保持时间就解决了。

4. 机械手程序的闭环:点位规划、节拍计算与异常恢复

4.1 机械手点位规划:接近点、抓取点、放置点与控制点

雅马哈机械手程序里点位规划的好坏直接决定了设备节拍。我这套设备的点位分成四组:检测工位抓取点、OK料箱放置点、NG料箱放置点、待机原点。每组点位我又规划了三个层次:待机点、接近点、实际动作点。

待机点是机械手在非工作状态下停靠的位置,要求不干涉其他设备且距离工作区域近;接近点是实际动作点上方20mm的过渡位置,机械手从接近点再低速直线下降到实际动作点;实际动作点才是抓取或放置产品的精确位置。为什么要这么设计?机械手如果直接从待机点高速直线运动到实际动作点,末端抓具很容易在快速停止时产生抖动,导致抓取定位偏移。分阶段运动后,机械手在接近点的速度已经降到低速,最后20mm的下降过程非常平稳。

抓取点确定后,我做了一件事让调试顺利了很多:在机械手工作范围最远端和最危险的拐角处各设置了一个慢速边界点,机械手在自动运行过程中一旦经过这些边界点,程序强制将其速度降到10%。这样即使程序里某段速度参数设置失误,机械手也不会高速冲向料箱边缘,降低了撞机风险。

4.2 RCX340程序中的分支指令与信号处理逻辑

雅马哈RCX340程序使用的是类似BASIC的语法,核心逻辑围绕输入信号判断和分支跳转展开。我给这套设备的机械手主程序定义了以下流程:

P100 ' 取料主流程 WAIT IN(0)=ON ' 等待PLC取料请求Y20 MOVE P_A, P_B, S=100 ' 从待机点移动到检测工位接近点 MOVE P_C, P_D, S=30 ' 低速移动到抓取点 GRIP ON ' 闭合气爪抓取 MOVE P_D, P_C, S=30 ' 低速离开 MOVE P_B, P_A, S=100 ' 高速回到待机区 OUT(0)=ON ' 输出取料完成信号X30 WAIT IN(0)=OFF ' 等待PLC撤除请求信号 OUT(0)=OFF ' 撤除取料完成反馈

放料流程与取料流程类似,只是根据PLC给出的放OK或放NG请求信号,在分支指令里跳转到不同的放置点位:

WAIT IN(1)=ON ' 放OK请求Y21 MOVE P_OK_A, P_OK_B, S=100 ... OUT(1)=ON ' 输出释放完成信号 WAIT IN(1)=OFF OUT(1)=OFF

这里有个重要的细节:PLC的请求信号必须保持有效一段时间,机械手才能稳定读到。我前面提到PLC侧加了50ms脉冲保持,机械手一侧对应在WAIT指令前加了延时语句。两个控制器的响应速度差异就用这种方式对齐,这是整个握手逻辑稳定运行的关键。

4.3 节拍优化与异常恢复策略

节拍优化的空间主要集中在移动速度和等待时间上。我把机械手运行速度分成了三段:待机点到接近点用100%速度,接近点到实际动作点用30%速度,返回路径用100%速度。客户一开始希望全程100%,我坚决不同意——实际动作点的高速到位风险太高,一旦出现定位不稳导致产品掉落或抓具撞料箱,损失远大于省下的零点几秒。最终实测单次搬运循环约1.5秒,完全能满足2.5秒节拍。

异常恢复策略我分两级设计:第一级是机械手本体异常,比如伺服报警、气压不足,RCX340会切断输出并停止动作,PLC收到机械手异常信号后进入报警状态,操作员需要在触摸屏手动复位;第二级是流程异常,比如取料超时、释放超时,PLC报警但机械手程序仍在待命状态,操作员处理完卡料后可以把设备切回自动状态继续跑。

这个两级策略在实际运行中救了很多次场。有一次NG料箱满料导致PLC报警停机,但机械手刚好抓起一件NG产品正往料箱方向飞。如果机械手本体没有异常处理,它会继续飞到满料位置然后执行放置动作,可能出现产品堆叠塌落。因为我在机械手程序里对放置动作前增加了一个"允许放置信号"判断,PLC一报警就撤掉该信号,机械手会在料箱上方悬停等待,直到操作员清完料箱重新启动,它才继续放置。

5. 人机界面不该只做"最后一页":画面布局、配方与权限

5.1 主画面与运行状态监控

很多人做HMI喜欢把控制按钮全堆在一个画面上,看似方便操作,其实隐患很大。我把主画面做成了两个区域:上部是设备整体状态示意,下部是当前工件的实时信息卡片。

状态示意区我用简单的图形组合画出了检测工位、机械手、两个料箱的位置关系,每个对象旁边配一个状态指示灯。机械手当前在哪个位置、检测到的产品是OK还是NG、料箱满不满,操作员扫一眼主画面就能完全掌握,不需要去翻各个子页面。这个设计在项目验收时被客户操作员特别夸奖了一下。

第二块区域是实时信息卡片,显示当前的工件编号、检测结果、累计OK数、累计NG数、当前机械手状态。韩版的工件编号来自PLC内部计数器,每次检测完成自动加一,这样操作员随时可以说出"我这一批次做到第几件了",对于生产管理和质量追溯非常重要。

5.2 参数配方的分层管理

参数配方界面我做了三层结构:系统参数、工艺参数、设备参数。系统参数包括程序版本、通讯端口设置,这些交给调试人员;工艺参数是操作员日常需要调整的,比如检测超时时间、机械手动作超时时间、满料设定数量;设备参数则是出厂前标定好的,比如IO滤波周期、秤定值、视觉触发延时,默认不允许普通操作员修改。

这三层的权限等级对应三个登录账号:管理员、工艺员、操作员。管理员可以改所有参数;工艺员只能改工艺参数层;操作员只允许查看,重点是看检测结果和计数。我特意没把操作员修改参数的权限开出来——在生产现场,操作员为了赶产量动参数导致品控出问题的情况太多了,把参数权限收紧是替客户把关,不是限制效率。

GX Works3里我用全局标签来映射HMI的写入地址,这样在HMI页面和PLC程序之间改元件名时,两边会自动同步,避免地址错位。触摸屏选的三菱GOT2000系列,它和FX5U用同一根以太网线直连,画面数据刷新速度很快,设备状态监控基本没有延迟感。

5.3 报警履历与手动操作页面

报警是HMI里最不能对付的页面。我把报警清单做成了一张表,每条报警有编号、内容、发生时间、复位方式四列。PLC程序里每触发一个报警,都会把报警代码写进一个数据寄存器并触发报警历史记录。GOT2000的报警履历功能支持掉电保持,故障发生时来不及看的报警,下次开机依然能查到。

手动操作页是设备调试和维修时的主要场景。我在页面里放了机械手原点回归按钮、传送带点动按钮、气缸伸缩点动按钮、各传感器的实时状态显示。手动页面与自动程序严格互锁,自动运行中禁止进入手动模式,反之进入手动模式后自动程序全部复位。这个互锁在PLC程序里用的是M8000常通触点加主控指令,一旦切换手动模式,整个自动状态机立即被清除,保证了调试时的安全。

6. 现场调试里的三个硬仗:通讯抖动、误检波动、堆叠错位

6.1 通讯抖动排查:一次IO信号误触发的前因后果

调试到第三天,出现了一个极其隐蔽的故障:设备运行大概两个小时后,机械手会自己执行一次额外的取料动作,但检测工位上明明没有产品。第一次我没当回事,以为是操作员误碰了手动按钮。第二次同样的事情再次出现,我开始认真排查。

我首先用GX Works3的软元件监控捕捉PLC输入端子的变化波形,机械手异常触发瞬间除了取料请求输出Y20有动作外,其他输入输出点都正常。接着怀疑是机械手控制器误发了完成反馈信号,于是把机械手一侧的输入输出监控调出来观察,结果发现它在未收到任何请求的情况下,IO输出区竟然出现了一个持续120毫秒的干扰脉冲信号。

最终锁定为机械手控制柜和动力电缆之间感应电压异常。机械手柜里的24V控制线有一段和伺服电机电源线走在了同一个线槽里,伺服电机加减速时的大电流在这段控制线上感应出尖峰电压,触发了IO端口误动作。解决方案是重新布线,把控制线全部分离出来单独走线,同时在机械手IO输入端口前增加了RC滤波。从此之后这类莫名奇妙的自触发现象再也没出现过。

这个教训让我养成了一个习惯:所有项目图纸里控制信号线和动力线必须分槽走线,标注间距不小于20cm,尤其是变频器/伺服驱动器的输出线更不能与信号线并行。

6.2 检测误判率波动:打光、触发与判定阈值的配合

在线检测系统稳定运行半个月后,客户反馈NG率从原来的10%突然跳到了18%,而且时间集中在下午两点到四点之间。我一度怀疑是视觉算法有问题,但视觉软件的日志显示判定逻辑和参数没有任何变化。后来我蹲在现场看了半天,终于找到了原因——阳光。

车间下午的阳光会照到检测工位附近,环境光强变化导致产品表面的光照条件改变,视觉提取的特征值和标准模板产生了偏差。解决办法有三个:一是给检测工位加装遮光罩,彻底隔断自然光对打光系统的干扰;二是把视觉系统每次触发时的光照值也写入日志,便于判断是否环境光异常;三是在视觉软件里把判定的灰度阈值从固定值改成了自适应范围。

这让我意识到在线检测系统的调试不是调完就完事,必须考虑车间光环境、设备温度漂移、产品批次差异这些"非程序因素"。我在程序里加了一条"检测结果趋势记录"功能,把每一件产品的检测结果和检测时间都在HMI里缓存下来,客户在发现NG率持续偏高时可以回看整个时间段的检测状况,判断是设备问题还是来料问题。

6.3 收料堆叠错位:机械、程序与HMI三方配合

客户试运行第四天,OK料箱里的产品出现了不规则的堆叠错位现象,最高的一摞几乎要倒,但满料光电传感器一直没有触发报警。原因是OK料箱的容量比设计时预估的大,实际堆到临界高度时产品已经明显倾斜,光电传感器的光路却被最高处的产品挡住了,导致传感器一直输出正常信号。

这个问题的解法不是简单地抬高传感器或增加传感器数量,而是从机械、程序、HMI三个层面协同解决。机械层是将OK料箱内部加了四根导向柱,产品落到位后会被限制在立柱范围内,堆叠始终保持整齐;程序层是把"倾倒预警"逻辑做成两条:满料计数第一次到达上限的90%时提前亮黄灯提醒操作员准备换箱,第二次到达上限时自动暂停设备;HMI层是设置了一个"料箱已清空"确认按钮,操作员换箱后必须点确认,设备才会继续运行。

这个案例充分说明,在线检测收料项目里很多问题的根源不在单一环节,而是机械精度、电气逻辑和操作员行为三者的交叉地带。排查问题时如果只盯着自己负责的部分,往往找不到真正的原因。

写在最后:从图纸到稳定运行的几点经验

这套设备从出图到稳定运行前后经历了大约三周的现场调试。我个人最深刻的体会是:一套完整的自动化案例程序,IO表的设计质量决定了项目一半的成败。IO分配合理,电气图纸、PLC程序、HMI画面之间自然就顺了;IO分配混乱,后面每一步都在为前面的仓促买单。

还有一个值得分享的小技巧:程序里所有给机械手的请求信号,都建议加一段10到50毫秒的稳定脉冲时间,不要用单纯的SET/RSET指令。原因前面写过,两个控制器的IO扫描周期存在差异,信号太短会导致对方读不到,信号粘滞又会导致下一次握手失效,适当加脉冲宽度是低成本高回报的做法。

这个项目的检测和收料逻辑已经比较通用,如果后续要扩展功能,比如增加二维码追溯、接入MES系统、增加多品种配方自动切换,现有架构上的FX5U以太网口和机械手总线接口都留有足够的扩展空间,照着原来的IO表和新需求扩展即可。设备运行大半年后的整体状态也稳定,基本达到了预期效果。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询