CNEN

您当前的位置:首页 > 新闻资讯 > 行业资讯 > 巷道堆垛机货位分配 和 入库调度 的优化

巷道堆垛机货位分配 和 入库调度 的优化

来源: 上海上柏    点击量:

      巷道式堆垛机是由叉车、桥式堆垛机演变而来的。桥式堆垛机由于桥架笨重因而运行速度受到很大的限制,它仅适用于出入库频率不高或存放长形原材料和笨重货物的仓库。巷道堆垛机的主要用途是在高层货架的巷道内来回穿梭运行,将位于巷道口的货物存入货格;或者,取出货格内的货物运送到巷道口。
      立体库关键的点:库存不要乱;要想库存不乱,关键的是入库要准确,因为“病从口入”;要想入库准确,有两个节点比较关键:
1.分配货位时机;
2.托盘到达入库口的时候,如何调度;
先说第1点:
分配货位的时机
这个时机处理,经过这些年,一共经历了6个阶段:
1.入库托盘登记时分配:
      在托盘码垛(货物和物料绑定)的时候,把具体的排列层的位置预先分配好,并且在货位表的该位置上做一个锁的标记,以免其他托盘登记的时候,再次分配到该货位上;
2.过第一个读码器(BCR)时分配:
      因为操作员可能在线下登记,所以登记时分配货位,有个很大的风险,万一操作员没有把该托盘放到线体上就拿走了,这个货位因为被预定了,就死掉了,永远不会被释放了;
所以在托盘进过第一个BCR的时候,再分配,托盘被中途拿走的概率就低很多了;
3.到达堆垛机入口时分配:
      过了第一个BCR就把货位分配号感觉太“死”了,万一输送线上有多个BCR,托盘经过第二个BCR的时候,发现事先分配的那个巷道的堆垛机出了故障,就要重新分配,重新分配就需要释放原来的,实现起来比较麻烦;所以过第一个BCR只是分配巷道,而不分配具体的货位;这样托盘经过其他BCR的时候,如果发现对应的堆垛机故障或线路拥堵,可以更换巷道;
      当托盘到达堆垛机入口的时候,再分配货位,这样就避免了重复分配的复杂度,简化了程序实现难度,而且也更灵活;如果电控“不慎”跟踪错误,或者人工手动将托盘送到入口,只要将输送机上的托盘号数据写正确,就可以正常入库;
4.到达入口并且堆垛机空闲时分配:
      托盘虽然到达入口了,但是也许堆垛机此刻正在做其他任务,这些任务可能做到一半的堆垛机就发生故障,这时候,就可能人工将该托盘转移到其他堆垛机入口,这样就导致已经分配的货位死在里面;
当然,可以人自动释放该货位,不过处理起来比较麻烦,要做很多判断;
所以等堆垛机空闲了,万事俱备,不欠东风,货位分配和调度堆垛机动作做在一起,这样就安全很多了;
5.到达入口并且堆垛机空闲时分配(不锁住预分配货位):
      就算巷道堆垛机动作时候的分配货位,在堆垛机取货的时候,也可能发生故障,也可能人工把托盘拿到其他堆垛机上,同样会造成已经分配的货位死在里面,当然也可以做自动释放,但是还是程序麻烦啊,
      所以干脆分配货位的时候,就不用锁货位了,这样终于感觉世界安静了,开始感觉有风险,因为分配货位要预先锁住的做法已经延续很多年了,突然取消自己都不适应,没有锁感觉不安全,万一两个托盘分配到到一个货位怎么办?但是你是在调度的时刻在分配的,这个时机也是单一的,所以细想一下,也是没有风险的;
      无论出现什么异常,只要入库没有完成,中途出现任何异常,都不需要做“撤销”处理,大家都知道,逆向流程很多时候要比正向流程复杂很多;如今,在任何设备异常情况下,入库的分配都不管逆向的处理,是不是感觉“松”了一个口气;
6.堆垛机放货的分配(同样不锁住预分配货位):
有些堆垛机的控制模式,是分段的,取货的时候,给堆垛机发一个取货指令,放货的时候,再给堆垛机发一个放货指令;
       这样,只要发现入口有货,不管三七二十一,先让堆垛机取到再说,取货完成时,再给托盘分配一个货位,这样分配的逻辑放到放货的动作去做了;
       因为取货的逻辑比较复杂,要考虑各种硬件设备状态和任务的情况综合考虑选取一个任务执行,而放货的逻辑相对就比较简单,所以把货位分配放到放货逻辑中,程序复杂度也更降低了;
