每个自动化项目中，输送机的信号跟踪是协议量最大的地方；
如何设计好这块，也是协议的关系；
既要考虑逻辑的方便性，也要考虑物理的合理性；

用PC面向对象的思路，去考虑plc层的设计，我想也是可行的；

每段输送机都是一个类；有属性和方法：

属性：
     1. 托盘号
      2.去向
      3.光电信号1( 0-无 1-有)
      4.光电信号2（有的输送机有两组光电）
       5.电机转动(0-停止 1-正转中 2-反转中)
       6.异常( 光电不一致，尺检异常，电机超时等）.
       7.是否手动
       8.可入或可出( 0-不可 1-可入 2-可出  主要用于入出库站台：一般配合堆垛机穿梭车这样自动调度的设备，这个可选）；
方法：
      1.请求上位去向指示（通讯点：指示类型，请求托盘号，请求去向）；

如果这样定义
优点：
       1. 协议通用化，容易编写；
       2.信号点集中；经典的做法：把托盘号去向放在一起作为每段输送机的属性；其他信号单独分布，这样就把输送机的属性打散了，
         不便于开发和集中式管理；
      3. 这样做，对于异常，上位就好掌控的多， 如果用常用做法，就一个或多个点 定义异常；
       异常没有和各段输送机对应；如果同一个时刻有多个输送机发生异常的时候，上位没法获取全部；
      而且对于电控这一侧也特别麻烦：同一个异常，比如电机超时，对于不同的输送机，PLC定义的编号也不一样；
       如果每段输送机都有一个异常信息，那么相同的异常，编号就一致了；大大的简化了异常的定义；         
      4.PLC内部可以写成子程序，100段输送机这样写，1000段也是如此，把一段输送机看成一个类的思路，容易做的通用；
         通讯点也是有规律的，每段的长度一致，便于定位，反查，哈希运算，也许程序的执行效率更高；

缺点：
     1.协议量有点大；，
     2.有些属性可以通用的，比如有的手动盒可能控制10端输送机，有的手动盒控制7端输送机；这样如果每个输送机有个手动信号，就会浪费点；   
    3.事件这一块，可能单独抽出来，放在不同的数据块里可能更方便；
    比如三菱的PLC，D3000的部分做事件；D4000的部分做属性；
           西门子PLC， DB5的数据块做事件，DB7的数据块做属性；
     4.对于三菱PLC， 比如对于光电信号，本来在原始的X输入点上，如果PLC在把这个信号转到D点相应的输送机位置，也增加了开发量和多占用了内存点； 但是我觉得为了PLC程序内部的循环和通用性方便，可以考虑编号规律性不强X,Y点和输送机对象的D点做一个映射；逻辑处理都从对象的D点去处理，这样plc自身程序就通用了；通用的“威力”是很大的；              这有点类似支付宝，比如想向某人汇款，可以把各种银行卡的钱先回到支付宝账户里，通过支付宝再转个别人，这个就比较方便，卡对卡转，你要登录不同的银行网站，各家应该转账方法都不一样，而将银行卡绑定支付宝后，所有对外都通过支付宝中转，就做到对银行无关性了，工行也好，农行也罢；账务的转入转出都是同一个方法；


但总的来说，把每段输送机都做为通用的个体来设计；而不是对每个单独的输送机单独做处理，好处是：
      1.开发工作量肯定要降低，
      2.便于plc工程师之间的技术规范统一；而且便于分工，核心工程师在家做好核心通用逻辑程序；普通现场工程师做好X，Y点的映射表；
       提高了现场实施进度，简化了排查问题的难度；                         
       而且做好了，plc的内部核心程序可以加密打包给第三方；由第三方做些外围的io信号的实施；
       这个想法我也是参考现在做WCS的思路：
       核心工程师把框架定好，内部事件，调度跟踪的骨架形式定好；
      现场工程师根据具体项目，配合好映射关系和编写事件逻辑和WMS的关系；