随着物流自动化的发展；自动化调度也越来也显得重要；在下位机控制层面，PLC是控制核心方式；
咨询了认识的一些认识的电气工程师，他们在使用了众多plc之后；也体会到在熟练使用几种plc后，
西门子确实在体系架构，开发方式，模块化设计等方便上比其他plc有不可比拟的先进性；


看看发生在身边周围的项目，西门子PLC几乎占有了80%的市场，而且有些客户也指定要用西门子的控制器；
虽然西门子的东西偏贵一些，但是一般项目中，人力成本才是最贵的；所以作为上位调度，搞清楚西门子的通讯也是很重要；

当然，西门子虽然号称最稳定，最强大，但是资料缺最保守；
根本找不到官方的通讯协议格式；不像其他plc都有很详细的通讯协议格式说明；
要想通讯，最好用他官方的smart.net（拼写的好像不太对），然后组态它的opc server；
繁琐的很，当然也可以用第三方的opc server；
作为“性能洁癖”爱好者，很讨厌使用第三方的通讯接口，
当然，不否认opc server 做的还是挺好的；我用工具抓取过它的数据包，它会”智能“判断OPC clinet需要访问的数据；
然后在根据再和plc做相关数据的访问； 并不是大家可能理解的：opc server里配置了那些点，就会全部访问plc;
至于怎么“智能”法，举个简单的例子：
   如果，你在opc client只访问DB7.B1的时候，opc server 和plc就只访问这一个点；
    如果，你在opc client访问DB7.B1和DB7.B5的时候，opc server 和plc就连续访问b1开始的5个点（虽然b2~b4白访问了，但是一次得到B1,B5还是划算的）
    如果，你在opc client访问DB7.B1和DB7.B100的时候，opc server 和plc如果连续访问100个点就太浪费了，这时候，它就会自动分两次各自访问
B1和B100;

opc server 类似于软件开发里的中间件；如WeblLogic，JBoss之类,封装了会话池，对象池；
假如有个大项目：客户用到了 三菱Q系列、三菱FX系列，西门子200，西门子300，西门子1200；
以上5种型号，底层协议全部不一样，如果配好成opc server ，使用起来根本不用关心底层通讯格式，通讯的异常处理等；
上位 用起来真的太爽了；

但是opc server 也有很多缺点；
     1.性能，肯定不如直接通讯来的高；而且中转一下，感觉会带来更多的异常可能性；
     2.费用，理论上opc server都要收费的，而且都是以万为单位的，土豪可以不在乎；
     3.组态麻烦，当然会者不难；不过确实麻烦；
    4.通讯时序的灵活性；比如上位直接和plc通讯扫描，可以对某些数据点高速扫描，某些点低速扫描；当然opc server也有这个
      功能，但是毕竟是黑匣子，使用起来不灵活；数据量大的时候，报文隔断opc server会安自己的原则分段，万一分段正好是我们内部
     做一个事务不可分割的地方，就会导致类似数据库不一致性读的问题；
     5.上位直接和plc通讯，一般在接收到读取回复到数据的同时，做相应的事件处理，这样数据是最新的，如刚出炉的包子，非常“干净”，
        而opc server 提供过来的数据，时序是不是自己控制的，数据就不是那么“干净”了，可能是半秒前的数据；对于某些敏感信号点带来的逻辑运算，
      可能会带来错误的判断；
    6.一个opc server 一般只会配置一个通讯端口和plc对接； 但是有些plc端口在使用的过程中会死掉，自己开发的程序，可以自动切换备用端口；
        特别是三菱plc，当通讯量大，网络指令不是很好的时候，经常出现端口假死；这个问题困扰数十年，咨询官方攻城狮，也得不到答案；
        不过这也正常，在这浮躁的时代里，探寻实物的本质是一个多么奢侈的事情；
       所以咱们制定协议的时候，还是要有节约意思，不要过多第浪费数据通讯点，作为性能洁癖者，最讨厌放那些备用点，不用就不要加，
用的时候再加也是分分钟的事情；

上面说了一大堆废话；真正要说的刚刚开始；西门子的通讯协议的格式到底有什么特点？
如果想到网上查，别白费心思了，肯定找不到；哪怕你去找德文版的，估计也找不到；

有一个朋友研究了sqlserver底层的dbf，ldf格式，当数据库出现任何故障都能修复，比如数据库启动不了，文件损坏；
不慎 delete 或truncate 数据， 甚至直接dorp掉数据表，全部能修复；所以他现在号称国内数据库修复第一人；
这些资料网上不会有的，就算有，也是很肤浅的互相抄袭的文章；
所以说，研究原理才是最本质的；
大家都知道 初中学的 一元二次方程的时候，f(x)=a*x^2+b*x+c ；当a>0时，f（x)有最小值 ；当a<0的时候，f(x)有最大值；
而且这个根据韦达定理，脑海里马上能够出现抛物线图；
大学高数里，对这个问题做了扩展；对二元二次方程也有极值问题，f(x,y)=... ；但是这里就不能简单的判断有极值了；
一共有3中情况，某些时候有极大/极小值；某些时候居然没有极值(还是没有明确极值，记不清楚了)，搞得像霍金提出的黑洞中心的奇点似的(质量无穷大，体积无限小，任何物理定律都失效)； 书上那些晦涩的说明描述，估计没几个人耐心的去看，看了估计也看不明白；
其实，搞明白最简单，自己用微分，结合洛必达法则推导一下，就能彻底明白了；


对于西门子的plc，如果它开放了协议，西门子那么多一堆堆的组态，监控软件买的人就可能少了；毕竟不是非它不可了；
而且西门子这么严谨的作风；肯定要封装的一层又一层；因为如果攻城狮水平很烂，直接做原始通讯，很容易做的有问题，这样会影响人家产品；

