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

最新更新：

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

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

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

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

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

     上述的测试中，对于300PLC无论在禁用还是使能“By PLC” 的情况下，发送数据给WinCC都是通过CCP进行的。因而这样通信的效率确实比较低，因为数据的发送周期取决于CPU的循环周期，特别当CPU的周期时间过长的情况下。不过随着CPU版本的升级，300PLC可以通过时间片的方式与WinCC进行通信，这也说明版本的升级不仅仅修改了一些Bug，也在实际上做了硬件性能的提升。在CPU版本V3.2版本之前，300PLC只能通过CCP的方式与WinCC进行数据交换，无论是否使用 “By PLC” 。而V3.2版本之后，CPU支持OCM功能，在CPU属性中可以激活，这表示CPU可以使用时间片来替代CCP做的通信。

     这样激活OCM功能后，再做测试看看通信的行为如何？还是根据前面的一些测试条件，发现当激活“By PLC”时，数据的推送仍然发生在CCP，数据通信行为不变，这表示仍然数据的推送周期取决于CPU的循环周期。当取消“By PLC”，那么当WinCC画面上同时存在多个刷新周期变量时，变量读任务响应周期等于画面变量的刷新周期，因为此时数据的响应在CPU中发生在时间片。所以总结来说这进一步说明在300CPU与WinCC通信时，不建议使能 “By PLC”。

     那么对于400PLC与WinCC的通信行为又是如何呢？前面文章中其实表明与300PLC不同的是400PLC通信多数发生在时间片。使用同样的测试条件和方法进行400PLC的测试，当禁用“By PLC”时，由于400PLC与WinCC的数据交换发生在时间片，那么数据通信行为与300PLC的OCM方式一样。激活“By PLC”，S7-400PLC会给每一个WinCC分配6个循环读服务，共16个，PLC会根据WinCC画面的变量刷新周期进行推送，这种方式与300PLC不同，发生在时间片。而当在WinCC画面上设置变量的刷新方式为“upon change”，如果PLC的数据在不断的变化，由PLC自行决定推送周期，该周期由PLC自行计算，无法得出准确公式。但肯定一点就是不是数据一变，PLC就推送该数据。

     激活“By PLC”&“Change Driven transfer”时，当WinCC画面上同时存在多个刷新周期变量时，根据变量的刷新时间判断变量变化，CPU才会推送这些变量数据给WinCC。也就是说判断变量是否变化，取决于画面变量的刷新周期，CPU会根据此时间内判断数据是否发生变化，变化则发送数据至WinCC。然而经过测试发现一个很有趣的过程就是数据变化才进行推送，仅对DB数据有效。即当画面上的变量为DB区时，根据变量周期发现此数据发生变化，则会推送变化数据给WinCC。

     如果画面存在其它地址区域。例如M区数据，无论数据变化与否，CPU都会按照画面上变量的刷新周期进行推送。即即使根据变量周期发现此数据没有发生变化，也会推送这些数据给WinCC。这样的使用 ，设置“Change Driven transfer” 并没有起到真正的作用。

     所以在这种情况下的通信优化方式，即使用DB区，甚至按照前面的结论最好是连续的DB区。一方面可以减少推送的报文数量，最大程度的装载有效数据，另一方面可以按照“Change Driven transfer”，真正是变化的数据才会被推送，减少网络负荷。

     以上就是S7-300/400PLC与WinCC画面变量通信的通信行为。整个测试过程，看似结论很多，但其实很简单，关键在于使用以前的通信概念进行分析和总结，多做，多看，多分析，多总结，很快会发现问题的所在，发现通信的行为以及背后的概念和原理。

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

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

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