有一个大家都听说过的笑话，大意是：
1.老婆永远是对的，
2.如果老婆是错的，请参考第一条；
我对堆垛机的控制思路也是类似，堆垛机控制系统不管人家怎么设计，都是对的，即便有点瑕疵，或者提供给上位的信息有点匮乏，那么也是你上位调度系统自己想办法解决的；

经历过很多堆垛机控制的项目，基本没见过上位100%的把跟踪调度控制的完美，总会在某些特殊情况下，出现数据紊乱的情况；

当然，调度系统，要在每个细节考虑异常的可能性；异常来自两方面：1.设备的异常；2.自身调度的网络异常造成的数据不匹配的修复；
很多时候，大家集中关注空出重入的异常，不过有些异常反而更具有迷惑性；


我联想了反证法的推断的思路。
这个思路，来源一个简单的数学问题：根号2是无理数的证明，要证明它不是有理数(也即是可以表示成两个互质的整数相除M/N的形式)，
就先要假设它是有理数，然后推断出矛盾的地方，从而证明它不是有理数；

所以，当我们在调度之前，不能预先知道堆垛机的异常的时候, 会给堆垛机正常的调度指令，在执行到取货或放货的时候堆垛机会抛出相应的异常反馈，
根据这个反馈我们在做相应的正确的自动化处理；


想象一个场景：
    1.假如堆垛机不把自己货叉上是否有货的信号告诉上位（大部分堆垛机是提供的，但是也有的不提供）；
    2.堆垛机是空闲状态;
    3.堆垛机入口有一托货，比如叫A；
那么这个时候：
   1.上位就会自动"调度"，让堆垛机去把A取到货叉上
   2.堆垛机到了入口，发现因为货叉行本身有一个东西，无法取货，上报上位:无法执行取货指令；
   3.这时候，上位就要做两件事情：
               1.把记忆的正在做的A任务清除掉，也即是后面的放货操作不是A了(上位后面的放货指令，一定不能当做A来处理)
               2.生成一个虚拟的任务(记录一个虚拟的托盘号B)，给堆垛机发出放货指令，如果出库站台可用，就将它出到出库站台，
                 如果出库站台暂时不能用，也不能停在那里干扰后面的任务，就暂时找个就近的空货位入库，等出库站台什么时候空闲了，再次出掉；
这个场景，就是非机械性的异常，有的堆垛机自身是不管的；静态情况下，谁也不知道，只有动作到那一步，才能知道，所以上位调度系统，
一定要灵活应对，发现问题，就要自动“猜测”问题的可能性，如果怀疑跟踪错了，立马对当前任务放弃，悬崖勒马，否者就有跟踪串货风险；

再来一个场景：
堆垛机放货的时候，提示无东西可放；    可能原因：
         取货故障，东西被人为直接放到目标位置；
    这时候， 上位最简单的方法是：假设该货物已经放好了，将任务完成掉(这种可能性比较大)，然后做一个记录，提醒人为检查关注，如果真的不对，再做人为数据修复；
    有的人，希望停下来，检查问题后，再手工干预；我觉有两点不可：1.时间长，干扰堆垛机后面待执行的任务； 2.操作员水平有限，未必能整明白，手工干预很容易是错的；

同样，这里如果上位处理不好，不把该任务结束掉，很容易继续调度，把后面的托盘当当前这个继续执行，重而串货；

当然，还有在通讯环节的错误，更具有迷惑性；
当你发送一个指令给堆垛机的时候，鬼知道它是否正常的接受了，并且去做了；
当然我们协议都是一问一答的，收到它的回复响应的时候，肯定是正常接受了；
但是本着怀疑的态度，万一你发过去后，它也响应了，但是状态没变，还是初始，这时候你怎么分析；

还要加上最傻瓜花的一招：凡是发送给堆垛机的指令后，第二个指令必须和第一个指令之间有间隔，比如最低3秒(堆垛机一个动作短则数十秒，多则1,2分钟)；
有的堆垛机，你给他发出去指令后，它的状态会闪变，执行中突然变成初始再变成执行中，这种假动作会给上位判断带来疑惑，所以你稍微延时一下，把这些干扰信号过滤掉；
这种奇怪的问题，你可以说是堆垛机自身的问题，但是还是回到开头的那个笑话，堆垛机自身的设计是不会错的，如果错，也是上位调度系统做的不够“聪明”；