其实，西门子plc的协议前两年也尝试研究过，网上有个libnodave的开源的dll代码，没什么注释的C++开发的；
看别人的东西，都感觉别人把东西做的狂复杂，其实更多的是自己的肤浅和无知；
感觉天书般的东西，看来是有生之年都搞不定了；

今天再次用抓包工具，琢磨了一下，发现其实挺简单的，就是之前没什么环境测试而已；

西门子有很多通讯协议方式 ,MPI,PPI,还是什么dp的，我都搞不明白，也不想搞明白了；这些都是比较老的，要不用串口，要不买专门的卡插在电脑上；
最讨厌这些“非绿色”的做法；

正常项目，一般都是网线tcp通讯的那种，官方叫 iso on tcp 这种方式；

西门子和三菱的tcp通讯方式不一样；

三菱是可以开放多个监听端口，但是每个端口同时只能连接一个客户端；
这种方式也挺好，傻瓜简单；

西门子的做法和 现在的大众软件方法类似，开放一个默认端口，是102，可以同时连接多个客户端；
这个比较符合我们做上位软件的攻城狮的习惯；
比如：oracle数据库默认端口1521，  MySQL 默认端口号为：3306 ； SQL Server默认端口号为：1433；
         http的默认是80等等；


所以，用抓包工具，抓取102端口的tcp数据即可；
西门子和三菱对报文的处理，有两个不一样；

1.tcp 客户端连上西门子的102端口后，必须做一个特定报文的交互，然后才能做正常的读取操作；
   而三菱不需要这个握手，直接读写操作；
2. 可能由于西门子的102端口是1对多的，所以它比较拽，一旦发现通讯数据格式或内容不正确，不但不回复，而且直接跟你把通讯通道断开，
    不理你了； 三菱遇到异常报文时，通讯不会断的，只是回复你异常数据，并且有异常代码；


最关键的是第一点，连接握手，其实，上位软件也是这么做的；
以前为了测试oracle数据库是否能连，经常用socket 客户端工具去连接数据库ip地址的1521端口测试，一般都会连上，
但是如果你随便乱发一个报文，通讯通道马上就显示断开；


今天终于摸索出来了，报文内容是：

握手第一个请求：

TX:03 00 00 16 11 E0 00 00 00 01 00 C1 02 01 00 C2 02 0102 C0 01 09 (15:12:11:264)

RX:03 00 00 16 11 D0 00 01 00 03 00 C0 01 09 C1 02 01 00C2 02 01 02 (15:12:11:273)

握手第2个请求:

TX:03 00 00 19 02 F0 80 32 01 00 00 FF FF 00 08 00 00 F000 00 01 00 01 07 80 (15:12:30:450)

RX:03 00 00 1B 02 F0 80 32 03 00 00 FF FF 00 08 00 00 0000 F0 00 00 01 00 01 00 F0 (15:12:30:459)

上面两个交互做完之后，下面就可以做正常的读写操作了；否者一上来就读写，102端口就会跟你断开了；

当然如果你为了省事，把两个请求合二为一，也可以：

TX:03 00 00 16 11 E0 00 00 00 01 00 C1 02 01 00 C2 02 01 02 C0 01 09  03 00 00 19 02 F0 80 32 01 00 00 FF FF 00 0800 00 F0 00 00 01 00 01 07 80 (15:49:00:731)

RX:03 00 00 16 11 D0 00 01 00 03 00 C0 01 09 C1 02 01 00 C2 02 01 02(15:49:00:764)

RX:03 00 00 1B 02 F0 80 32 03 00 00 FF FF 00 08 00 00 00 00 F0 00 00 01 0001 00 F0 (15:49:00:775)

不过最好还是按标准来，一问一答，安稳最两次交互好；

下面就是读写了，写的格式还没摸索，应该不难，以后有空再补充；

读的格式是：

例子： 读取DB7.B16开始的22个点：

TX:03 00 00 1F 02 F0 80 32  01 00 00 00 00 00 0E 00   

     00 04 01 12 0A 10 02 00 16(起始地址：十进制的22)  00 07(DB块地址)

     84 00 00 80(偏移量0x80=128=16*8)   

RX:03 00 00 2F 02 F0 80 32  03 00 00 00 00 00 02 00  

           1A 00 00 04 01 FF 04 00  B0(数据长度：0xB0=176，176=22*8)  0F(DB7.B16=15） 00 00 00 00 00 00   00 00 00 00 00 00 00 00  00 00 00 01(DB7.31=1) 00 00 00   

以上红色部分，是有效部分，其他地方，只要是db块的访问，全部一样；

当然还有很多细节需要用抓包工具结合真实数据，再做验证；不同型号的plc可能有些差距；

但是应付开发足够了；

如果能够实现直接通讯，收益是：

  1.节约opc server的中间件成本；

  2.提高通讯效率，特别应付高速分拣之类的交互方式， 交互控制在100ms~200ms以内，是easy的事情；用opc中间件方式就有点不可控；

  3.灵活控制通讯方式；

  4.确保在事件处理那一刻，数据最新；

  5.时序自由控制；

  6.减少了中间环节，就像小米手机一样，直接官网购买，出了问题，直接官网申请维修；主流购买基本不需要第三方；

     现在流行扁平化管理，以前下达命令，都是军长，旅长，团。。一级级下达，这样命令最终可能变味；据说现在美国的军方

指令都是直接来自五角大楼，不需要层层下达；所以通讯也一个到底，最好直接上下位对接；较少中介结构带来的额外异常的可能行；

一句话，省成本，提高稳定性和健壮性；