不同的PLC，通讯方式都不一样; 对于最普及的两种PLC，西门子和三菱;
最传统的通讯方式是：
    西门子： 通过OPC中转；
    三菱    ： 通过三菱自带的MC协议；

这种通讯方式的优点是：
1. 通讯 和PLC工程师几乎没有任何关系，很多PLC工程师非常熟练于plc内部的控制，单对于如何上位通讯，还是小白；
2.循环扫描虽然看上去比较傻，但是确实比较稳定；万一网络闪断，偶尔的通讯失败，对整个控制没有影响；

不过这样和PLC通讯，有3个很大的弊端：
1.不同的PLC的通讯方式和具体内部协议，上位都要去了解细节，很麻烦；
2.上位要关心内存块的每个地址的定义，和设备底层衔接的太紧；
3.对数据的都是扫描式的，对实时性非常高的系统(比如高速分拣)会浪费扫描的间隔时间；

对于实时性问题的改进手段：
1.  对于OPC有数据变化事件，所以可以不用去扫描，直接通过变化事件获取最新的数据值，但是OPC这个中间层自身是基于扫描的，
      一般周期在500毫秒；所以即便OPC能实时的提供变化数据，但其自身可能就延时了半秒；这对高速的系统是无法容忍的；
2. 对于三菱这样可以有直接协议的，可以稍微优化一些，比如开放4个通讯端口，每个端口0.5秒扫描一次，这样4个端口同时开工，可以间隔125毫秒就能扫描一次，
    而且一旦捕获到数据点变化，可以把扫描频率提高，等捕获不到变化了，再恢复到基本频率；不够基于扫描的基调没变，就像雷军说的，传统企业做的再好，也难以匹配基于互联网思维运作的公司；如同你太极武功再厉害，也抵不过机关枪；
所以没有那种基于毫秒级的实时通讯，总是让人如鲠在喉；

不过，现在有个趋势，随着PLC工程师能力的提高，他们也渐渐认识到，如果自己不做主动通讯，而是完全让上位去扫描通讯点方式，确实有很多弊端；

对于国外的设备，基本没遇到过：上位直接和PLC通讯的；
为什么这样，我想可能是以下几个原因：
   1.国外设备一般是标准件，标准件都比较注重封装，说的通俗一点，就是把复杂的留给自己，把简单开放给别人，
      所以他不需要你关心他内部的结构，使用的什么核心部件，它会自定义通讯协议，一般通过socket的方式，和上位对接；
     这样的话，上位的开发人员，就可以对PLC是个小白，甚至不需要知道什么是PLC,不需要关心内部各个地址的点定义；
    2. 可能也是技术防盗的一种手段；
当然现在国内的很多项目，也逐渐采用了自定义协议的这种方式，我想这应该是个趋势吧；
上位直接和PLC通讯的方式，如同谈恋爱，只有一方有炽热的主动；
  而双方自定义通讯协议，那么就双方互有主被动，效果甚至达到1+1>2

自定义协议的注意点：
   1. 可以考虑多个端口通讯：比如A端口是上位主动，比如发出动作指示； B端口是下位主动，比如动作完成报告或条码去向请求；      这样一个端口就一个方向，有点类似于485通讯的半双工方式；虽然可以一个端口搞定，但是通讯方向上通过端口区分开，感觉更好些；
   2. 不一定要严格的一问一答，传统的通讯方式都是问答式样的；
        第一个请求得不到答复，第二个请求不会发出；
       但对于高速事件请求显然不行，PLC接受到设备的事件，必须马上一口气抛给上位请求，否者事件来不及；
        第一个料箱请求抛给上位请求去向后，万一100毫秒内等不到上位响应，可能第二个料箱又来了，这时候就必须马上继续抛给上位；
        这就需要在每个自定义的协议报文里，要有严格序列号的概念；
       当然问答也是保证的，只不过变成了n问n答，而不是1问1答；
     这对上位也做出了要求，对于通讯，就一定要做非阻塞的了；
    3. 对于核心的交互事件，用自定义协议确实解决了实时性的问题，但是对于那些监控数据，比如光电信号，电机的正反转，托盘的跟踪等，
    这些信号变化量非常大，如果用数据变化的事件式主动上报通讯，反而让通讯频率太高；而且这些数据往往没有基于毫秒级的实时要求，
   这些地方可以使用传统的方法，让上位统一以半秒左右的周期扫描获取；