专家大讲堂《PLC通信原理探秘》系列视频:https://www.ad.siemens.com.cn/service/elearning/series/288.html
最新更新:
连载之九: 【PLC通信原理探秘】大讲堂幕后彩蛋之花明
连载之十: 【PLC通信原理探秘】大讲堂幕后彩蛋之远航
连载之十一: 【PLC通信原理探秘】大讲堂幕后彩蛋之搁浅
连载之十二: 【PLC通信原理探秘】大讲堂幕后彩蛋之有谁
连载之十三: 【PLC通信原理探秘】大讲堂幕后彩蛋之头疼
生活要继续,问题解决也要继续,继续对前面遗留的问题进行研究。
在使用CP卡做S7通信时又发现一个有趣的问题。就是在S7通信属性面板发现S7的终点有两个。在“Connection Path”中,End Point是CPU319-3PN/DP,而打开“Address Details”时,发现End Point是CP343-1 Advanced。
那么对比一下400CP卡的属性看看吧。发现两个End Point都是CPU414-3PN/DP。
那么为什么会有这种差异?结合前面所阐述的问题,300CP卡通信使用的功能块与CPU使用的功能块不同,导致这个问题出现的原因可能就是这个吧?因为300CPU和CP之间的数据交换是通过SFC58/59进行的,而400CP卡的S7通信仍然是由CPU来处理的。再看TSAP的地址指向不同,前者指向是CP343-1,而后者则指向CPU本身,这似乎意味着S7的协议处理在对应的TSAP的指向上面。结合这两点,对于300PLC来说,CP卡对S7协议进行处理,或者说进行S7的ISO/OSI参考模型的数据封装和拆包处理,而400PLC则是由CPU本身进行数据的堆栈处理。这就意味着300PLC在最初设计的时候确实在性能上无法与400PLC相比拟,即使后来出了CPU319,但内部的结构设计确定了,所以需要继续需要CP343-1来支持处理S7协议,这样也就变相的节省了CPU的负荷,缩短CPU的周期运行时间。这打破我原有对于300PLC和400PLC之间差异上的理念,我以为它们之间仅仅是速度或者性能上的差异,然而从这上面来看它们的内部设计结构也是存在差异的。
那么这些假设看似是合理的,如何来证明呢?那就使用同样的方法呗!300CPU和CP卡之间是通过SFC58/59来实现的,根据手册SFC58/59的数据一致性是240B,这就是说使用CP卡做BSEND/BRECV的S7通信的数据一致性长度是240B。验证的方式就是前面所描述的方法,通过[240]和[241]的数据自增来去检查是否是240B,而不是前面所说的204B,测试结果说明数据一致性为240B。而这些都是纯粹的用户数据,这240B发送到CP卡中,再由S7协议接手处理,进行数据一致性为204B的数据发送,所以在总线上通过Wireshark抓包看到的依然是204B,206B这样的S7PDU,而CPU中的数据一致性是240B,也就是SFC58/59的数据一致性。这就证明确实像假设的那般,300CP卡做了S7通信的主体负荷承担,而CPU拿到的仅仅是最终的数据。这反过来来解释为什么300PLC的S7通信在使用CPU和CP卡时使用不同的指令库。而如今1500PLC在编程的时候仅仅使用一个指令库,但实际上已经把这两者之间的差别掩盖了。
那400PLC如何像300PLC那样来证明呢?400的CP卡不是像300CP卡那般去承担S7协议处理的主体负荷,而是由CPU来承担的。调用的程序库可以证明这一点,然而还不够!找不到测试的方法,找不到参考的资料,找不到我想看到的结果!找不到!
于是我不得不写一封邮件给德国技术支持总部,邮件中我阐述了我对300CP卡的结论,以及对于400CP卡的猜测。还好这封邮件辗转反侧,很幸运的到了一位曾经做过400CPU开发的德国同事那里,他的回信证明了我的猜测!这就是说明在这种情况下,400CP卡实际上就是扩展了CPU的通信接口,仅此而已!
以下是我保留的那封邮件的一部分,截取这个最重要的部分分享给大家,以此鼓励我自己,让我继续前行!
You can't find anything about the internal design. So, instead of “route" you may also call it "transport-gateway" (i.e, ISO/OSI-Layer-4), which just forward the incoming transport packet to the S7-400 CPU. That's all about that issue.
----------未完待续----------
连载之十五: 【PLC通信原理探秘】大讲堂幕后彩蛋之苦大
连 载 汇 总: 【PLC通信原理探秘】系列连载故事汇总