--- 颠覆传统的使用策略

一、BCR 的合理运用：

1.1 传统概念，BCR 的常见作用有 3 个：

 1.识别条码(或校正 PLC 跟踪的条码) 

 2.分配下一个去向； 

 3.任务完成确认；

     第一点是 BCR 的物理作用，这个是关键的； 第二第三点是 BCR 的逻辑作用； 现在我最大的感受是：BCR 的最大作用是其物理作用； 逻辑作用，未必全部需要用 BCR 实现。 BCR 实现有以下不好的地方： BCR 故障时，比如 BCR 自身问题，或者网线接触不良，网络不通等，BCR 的通讯信号不会上传给 WCS 系统;或者是 条码读取不到，反馈 noread; 

    我对 BCR 的应用策略 

1.一个动线的完整运作，往往会涉及多个 BCR，如果一个 BCR 没有做它该做的事情，后面的 BCR 会判断前面的作业有没有完成，如果没完成，就会把前面 BCR 的逻辑运算再做一遍；

2. 在 BCR 紧挨着的后面一段输送机上，通过 PLC 对托盘号的跟踪变更，判断前面的 BCR 的逻辑 运算知否执行，如果没有执行，就再触发一下前面 BCR 该做的逻辑运算；对于这个情况，我 后来突然想到，为什么不直接在这个 BCR 之后的输送机上做逻辑运算呢；这样即使前面的 BCR 因为信号没有上传，我们也能触发逻辑运算； 

3. 有的时候，某个 BCR 是最后一个环节，后面也没有输送机了，这就通过所在的输送机上的托 盘离开事件(即托盘号从有到无)触发；因为用 BCR 触发风险很大，主要是网络不好的时候，BCR 条码读取条码经常不会上传到 WCS；但是托盘离开输送机事件应该是百分之百能感应到的， 触发 WCS 和 PLC 通讯是相对稳定的，而且即使不稳定，WCS-PLC 是不停交互数据的，一次不 行还有下次，总不会漏掉通讯数据的； 但是 BCR 触发没有握手机制，只有一次机会，如果触 发没有上传就会拉倒； 

4. 由于条码磨损，BCR 安装位置角度不是最佳位置（这个是关键）等原因，BCR 读取不到条码， 反馈 noread 的概率不是一般的高；在这种“艰苦”的条件下，我们只能从软件上多动脑筋， 如果有 PLC 跟踪的地方就好办，因为这里的 BCR 本来就是启到一个校正条码的作用，换句话 说，这里没有 BCR 也无所谓； 所以这里，如果 BCR 反馈正确条码，那么就用该条码触发逻辑 运算，如果 BCR 反馈 noread，就用 PLC 跟踪的条码判断；这就是“尽信 BCR，不如无 BCR”； 

5. BCR 的逻辑运算的触发位置，其实往往是不佳的，我们常常用 BCR 来触发入库货位的分配， 如今看来，我觉得是一个误区； 特别是一段长长的输送线，只有一个 BCR，如果只是用 BCR 触发入库货位的分配，一个时机太早，就像刻舟求剑，等托盘到那个巷道口的时候，可能堆 垛机不可用，或者正在忙碌，怎么办？要么等，要么逗一圈在回来；第二，分配货位是个“团 体行为”我现在的策略是多点触发，“全民皆兵”，类似公司提出的“全民营业”；入库分配的 事情，是所有关键点的输送线触发信号和 BCR 共同完成的；就像 100 多年前甲午战争，北洋 水师就李鸿章一个人殚精竭虑，而日本是全民都在搞海军；一个人的力量和团体是没法抗衡 的；

二.逗圈线的合理调度的实现改进：

 上面这幅图，体现了两个思路：

 1. 协同多点作战；以前业务逻辑控制主要靠 BCR 触发，这样做有 2 个缺点：

 1）. 很多时候，我们需要多个触发点，这样就需要多个 BCR，但是实际上，就像我上面说的， BCR 的物理作用只是识别托盘号而已；作为我们的逻辑运算，未必只能在 BCR 里做；这个 定向思维可以调整； 

2）. BCR 的信号往往给的太提前，后面的状况谁也不能预知，所以必须动态调整，就像导弹一 样，必须能在所有关键点上进行导航；而不是一旦有问题，就必须兜一个大圈后，再重复 读 BCR 重分货位；线体忙的时候，兜圈太频繁了，经常一个托盘兜上 3,4 个圈，因为堆垛 机同时做入出库，当某个托盘快进入库口的时候，堆垛机在忙碌的概率非常高，这时候， 你让该托盘重新逗一圈，太奢侈了，应该让它去下一个堆垛机再去尝试入库；而且从公平 角度来说，也不合理；就比如，我们到龙之梦楼下老娘舅吃饭，排队轮到你的时候，突然 机器出故障或者换班了，这时候，我们应该有权利插队到隔壁的 POS 机最前面去购买，而 不是重头排到最后； 

所以协同作战后，BCR，入库口前的输送机时，入库站台，这 3 个人，各自做自己最合理的事情，

 1）. BCR 只是告诉托盘去哪个堆垛机，不说最终的货位，为什么这样，因为 BCR 说的只是一个计划，托盘 未必按照它的路线走，所以没必要把最终货位定下来，如果定下来，而托盘走到其他堆垛机，还要把 这个目标货位清除，很是麻烦，也没必要；

 2）. 托盘进入入库口前的输送机站台时，判断当前堆垛机忙碌或异常否，如果异常去下一个堆垛机；

3）. 托盘进入入库站台时，这时候分配最终货位，同时提醒堆垛机来取； 这样分工合理，整个线路做了最合理的安排；

 2. 不要刻舟求剑

     以前托盘一过 BCR 就分配货位，甚至任务一生成货位； 这样一来程序复杂，二来异常难以处理；

     托盘到什么位置，就只最下一步事情，不要把下下步的事情也做了；系统的后续状态本来 就是未知的，我们没有必要让系统做“先知”，把所有事情提前安排好； 

    这两天，我把这些思路全部调整了，感觉很好，具体效果，我想应该会有很大改观； 

主要体现在：

1）一些 BCR 即使不触发信号(或者说干脆 BCR 彻底坏了)，也不会影响业务和数据；

2）.入库再也不会频繁兜圈了；

3）异常也更灵活的处理了；

     其实这次思路的改变，是在做尚德项目的时候，就有了这样的多点控制的想法雏形，但是因 为WCS不是自己掌控，所以也不能要求别人做的太多；而且以前只能对电控修改PC通讯部分， 现在 PLC 的两个部分的通讯，对 WCS 全部开放，也增加了 WCS 的“唯所欲为”能力；

     尚德是一个大的兜圈线，比如分配托盘进入 3 号堆垛机，那么当托盘到达 3 号堆垛机前的 时候，万一堆垛机出现故障，就会死等，这样一来，后面的（4，5….15）那么多堆垛机对应的 线体都会死等；等的海枯石烂，必须让 3 号机恢复才能让整个线体畅通；而且真的 3 号机一 时半会好不了，就打手动，很是麻烦；

     最后，一句话总结： 事件未必只是用 BCR 触发； 一个完整的运作路线，需要多个环节触发导航；这样在整个立体库的 WMS 系统中，就做的非常行云流水和畅通；

具体图片见附件bcr_control.pdf。