1.入口处理：

在托盘 / 料箱在入口入库时，经过读码器， 系统判断两件事情：
a.托盘/ 料箱条码是否有任务，如果没任务，就近剔出口剔除 ;
b.查看该条码是否在立库货架的某个货位上，如果不在，说明可以正常入库；
如果在，可能有两种情况：
1.该条码确实在货架上存在，是人为打印重复条码导致；这种情况不允许入库 , 就近剔出口剔除；
2.有可能该条码在对应货位的堆垛机上出过库，但是当时是堆垛机出了 故障没有给出库完成报告，人为的把东西取出来，这时候，虽然条码仍然在货架上，但是该货位的状态应该是 “出库中 ”，这种情况我们就可以人为当时这个条码已经确定出过库了，就把那个货位释放，同时允许其 继续入库；
2. 进入堆垛机入库站台前处理：
进入堆垛机入口前最近的那个读码器，系统给托盘 / 料箱分配去哪一台堆垛机 ( 不分配具体货位，只是指示去那个堆垛机 ) ；
分配原则：
1.总原则是 N台堆垛机轮流分配 ;
2.在分配的那个时刻，在轮流分配的基础上把当时发生故障的堆垛机的优先级放到最低 ( 除非所有堆垛机都有故障，才有可能分配到 )；
3.对于快爆仓的 ( 即两侧货架快满的 ) 那些堆垛机 ( 比如可用货位很少， 只有不到 40 个)，对于这类堆垛机，把入库优先级降到第二低；
而且如果所有的堆垛机都全部快爆仓了，那就取消轮流原则，那个可用货位多，就分配给谁；
因为这时候货位紧张是最主要矛盾，爆仓危险很大了，已经顾不上轮流分配的运作效率问题了；
4.把入库站台上已经有货物的堆垛机的优先级设置为次第三低 ( 这样优先入库站台上为空的堆垛机入库，降低入库站台上有多个托盘 / 料箱的概率，防止入口被堵）；
3.到达入库站台处理：
托盘/ 料箱到达入库站台，系统将条码位置记录下来，同时通过 Socket
给对应的堆垛机控制系统一个消息，提醒堆垛机动作；
如果条码到达的位置不一致，系统提醒条码应该去那里，实际却到了那里，也不做任何其他处理；
4.堆垛机入库：
堆垛机接收到输送机系统发送的提醒信息，搜索满足条件的任务 , 因为入库站台上有条码，所以必须要动作，否者入库站台要被堵住；
正常流程：
条码有入库任务，堆垛机分配货位： 分配原则：
1.根据货架的每一个货位长度和高度 , 堆垛机的横向速度 / 横向速度，入库口的坐标 ( 未必是 (1,1), 可能在中间 ) 等条件获取从入库口到可用的货位中运行时间最少的那个货位作 为分配货位；
2.如果货位满，就分配就近的出库站台；
货位分配后，系统立马给堆垛机发送入库动作命令； 可能出现的异常流程：
1.条码异常：
1.条码未读取 , 系统生成 1 个特殊条码的入库任务，从入库站到到出库站台 ( 不入库 ) ，每个堆垛机的入库读不到条码时生成的特殊条码都不一样，以防止混淆；
2.条码和库存中某个条码重复，由于各个货位上的条码的唯一性，这个条码也要变成一个特殊条码，从入库站台到出库站台 ( 不入库 )；
3.条码和其他正在工作的堆垛机操作的条码重复，也要将该条码设置成一个特殊条码，从入库站台到出库站台 ( 不入库 ) ；
对于上面这 3 种异常，为什么要把真实条码变成一个条码进行操作，因为条码作为堆垛机任务调用的一个非常关键的识别信息，为了避免数据矛盾，从而把后续矛盾的条码设置成特殊值，
把不同条码的物件区分出来；
2. 出库站台卡住 :
如果出库站台暂时卡住 ( 机械故障，或者主线堵死 ) ，出库站台的托盘 /
料箱停在出库站台暂时无法离开，
这时候，对于从入库站台直接到出库站台的任务 , 因为出库站台堵住， 系统会把入库站台的托盘 / 料箱暂时入库到货架里面，等出库站台什么
时候可用了，再立马出库；
入库原则特点说明：
1. 入库货位不是一下子分配好的；而是在 “运动 ”中逐步分配的，在进入堆垛机前只是分配去那个巷道，而不指明具体货位；只有当货物到达堆 垛机入口，并且堆垛机可以调度的时候，
才分配货位和发送动作指令一口气完成； 为什么不是一下子分配好货位？
原因：
1.一下子分配好，万一入库到半途上 “反悔 ”，人工干预把货物等原因拿走，就会把分配中的货位 “牺牲 ”掉；现在是到达堆垛机入口才分配，就避免了中途异常导致的货位不能释放的现象；
2.分配货位是需要动态考虑堆垛机状态的，所以尽量晚分配，才尽可能的接近实时的真实状态；
3.降低对电控系统的跟踪要求，如果一下子分配好货位，万一货物跟踪错了巷道，就要做异常处理或者从入口直接到出口，重新做入库；
而我们动态分配，就没这个问题，即使设备走错位置，系统会 “将错就错”，在当前巷道分配货位入库；甚至可以这样理解：上位系统给电控
分配的巷道只是一个计划，电控甚至可以不按我们系统提供的巷道 ( 比如万一那个巷道的入口故障等 ) 去运作；这样就大大增加了灵活行；
4.重新分配的 “轻量级 ”处理，如果一下子分配好目标货位，一旦涉及到半途重新分配，比如半途上读码器读取条码时候，发现目标货位对应的堆垛机发生故障，这就需要重新分配新货位，释放掉旧的已分配的货 位；而我们系统到在半途上只是分配好去那个巷道，并没有确定去那个货位，这样重分配的工作量就小很多；
2.堆垛机的负载均衡，总原则是轮流，同时配合 考虑到入口满，堆垛机异常，堆垛机货位是否接近爆仓等条件综合考虑；
为什么不考虑按照不同物料在各个巷道里做均匀分配？ 原因：
很多系统都喜欢采用各个不同物料在各个堆垛机巷道里均匀分配的原则, 感觉这样就可以让堆垛机出库的时候，让所有堆垛机同时均匀出库；
乍一看，这样很 “合理 ”，但是仔细想想运作，会有以下问题：
如果按照物料的托盘 / 料箱库存个数做均匀巷道之间的分配，必然会导致入库时，各个堆垛机的轮训原则遭到破坏，常见有两种情况会破坏轮训：
a.比如 1 号堆垛机发送了故障，修复花了一小时，这一小时内，所有入库的A物料只能均匀分配到其他巷道的堆垛机，当 1 号堆垛机修复好后，
就必然会导致之后继续入库的 A物料集中往 1 号堆垛机入库，严重破坏轮询原则，负载不均，容易引起主线堵塞；
b.出库的时候，如果按照先进先出或者手工选择等原则，不能保证出库
的托盘 / 料箱同时均匀的从各个堆垛机出来，可能 1 号机出 20 托， 2 号机出15 托；
那么再有新的该物料入库的时候，就会集中先入 1 号堆垛机； 这样轮询负载均衡的大原则基本就保证不了；
所以宏观上严格轮询入库，不但考虑了运作效率，也同样兼顾了物料的均匀分配 ( 虽然不能绝对保证 )，即便出现 A物料在 1 号堆垛机入库很多，其他的很少，也没关系，因为这样 1 号堆垛机出库的概率也会更高，总的宏观上来说，各个巷道里的物料是差不多的；
3.每台堆垛机货位的分配，以最短运作时间为分配依据为什么不以最短距离作为分配原则？
原因：最短路径分配，样子像一个圆弧，但提高效率的本质是运作时间短，而不是距离短，所以要考虑堆垛机货叉横向和纵向动作时间最长的那个作为运作 ( 木桶效应 ) ；
获取一个入库时间最短的货位作为目标货位二佛涅槃原则； 为什么不对不同物料按区域划分？
原因：自动化仓库是个黑匣子，入出库作业不需要人工查找，所以没必要把不同物料分区域管理；
为什么不按 ABC 分类，考虑常用的物料优先放在前面，不常用的优先放后面？
原因：不同物料作业可能是动态的，所以 ABC 分类也是动态的，即便系统动态根据历史作业量动态调整 ABC 属性，也往往不能判断准确，
让那些频率低的物料入库到后面的列；理论上可能会提高些效率，但是
提高有限，而且控制不好，分析的不准确，效率反而不如不考虑；
比如：仓库货位利用率如果很低，就算是 C类不常用的物料，一下子放到后面的列，反而浪费很多；
仓库货位利用率如果很高，货位一直是快满的状态，基本 A类的也照样被迫放到后列；
所以不考虑 ABC 分类的优先前后防止的方法，折衷下来是一种 “性价比”比较高的方法；
堆垛机的入出库调度中所设计的几个大的环节，我都写出来了，可能也有遗漏；
这也是我对围绕堆垛机为中心的立体库的运作控制的主要控制点： 基本原则是：
1.配置性的路径，任意位置都能检索到目标位置；哪怕设备走错了；就想有地图，哪怕公交车坐过了，照样能够通过其他路径到达目的地；
2.入库口不能堵死，哪怕是个没任务的托盘，必须让它从出口出来，如果出口暂时堵塞，就暂时入库，出口什么时候通了，再出来；
3.货位分配最后完成，很多人都是 RF组盘的时候，就做货位生成锁定，这样做比较死，而且异常处理不方便；我这边就算托盘到达入库口也不分配，只有等堆垛机自身条件也满足了，才分配，也就是分配货位
和堆垛机动作是一个事务，这样到 " 最后关头 " 才分配有助于异常的处理和设备的优化；
4.注重货位的平均和效率的平衡；
5.对出库流量控制做了重点的配置管理；
堆垛机出库原则；
1. 出库时机触发：
1.正常情况下 , 每台堆垛机 1 分钟触发一次扫描任务的事件；如果条件满足，就执行动作，不满足就等下一分钟继续判断 ;
2.WCS 给堆垛机发送任务是单条的，也就是做完一个再做下一个；当一个堆垛机当前多个排队任务的时候，完成一个，马上触发下一个任务
2.当相关设备状态发生变化时，马上出发扫描任务事件；比如：堆垛机状态离线变在线，异常变正常，对应的出库站台不可用变可用；
3.当WMS 下发出库任务到接口的时候 , 接口程序会自动发消息提醒对应的堆垛机控制系统，马上触发扫描任务事件；
4.流量控制的目标位置，每完成一个任务，寻找满足下面两个条件的第一个任务对应的堆垛机，给其发送消息提醒，马上触发扫描任务事件；
a.待出库任务中最优先的
b.对应堆垛机可以调度的 ( 堆垛机状态正常 , 没有执行其他任务待机状态)
所以，出库触发事件在不忙的时候 ,1 分钟触发一次； 但是任何相关的设备状态或业务状态发生变化都会触发堆垛机获取任务的事件；
这样设计的巧妙在于：
1.不做那种传统的类似 1 秒中扫描一次任务触发方式；这样太浪费资源，因为大部分时候是扫描不到任务的；反而消耗了很大资源；
2.各种相关条件变化都导致触发，实时性得到了保障，实际效果，一般在任务下达后或者连续任务间隔都不超过半秒钟；
3.为什么设计每分钟触发一次扫描事件，就是防止万一程序触发遗漏， 或者网络不好的时候，各个系统之间的消息触发丢失，还能保证系统正常走下去；
(最坏的可能也就是浪费 1 分钟，但不至于系统停滞 )；当让 1 分钟是可设置的；
2. 出库动作条件的判断：
这是一个重点，条件要满足下面 3 个：
1.硬件自身满足：
a.WCS 系统和堆垛机通讯正常；
b.堆垛机在线；
c.堆垛机当前没有异常；
d.对应的出库站台可用 ( 没有被堵住 );
2.目标位置流量控制满足：
很多时候 WMS 会批量把很多出库任务下发给 WCS 系统，但是 WCS 不能一口气把这些托盘 / 料箱全部出库，因为这样会有把整个线体堵死的风险；
尤其对于那些在线拣选又回库的托盘 / 料箱; 所有很多目标位置都有流量的控制，这个数量可以设定；
关于流量有以下三点：
a.目标位置的流量是指所有到达该位置的正在执行的托盘 / 料箱个数； 或者说堆垛机已经下架但是未完成的任务；所以很多时候如果看到目标 位置上不到额定控制数量，很可能是还有很多正在线路上继续前进；
b.如果因为线路堵塞等原因，某个托盘 / 料箱兜了 3 圈( 可设置 ) 后剔出， 那么这个托盘 / 料箱不作为计数；
c.万一存在时间很久的任务一直未结束 ( 比如是任务为确认 ) ，那么超过
3 天的数据就不作为计数；
3.各个堆垛机之间的任务顺序控制：
a.如果没有堆垛机之间的彼此约束：各个堆垛机的入出库任务是独自调 度的；所以有这种风险： 1 批出库任务，比如有 100 个料箱，分布在各个堆垛机里 ( 未必很均匀 ) ，理论上是按这些出库任务的生成顺序出库， 但是因为流量控制，某个时刻，当仅有一个流量可以放行的时候，如果 最优先的任务在 2 号堆垛机，但是这个时候可能 2 号机正在入库后者故障，这个机会就可能让给 1 号堆垛机；当 2 号堆垛机物理上满足出库条件时，因为流量满了，暂时不能出库；等再有一个流量放出的时候，系 统会优先触发 2 号机动作，但由于其他 10 多台堆垛机都同时在抢这个唯一的流量，所以往往事与愿违，优先级最高的那个任务不能及时出来；
b.所以每个堆垛机调度的时候，要 “看看 ”其他兄弟堆垛机是不是有比自己更优先的任务，如果有，就不要做相同目的地的任务，可以做入库或 者做去其他目的地的出库任务； 当然，如果优先级最高的出库任务对应的兄弟堆垛机正在忙其他活或者故障的时候，就不让了，也就是说， 只有在兄弟堆垛机有更高优先级的任务，并且空闲，才让出相同目的地 的出库机会；
这样设计的巧妙在于：
1.对于同一个目的地，尽量让其下发的任务，按照顺序执行 ( 由于线路问题，未必绝对顺序执行，但是不会出现先下发的任务等了很久不执
行，后下发的反而提前执行了 )；
2.对于正在工作中或异常中的堆垛机，不作为是否有优先任务的等待控制，主要是因为效率；这样逻辑顺序和设备效率都有所兼顾；