同样,只要堆垛机动作没做完,中途任何故障,都不需要做任何逻辑上的撤销处理;
      说了上面6个阶段,其实主要想说的,就是分配货位不做锁的处理会让系统在异常的时候,更加灵活的处理;这是切肤之痛,以前几乎每个项目都遇到“已分配”的货位烂在系统里很久,原因各种各样,
      之前,我都做“智能”的判断是否“自动”释放,这个逻辑非常复杂的,当时我的思路是:托盘经过BCR的时候,判断是否已经分配了货位(理论上是不可能的,可能人工干预在堆垛机入口因为故障拿走),
      如果有就“可能”要释放,为什么是“可能”,因为客户的托盘条码有可能贴重复了,要分清李逵还时李鬼很麻烦,我的判断原则是如果半小时内,该托盘在之前的入口出现过堆垛机或输送机的故障,而且按照线路顺序,托盘确实可能走到该BCR,这就释放之前货位,但是这也是取得“高概率”事件;而且程序写起来挺复杂的;所以预分配货位在异常情况下的释放,一直是困扰我的一个难题;
当然你可以说,让客户自己手动去释放,这是一个偷懒的做法;把问题抛给客户,出了问题算客户的,这样不地道;
这就像:你跟别人借钱,不写借条(不做货位锁定),等到期了,没能力偿还,就可以耍赖;
再说第2点:
托盘到达入库口的时候,如何调度
1.以前的做法:
通过任务调度,如果托盘到达入口,硬件满足了,但是万一这个托盘没有任务数据,就不能调度;
       比如你在入口随便放一个没有任务的托盘号,堆垛机时不会调度的,这就有问题了,堆垛机的调度关键的是要做“永动机”,也就是在任何情况下,都不能让入口堵住
所以:对于托盘到达堆垛机入口的时候,当系统发现时一个“莫名其妙”的托盘的时候,就需要生成虚拟任务,否者堆垛机没法调度;
这个虚拟任务生成起来,甚是麻烦:
1.要捕获托盘到达入口的事件,才能知道这个消息;如果和PLC交互没做好,这个事件可能遗漏;
2.生成的虚拟任务,有的时候不能使用真实的PLC提供的条码,因为万一这个条码的任务正在被其他堆垛机调度,会导致用一个托盘在两个位置(这种情原因:1.电控跟踪问题;2托盘条码重复),
甚至该条码在货架上已经有了,都要生成虚拟任务,所以这就很麻烦;
对于这种虚拟任务,我统计过,常见的有4种:
1.条码未识别,很多人想用99999之类的固定条码生成虚拟任务,这是不行的,因为同时两个站台都可能未识别,同一个托盘同时只能有一个被调度的任务;
2.库存内已经有的条码;
3. 多个入库站台的条码同时重复;
4. 当前入口托盘和其他正在调度的堆垛机的条码重复;
这几种情况,就要考虑做虚拟任务,避开冲突,甚至麻烦;
2.现在的做法:
以前托盘在入口的时候,既然要可能生成虚拟任务,以满足让堆垛机调度;
       这种方法,实在复杂,当然你可以说,托盘在入口的时候,没有任务或者有异常或冲突的任务的时候,就让托盘停着不动,让人工干预,这是懒人的做法;
现在思路又变了,入库调度,不看任务,只看入口的物理跟踪的托盘;
只要入口有条码并且可入,那么就必须调度;
如果是半循环的堆垛机,就直接去取货,取到后,如果满足条件,就正常分配货位放货,否者调度到出库站台;
如果是全循环的巷道堆垛机,就匹配该托盘任务,匹配正常,就正常运作,匹配失败(无任务,冲突等)就给出库站台,然后发出from to 指令;
现在这个做法,就更贴切物理条件,只要入口有货,就必然调度,而不是必须要有任务;
虽然也是很小的改进,但是彻底解放了:托盘到达入口站台的逻辑处理;
以前这个地方要做很多判断,要可能生成虚拟任务,虚拟任务生成了,如果在执行失败,该虚拟任务就不能被删除;导致虚拟任务的残留;
所以换一个思路,把以任务为基准的入库调度改成 以入口跟踪条码的硬件条件为基准,一些异常的处理,就豁然开朗了。