专家大讲堂《PLC通信原理探秘》系列视频：https://www.ad.siemens.com.cn/service/elearning/series/288.html

最新更新：

连载之十五： 【PLC通信原理探秘】大讲堂幕后彩蛋之苦大

连载之十六： 【PLC通信原理探秘】大讲堂幕后彩蛋之愁深

连载之十七： 【PLC通信原理探秘】大讲堂幕后彩蛋之砥砺

连载之十八： 【PLC通信原理探秘】大讲堂幕后彩蛋之前行

连载之十九： 【PLC通信原理探秘】大讲堂幕后彩蛋之一步

连载之二十： 【PLC通信原理探秘】大讲堂幕后彩蛋之之遥

     至此，基本上TCP/IP的通信原理和行为都告一段落了。然而，还有一个参数是很早使用CP卡做TCP通信时候看到的，”Send Keepalives for connections”，后来这个参数又出现在PN的CPU上，这个参数的作用到底是什么？当时的理解可能不深刻，于是正好在理解TCP通信的基础上，把这股残余势力彻底消灭吧。

     在理解这个参数之前，这里提到了CP卡的TCP/IP通信，是使用AG_SEND/AG_RECV来实现的，那么和PN CPU的TCP/IP的通信行为一样吗？结合前面的测试，对于300CP卡，CPU和CP卡之间是通过SFC58/59来实现的，那么数据一致性是240B，此外TCP协议使用了CP卡的资源，那么必然占用CP卡的TCP连接资源，而CP卡本身对于TCP来说是4层网卡，很自然的处理TCP通信服务，这也意味着CP卡的TCP/IP通信与CPU无关，CP卡可以帮助节约CPU的负荷。对于400CP以及1500CP卡是同样的道理，只不过数据一致性为8K，因为CPU和CP卡的数据交换方式两者不同。

    在做CP卡通信的时候，会在Options属性页中发现对于Keepalive的Interval的设置，PN的CPU推出来后，同样的参数也出现了。根据在线帮助和手册该参数用来探测通信伙伴是否失效，以此来释放连接资源。

     通过Wireshark抓包，来分析Keepalive的工作机制，简单来说就是主机A发送数据给主机B，接收完毕后，主机B开始计时，如果在默认的时间30s，没有再次收到主机A发来的数据，那么主机B就会发送该探测帧，用来查看主机A是否存活，如果主机A存活，主机A会发出应答，说明还活着，如果主机A宕机，那么主机B会自动每个30s发送一次Keepalive。这里关键的问题就是如果主机A真的没有存活，那么后续的动作是否是释放连接资源。实际上对于办公室的多数TCP应用是释放掉这些无用的连接资源的，然而通过测试，对于PLC，连接资源并不会被释放，能够释放资源的方法只有重新启动CPU和激活DISCON。那么它对PLC的TCP通信的作用是什么呢？

     还是使用前面测试Done和Busy信号的实验，在双方的缓冲区中都压入不同标记的数据，在正常的情况，接收端会收到这些数据，然而断开网线超过30s会再接上，或者停止数据发送超过30s且对方无Keepalive应答，发现接收端没有收到这些标记的数据，那么也就意味着缓冲区，Shadow Buffer和Stack Buffer中的数据被清空。这说明Interval的时间后，释放的不是连接资源，准确的说是任务资源，是数据，这放映了工业网络通信对于可用性的一个考虑，即不能因为上述两个原因，而释放掉连接资源，从而导致PLC通信断开；此外也放映了手册和在线帮助的说明不是那么的严谨，所以当我们看到这些时，要保持怀疑的态度，而严谨是做好技术的最好态度！

     这个结果可以恰恰解释我在第一篇《序言》里提到的第一个案例的答案。即如果不想收到旧数据，那么拔插网线的间隔动作时间要超过设定的Keepalive的Interval的时间。好了，TCP的残余已经消灭了，整装待发向S7协议挺进吧！

----------未完待续----------

连载之二十二： 【PLC通信原理探秘】大讲堂幕后彩蛋之新敌

连   载   汇  总:   【PLC通信原理探秘】系列连载故事汇总