WINCC和S7 PLC的通讯原理应该比较复杂，但大致过程应该如同WINCC在线帮助里说的，“在工业通讯环境中，WinCC以变量和过程值的形式进行交换信息的通讯。为了采集过程值，WinCC通讯驱动程序发送任务消息给AS，然后AS把相应的包含有所请求的过程值的回复消息发送给WinCC。”这里WINCC应该维护一个变量的映像区，然后定期的去刷新映像区的内容。
WINCC和S7 PLC一齐使用的时候，可以充分发挥S7 PLC的周期性读取服务，当启用这种功能时，WINCC把要周期性读取的变量编组成一个独立的请求，并将其传送给CPU,一旦CPU收到请求，AS将立即传送所需要的数据，并且每当周期时间到达时都主动传送数据给WINCC，这样的话WINCC就不需要每次发请求帧给PLC，通讯的效率就有了较大的提高。
当请求数据不再需要时，例如画面切换时，WinCC将删除AS中相应的周期性读取服务。这里要注意的是，虽然WINCC的变量管理器中建立了很多变量，但某一时刻，只有当前画面中的变量以及当前画面脚本中使用的变量和全局脚本中使用的变量真正与PLC进行通讯。至于报警记录和变量记录中的变量怎么样和PLC进行通讯，我觉得WINCC可能是采用特殊的机制进行通讯。这也是我们在变量管理器中看很多变量的质量代码不同的原因。
正常情况下，应该使用AS中的周期性读取服务。因此，缺省是使用这项功能的。只有当激活周期性读取服务时，才可使用变化传送。当数值改变时，数据才能从AS中传送且在每个AS周期只传送一次。该功能必须由相应AS支持。使用周期性读取服务和变化传送会减轻AS和PLC-OS二者的通讯负荷，因为读取请求不需要连续发送给AS并处理。
至于脚本的使用是否会影响通讯?如果在脚本中大量的采用GetTag、SetTag函数肯定会影响通讯，因为WINCC不会把脚本中使用的变量放到周期性服务中，这样WINCC就会使用非周期读取请求来和PLC进行通讯,通讯效率必然下降。另如果实在要在脚本中使用变量,一定要采用变量触发的方式，不然WINCC将连续发送读取请求给PLC，这样通讯效率也必然下降。
周期性读取服务的数目取决于S7-PLC中可用的资源。对于S7-300，最多有4个周期性服务可用，对于S7-416或417，则最多为32。该数目适用于与AS进行通讯的所有成员，也就是说，如果有多个WinCC系统与S7-PLC进行通讯，则它们必须共享可用的资源。如果超过资源的最大数目，则更多的周期性读取服务访问将被拒绝。于是WinCC不得不使用非周期读取请求来请求该数据。
对于象GetTagByteWait这样的函数执行时会绕过WINCC的映像区，而是直接从PLC中读取数据，并且要一直等到从PLC读出数据才执行结束，这样执行速度相对还是比较慢的。
综上所述，总结如下：
1.优先使用AS的周期性服务和变化传送，没有特殊情况，不要关闭这项功能。
2.少在脚本中使用GetTag、SetTag等函数，一定要用时脚本需采用变量触发的方式
3.一幅画面中,变量的更新周期尽量保持一致。
4.没有特别要求，不要使用加WAIT的读写TAG函数。
至于楼上大侠所说脚本是单线程的问题，各种脚本（全局脚本，画面中的脚本等）的执行应该都是一个线程，也就是说可能有几个线程,而且脚本的执行采用的是队列的方式。如果脚本中使用延时，或者直接外部变量读取就会影响脚本的正常执行，最终的可能是脚本队列满，然后报错。
另有疑问如下：
我有几次遇到这样的问题，一次是315+343，一次是317-PN/DP，一次是412+443，当采用周期性服务时，出现通讯间隔中断的情况，而不采用周期性服务反而工作正常。我怀疑是WINCC中使用了大量的脚本用SetTag,GetTag去读取PLC中的变量，导致大量的非周期性服务存在，而很少一部分变量能够使用周期性服务，而周期性服务又占用了CPU较大的通讯资源，导致CPU通讯负担太重，从而引起上面的问题，而关闭周期性服务后，周期性服务的资源被释放，反而通讯负担有所减轻。不过我不敢确认以上说法，希望各位大侠能给个解释。谢谢！
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。