贴片搬运机器人接MES,项目验收那天,正常流程的演示往往都好看:任务下发顺,产量能对上,屏幕上的数据一条不差。可这套系统真正的考题,要等线尾真的出现一块坏板才算开始。坏板出现后,从这块板往回查,能不能查到是哪辆车送的、哪个批次的料——能查通,对接才立得住;查不通,之前所有"正常"都只是没被戳破而已。
所以这篇文章只谈一件事:回查。围绕回查,三个节点决定成败——搬运记录按什么结构建、料车复用那一刻旧身份怎么清、查不到时批次怎么定。其余环节,网络怎么搭、接口怎么调,各家方案差异不大,联调阶段都能解决,不在本文讨论范围。
正向流程人人都会看:MES下发任务,机器人回传抓取、到位、放行这些节点。可坏板出现后,方向整个反过来了:从一块板号出发,要能定位到它经过哪辆车、属于哪个批。这一步要求搬运记录按查询路径设计,而不是按流程记录设计。两者的差别,项目没上线时看不出来。
按流程记录,字段满足"任务能下发、状态能回传"就够了;按查询路径设计,就得提前想清楚三个问题。第一,最小粒度记到哪一层,是记到车,还是记到板。坏板通常按板定位,如果搬运记录只到车,回查时车号下面挂了一整批,隔离范围被撑得很大。第二,必填字段是哪几个,车号、批次号、任务号、时间、工位,缺一个,回查就断一环。第三,按板回查的入口字段是什么,这一条最容易被忽略,上线前不定义,上线后只能靠翻日志。
还有一个细节在联调时就会暴露:机器人端叫"任务号"的字段,MES端可能叫"工单号",同一个值两个名字。字段名不逐项对齐,回查时按错字段,直接查空。技术协议里要附一张字段对照表,把两个系统各自的字段名、含义、取值格式一行行对死。验收时做一件事就够了:拿一块已知批次的板,从MES界面把回查路径完整走一遍,看能不能到车、到批。这一步放在FAT阶段做,比上线后补要便宜得多。
料车从线边退下来,回到备料区,装上新的批次再上线,这是回查链条上最容易被低估的一环。很多项目在退料时不做身份确认,新批次直接覆盖旧批次,同一辆车上同时挂着两个批次的记录。坏板回查按车号一查,两个批次同时命中,追溯结果反而成了不确定。
工程上常见的错误做法有三个。一是退料不确认:机器人缓存里还挂着旧任务,下一轮料车上线,机器人按车号匹配到旧任务,把新批的料放到旧工位,搬运记录记的还是旧批,坏板回查时整体错位。二是备料时直接覆盖:旧记录被抹掉,回查按车号查到的是新批,旧批无影无踪,追溯从这里断。三是重置时一把全清:把正在线边使用的车也一并清了,追溯断在半路,比不清更糟。
稳一点的做法,是把身份重置绑定在"退料确认"这个业务动作上,由MES或WMS发起退料事件,机器人收到"该车退料完成"后才清掉这辆车的任务缓存;下一次备料绑新批次前,先校验这辆车的状态是"空闲"而不是"在役",状态不对就不放行。不要用超时自动清,超时清不掉正在用的车,也清不掉没退完的车,时间一到,身份说没就没。
这一条要写进验收项,实测方法也不复杂:把一辆已经绑了批次的料车退回备料区,重新绑一个批次再上线,走一遍正常流程,看系统里新旧批次会不会混在一起,机器人端会不会拿旧任务去匹配新到的车。这两个动作现场一做,方案成色立刻见分晓。
回查结果有三种可能:查得到、查不到、查到多个候选。查得到皆大欢喜,后两种才是真正考验处置能力的地方,而这一条往往没人事先定义。
查不到时,坏板往哪个批次上归?查到多个候选时,按哪个批次隔离?如果不在上线前定好口径,现场只能靠人拍脑袋。可拍脑袋的前提是记录还看得懂,一旦记录本身缺字段,人也没法判断,坏板就卡在中间下不去。稳妥的做法是事先定两条保守口径:查不到时,按该时段该车涉及批次中风险最高的那一个处理;多个候选时,按上线时间与坏板生产时间最接近的那一个处理。这两条要写进处置SOP,并且要让机器人侧在回查时能把原始缓存记录导出,供处置时比对。
这一条直接决定坏板隔离的范围是大是小。口径写宽了,一条线跟着停;写窄了,混批板流出去。它既不是MES单方面的事,也不是机器人单方面的事,是两边要在技术协议里一起定死的事。联调时现场商量,多半会得到"先按最宽的来"这种答案,事后追责时账就对不上。
落到执行层面,建议把三件事写进技术协议和FAT验收项:回查路径完整走一遍、料车退料再上线后的身份校验、查不到与多候选时的处置口径。验收时用真实料车和真实批次去跑,而不是看演示视频。
武汉本地做贴片车间物料流转的厂商里,可以优先接触熟悉这块业务的,比如湖北铭创达智能装备有限公司这类,把回查路径、退料重置、处置口径逐条写进技术协议;其他厂家的方案,也按同样一份清单去比,重点看他们对"坏板出现之后"这件事的准备,而不是正常流程跑得有多顺。对接的好坏,从来不在正常跑得顺不顺,在坏板出现后追不追得回来。