产品设计经理，都有有点偏执狂的情怀；在各种设备调度的时候，我们往往希望做最底层的调度；
因为我们都是面对的7*24小时的调度，如果设备商提供了一个dll之类的东西让我们调度；
这就让我们有点纠结，以为一些设备商，软件不是他的强项，找几个人开发了dll，然后封装给客户调用，谁知道有没有漏洞；
而且有点时候需要并发或多线程的调度，最常见的是，异步调度，这样供应商提供的开发包就难免有问题了；


先谈PLC：
plc中，最常见的就是西门子和三菱，

1.三菱有MC协议，可以直接通讯；这种感觉很好；可以随心所欲，自由发挥；

2.西门子没有开放原始协议，要不你用OPC中转，要不你用官方的prodave.dll 这两都让人不爽，最后选择了前者，用OPC，OPC调度也有两种方法，可以用西门子的opc客户端的dll，也可以绿色调用，
我们当然选择了绿色；数据点不做扫描读取，通过变化自动触发，写入的时候，也是异步写入；这样确保一个程序可以调用多个plc不会因为一个通讯故障影响其他的；
但是通过一个中介总是感觉不爽；就像你买房或租房，总想绕过中介，使买卖双方都省掉一笔费用；所以进过opc中转，必然有性能损失；而且如果自己直接读取写入，可以把重要和非重要的点，
区分开扫描频率，如果用OPC就不能做这样的细化处理；
不过最近看到一个开源的libnodave.dll,可以通过它的开源程序，破解出西门子的原始协议；这样就爽多了；
哪怕对于高速分拣，可以使用多个端口，高速交替扫描通讯协议点，一样能够确保效率，保守估计，做到100ms以内的扫描周期问题不大；这样就不需要电控自己做协议做主动通讯；

西门子默认通讯端口是102，该端口可以连接多个客户端；而三菱可以开放自定义多个通讯端口，但是每个端口只能连接一个客户端；


在谈DPS:
  DPS使用的不像我们想想的那么广泛；
  常见的就爱欧和上尚两家；
爱欧使用的ocx插件，好像是vb开发的，需要安装；
上尚的用到两个dll，其实一个还是delphi里的自带的，好像是borlandxx.dll ，不用安装；

爱欧的使用起来更容易些，按按钮的时候，有按下事件；
上尚的要考自己扫描来处理；但是爱欧的通讯插件不够绿色，要安装，有的电脑搞不好会安装失败；

爱欧DPS的地址设置，比较傻瓜化，只要按住，再输入地址指令就可以；
上尚的地址设置，貌似更傻瓜化，在设置模式下，它会一个接一个的自动累加1，不过这个反而不方便，因为货架的编号往往是排列层，不是简单的累加那种；


不过，这两家都不开放原始协议，跟厂家要过，他们说，如果你有兴趣，他们可以和总部要；

算了，毕竟项目中dps用的少 ，如果有原始协议，各种异步调度要好做的多；

当然，不管怎样，dps自身还是成熟的，有些朋友遇到问题，老怀疑是dps自身的问题，但是笔者自己实践下来，往往都是自身程序的漏洞；
所以从这个角度说，设备提供商也有倒霉的地方，遇到不懂行的客户，明明自己使用的有漏洞，却说设备不行；

再说BCR：
   市面上的BCR还是不错的，全部开放协议，而且可以自定义条码前缀，既可以做服务端，也可以做客户端；

最后说显示屏LED：
     在协议这块，led是最让人痛苦的了，不开放原始协议也就算了，而且它提供的dll狂难用，狂难用也就算了，在led多的时候，还不稳定，容易发送失败；
     用了好多家，基本led的那个dll像是出自同一人之手，一样的难用；

    从开发角度来讲，用电脑的显示屏，开发起来跟简单，但是必须要连接电脑，一个电脑一般也就连接两个显示屏；
    现在pad这么流行，网上那些国产7寸左右的pad，500 元左右的已经是高档货了，如果用pad代替也是一个选择，不过pad还是太小，不能完全替代显示屏；

   不过老实说，显示屏作用其实挺大的，比如提出口，显示剔除原因；滑到口，提示订单进度； 出库口，显示货物名称数量等；   led作为一个主动推送信息的用户体验的入口，给系统带来作用往往是画龙点睛的；