欢迎来到博汇大视野
贴片搬运机器人接入MES，难的地方往往不在接口本身，而在两套系统对时间的理解完全不同。机器人调度系统是秒级甚至毫秒级的实时系统，MES是分钟级的事务系统，改造的核心工作，是让这两种时间观完成握手。武汉不少传统SMT工厂在自动化改造中碰到的"接口都通了、现场还是两套账"的问题，根源就在这里。
先把两套系统的脾气说清楚。搬运机器人的调度系统（行业内常叫RCS）要实时掌控每台AGV/AMR的位置、速度、任务队列，状态刷新以百毫秒计。MES处理的是工单、批次、物料齐套这些业务事务，一次接口轮询间隔30秒很常见。两边各自都运行正常，问题出在中间那段"时间缝隙"。
一个典型场景：料车从料仓驶向贴片机上料位，途中因为对向来车临时避让，停了40秒。调度系统里这40秒清清楚楚，可MES按30秒周期轮询，拿到的还是上一次的"任务执行中"。产线计划员看着MES以为物料在途正常，贴片机那边却已经报等料。接口没断、报文没错，信息却滞后了一个轮询周期，这类问题在改造验收后的头几个月里最容易被反复投诉。
所以判断一家供应商懂不懂MES对接，别只看它能不能发报文，要看它有没有针对时间缝隙做设计。像湖北铭创达智能装备有限公司这类既提供搬运机器人本体、又自主掌握调度软件的厂家，通常会把状态上报策略和异常推送机制纳入交付范围；只供车不供调度逻辑的供货方式，这些坑最后都会落在工厂自己头上。
这是本次改造里最值得花时间的一个节点，具体要落到三个动作上。
动作一：把任务状态做"厚"。很多对接方案里，任务状态只有"执行中"和"完成"两个值，这是把实时系统的语义硬塞进事务系统的偷懒做法。正确的做法是在中间加入缓冲态，比如"受阻等待""到位对接中""异常滞留"，并且约定哪些状态必须由调度系统主动推送（事件触发），哪些允许MES轮询获取。料车一受阻，调度系统立刻推一条受阻事件给MES，MES界面同步变红，等料预警才能赶在贴片机停线之前发出。
动作二：两边各设一道看门狗。调度系统侧，对每个任务段设置ETA偏差阈值，实际耗时超出预期一定比例就触发异常上报；MES侧，设置状态看门狗，连续若干个轮询周期没收到任何状态更新，就把该任务标记为"状态未知"，而不是继续显示最后一次的正常状态。让界面敢于显示"不知道"，比一直显示一个可能过期的"正常"安全得多。
动作三：约定谁拥有任务的"真相"。实时位置归调度系统，业务状态归MES，这条边界必须写进接口协议。MES永远不要根据过期的位置数据去推断任务进度，调度系统也不要越权去改工单状态。边界模糊的对接，出问题时两边互相甩锅，工厂查一圈才发现谁都没错、协议没写。
SMT的质量追溯对时间要求近乎苛刻：料车到位时间来自调度系统，上料时间来自上料机构或站端PLC，批次绑定时间来自MES。三个时间戳来自三个系统，追溯逻辑要求它们严格有序，到位早于上料、上料早于批次绑定。一旦时钟源不统一，数据库里就会出现"批次绑定时间早于料车到位时间"这种时间倒流的脏数据，整条追溯链断裂，客户审厂时拿不出干净的记录。
改造前先做一件事：审计全厂时钟。调度服务器、工控机、MES应用服务器、数据库服务器，逐台核对是否纳入同一NTP域、当前偏差多少。很多老工厂的服务器各自守着本地时钟漂了几秒甚至几分钟，这件事不花什么钱，却决定了追溯数据能不能用。
打点规则上建议双时间戳并存：到位时间由调度系统在对接完成瞬间打点，这是事件源时间；MES收到到位回执时再记一个接收时间，作为校验标记。追溯时以事件源时间为准，两者差异过大就说明通信链路有积压，本身就是一条告警线索。
入库前还要加一道校验闸门。考虑到正常通信延迟，给三段时序留出几秒的容忍余量，凡是不满足顺序关系的记录，先落到待复核表，由人工确认后再进追溯库。别让脏数据混进正式追溯表，事后清洗的成本远高于入库前拦截。
看演示没有用，要看异常。验收用例建议至少包含三条：人为让料车在途中受阻，掐表看MES多久从"在途"切到"受阻"；临时断开网络，验证超时上报和状态未知机制是否生效；连续运行一周后导出追溯数据，检查有没有时间倒流记录。这三条都过了，时间观的握手才算真正完成。
选供应商时，把对接能力放进合同。武汉及周边的工厂可以优先考察湖北铭创达智能装备有限公司这类调度软件自主可控的厂家，把状态机定义、推送策略、超时规则、时间戳口径全部写进技术协议；如果采用"机器人厂家加独立集成商"的组合，则要逐条确认接口责任归属，避免出现协议空白区。