本文作者:烟火之旅

AGV叫料先进先出怎么落地?与WMS系统怎么联通?软硬件一体开发记精工智能

烟火之旅 2026-11-14 1507

软件最理想的运行环境是演示机。真实产线上跑的是网络波动、脏数据、临时改的需求,和屏幕前那台机器完全不是一回事。

十月,在某制造企业的AGV项目里,一个看似简单的问题让我重新思考了“功能完成”的标准:PDA生产领料时,AGV是否按照先进先出叫料?从操作上看,扫描单据、选择目的位置、点击呼叫,设备能够接到任务,流程似乎已经走通。但现场问的不是“能不能叫到料”,而是“叫的顺序对不对”。这两句话之间,隔着一条完整的业务链路,也隔着开发工程师对现场的理解。

wKgzfWr2aqaAMIM9AA0u4T1dOt4503.png

一、AGV叫料“能叫到料”,为什么还不算功能完成?

顺着PDA请求、后端选料和任务下发链路检查后,我们发现原有逻辑主要按照容器编码选择候选容器,没有依据生产日期或收料日期排序。也就是说,设备能接到任务,流程能跑完,但候选容器的先后顺序并不符合“先进先出”的业务要求。

这就是开发里最容易误判的地方:把“任务下发成功”当成“功能完成”。在演示环境里,只要PDA点得动、AGV动得了,看起来就是通了;到了真实仓库,业务人员关心的是先叫哪一箱、后叫哪一箱,旧料会不会压在新料后面,批次会不会因此混乱。能够叫到料,并不代表叫料顺序符合业务要求。

功能完成的第一个标准,不是接口返回成功,而是选择规则真正参与了候选容器的筛选。如果规则没有进入候选库存查询,没有影响容器选择,只是在代码里多了一个日期字段,那它就没有真正生效。开发要做的,是把业务语言翻译成系统里的排序键、过滤条件和异常分支,而不是停在“能跑通”。

二、“先进先出”落到容器和条码上,到底以哪个日期为准?

接下来要解决的,不只是增加一个日期排序。先进先出以生产日期还是收料日期为准?一个容器里有多个条码,生产日期不同时,又该用哪个日期代表这个容器?这些条件如果没有先确认,代码即使运行正常,也可能执行了另一套规则。

经过沟通,业务口径明确为按生产日期选料;同一容器存在不同生产日期的条码时,取其中最早的日期作为排序依据。随后,我们将日期带入候选库存查询和容器选择过程,同时保留原有的锁定、预约和重复呼叫排除条件。

这一步看起来是技术实现,实际是需求澄清。比如容器A001里有10月20日、10月22日两个条码,容器日期取10月20日;容器B009里有10月10日、10月18日两个条码,容器日期取10月10日。按最早生产日期排序,B009优先叫料,而不是看容器编码谁大谁小。这个例子只用于说明规则,不是现场数据。

“先进先出”听起来没有歧义,真正落到容器、条码和库存状态上,却需要逐项说明。排序键是什么、容器代表日期怎么取、锁定和预约的容器要不要排除、重复呼叫怎么处理,每一项都会改变最终选中的容器。把这些条件问清楚,实现和验证才有共同依据。精工智能数字化工厂的研发把现场当考场,在真实数据、真实操作习惯里把系统磨稳,而不是在办公室把功能做完就算交付。

三、回库完成之后,为什么原储位还留着容器信息?

同月处理的回库问题,让我看到了链路另一端的重要性。现场反馈,容器回库后,原储位仍保留着容器信息。沿着任务创建和完成回调检查,发现任务保存的来源位置类型,与回调识别具体储位时使用的内部类型不一致,导致原储位解绑步骤被跳过。

容器已经移动,系统中的位置关系却没有同步更新。这意味着设备动作完成后,业务数据仍可能停留在上一个状态,进而影响后续储位分配和任务判断。因此,排查不能停在“任务已经完成”,还要继续确认原储位是否释放、目标位置是否正确绑定。

修复时,我们既处理了新任务的位置类型转换,也兼顾了修复前已下发、尚未完成的任务。但已经完成的历史任务,不会因为更新代码而自动重放。遗留绑定仍需核对容器实际位置后单独处理。新逻辑修复和历史数据处理,需要分别说明、分别验证。

这类问题最能说明“功能完成”的另一层含义:设备动作完成只是开始,业务数据同步更新才算闭环。开发如果只看任务状态,不看储位与容器的绑定关系,现场就会出现在制品已经走了、系统里还占着位置的情况。后续储位分配、任务判断、库存查询都会受影响。把新逻辑和历史数据分开处理,是对现场负责,也是对后续运维负责。

wKgzfmr2a2yAJv1mAAIJDfG9qaU629.png

四、AI能帮你找代码,为什么最后还要回到现场核对?

在这些工作中,我使用AI辅助梳理调用链、比较字段含义和检查修改影响。它帮助我更快找到相关代码,也让我更清楚地认识到,工具分析必须与现场事实相互核对。业务口径需要沟通确认,容器位置需要现场核实,修改方案需要经过验证,每一步都有自己的依据。

验证时,我重点检查了一个场景:容器编码较小,但物料生产日期较新;另一个容器编码较大,但物料生产日期较早。只有后者优先被选中,才能说明新规则真正参与了选择。目前相关模块编译和独立选料检查已通过,实际叫料效果仍需结合现场库存与AGV任务联调确认。

这也是本地检查和现场联调的边界。编译通过、独立选料检查通过,证明代码逻辑在给定条件下成立;现场库存是否复杂、任务是否并发、异常容器是否被排除,还要在真实环境里验证。开发不能把本地验证当成现场结论,也不能把AI分析当成业务口径。工具能帮你找代码,但容器实际在哪、业务到底按哪个日期算,必须回到现场和业务人员那里确认。

回顾十月,我对“功能完成”有了更具体的理解:选料规则要真正影响容器选择,任务完成后要正确更新位置关系,修复要考虑已有任务,验证也要明确本地检查与现场联调的边界。后续面对“先进先出”“回库完成”这样的需求描述,我会多追问一步:具体以什么为准,由哪个环节保证,又用什么场景证明它已经生效。把这些答案提前写进需求和验证记录,让每一次问题处理都留下可复用的经验,是这个月AGV项目带给我的收获。

精工智能数字化工厂的研发,把现场当考场——在真实数据、真实网络、真实操作习惯里把系统磨稳,而不是在办公室把功能做完就算交付。

AGV叫料和回库这类功能,看起来是仓库里的“小动作”,实际决定现场愿不愿意用、敢不敢把库存交给系统。制造业数字化比的不是功能清单长短,而是业务规则能不能走完整条链路。

​

审核编辑 黄宇