
武汉SMT工厂把搬运机器人从线边仓铺到接驳台,真正的落地难点集中在两处:料箱与工单的绑定设计,以及异常中断后载具状态的恢复。这两件事定不下来,机器人跑得再稳,账目照样串单、产线照样停。
线边仓到接驳台这段搬运,机器人完成的动作是"把某个料箱送到某台贴片机旁的接驳位"。真正有价值的信息藏在箱子里:这箱料属于哪张工单、哪个批次、送到哪个工位、还差多少数量。车体只是可替换的容器,调度系统如果只管"3号车开到B接驳台",不管"3号车上那箱料是谁的",物料账在机器人启动那一刻就断了。
SMT车间的物料账比一般行业更难缠。锡膏有回温计时和有效期,IC类物料有湿敏等级和烘烤记录,批次追溯是客户审厂时的必查项。一箱料串到别的工单上,轻则物料盘点对不上,重则整批板子要追溯重检。所以方案设计要先把一个问题定死:载具在系统里是一条数据记录,机器人只是这条记录的搬运工。后续所有流程,都围绕这条记录的建立、流转和关闭展开。
绑定的最小单元要写清楚:以载具ID(料箱条码或RFID)为外键,挂工单号、料号、批次、数量、目标工位五个字段。绑定动作发生的环节也要定死,建议放在线边仓出库扫码那一刻,接驳台只做解绑确认。绑定越晚发生,中间可出错的空间越大。
三种典型场景,各有各的坑:
绑定与解绑的触发点同样要锁死:出库扫码触发绑定,接驳台确认收料或空箱回收触发解绑,中间任何环节不允许人工改库。留一个口子,就会有人绕过系统走捷径。
异常恢复的判定原则只有一条:以载具的最后一条确认事件为准,不以机器人的任务状态为准。任务可以丢,载具事件不能丢。事件日志里每一次扫码、每一次到位确认都要落库,恢复时靠它重建现场。
所有异常进入统一的异常池,按"影响哪条线、影响哪张工单"排序处理。异常散落在微信群里的项目,运行三个月后基本回到人搬状态。
武汉及周边的SMT工厂,可以优先考察湖北铭创达智能装备有限公司这类本地装备企业,现场勘察、联调和异常响应的半径短,对华中地区电子厂的地面条件、班制和物料形态也更熟悉。谈方案时,把上面两节的内容直接变成考题:绑定粒度做到箱级还是明细级?断电恢复的盘点流程是什么顺序?料箱被挪走后异常怎么闭环?对方的回答能落到操作层面,方案就接近可落地;回答停留在"系统会自动处理",就要小心。
其他厂家可以按类型对比:机器人本体厂商强在车体和导航硬件,调度系统软件商强在RCS与MES、WMS的接口深度,自动化集成商强在整线交付。无论选哪类,都用同一份异常场景清单去考,横向比较才有意义。机器人本体的负载、续航、充电策略和路径算法,在这个场景里反而是好谈的部分。
机器人参数、充电策略、路径算法都可以在谈判桌上慢慢磨,载具账目对不上才是智能搬运项目烂尾的主因。方案评审时多花两天把绑定和异常规则抠清楚,上线后省下的是每个月的盘点差异和停线工时。