前一阶段，关于“WinCC实现报表的不同方法及其应用”的技术探讨已经圆满落下帷幕，其间获得了众多网友的关注，并且大家也在交流过程中澄清了一些概念，总结出了很多宝贵经验，可以作为今后实践中的重要参考。
接下来让我们再次聚焦，共同探讨WinCC的另一热点话题：WinCC 与 S7-300/400 间的通信设置和优化，这也是WinCC项目中最常见的一种应用。
WinCC 作为人机交互的窗口，其性能和可靠性直接影响操作员的工作效率甚至生产过程的安全性。而高效的数据通信更是保证WinCC正常工作的基本条件。
那么，如何通过正确的参数设置来保证通信的正常，以及面临一些通信问题时（如通信时断时续，变量更新慢甚至不更新，或者还有些现象疑似通信问题，如命令执行滞后、画面切换缓慢等）如何诊断排除，将是我们本次交流的重点。
借此机会，大家可以把自己在项目中遇到的WinCC通信相关问题拿出来，我们一起切磋探讨，共同寻找解决方案或是优化空间。
此次集中探讨将持续至4月30日，其中有突出表现的网友将获得加倍精华奖励积分；最终所有有效留帖的网友将获得加倍发帖金币；根据交流情况，会酌情赠送小礼品。
交流结束后将整理精华内容，供大家分享参考。
预祝大家交流愉快，收获丰富！

我谈一下我对画面切换慢的感受和想法：
1.往往我们在一副画面中做了太多的动态连接，这样在运行状态下，数据量过大，在画面切到这副画面的时候必定会慢；因此我一般都不会在同一副画面中做太多的动态连接；至于这个数量得多少，根据经验掌握；
2.对于PDL CACHE，我倒是用过，感觉效果并不明显；因此我认为，解决画面切换慢的问题，这个方法只是辅助功能，解决不了根本问题；
3.网络问题：我曾经在项目中遇到过；在项目投入正常使用前，我们用思科的交换机进行实验，结果就是画面切换的速度很慢。好在第2天就连到了OSM上，画面切换一切正常。并不是说思科的交换机不好，而是我们用的思科交换机有问题。因此对于画面顺畅运行的基础是必须保证网络的正常；包括交换机，网线，接头等等。尽量使用工业级产品，可以对系统的稳定性得到好的保障；而且对于安装，走线也要尽量考虑安全，稳定。
4.再有就是对于脚本的使用。过多的使用脚本必定会带来机器负荷的增加。因此对于脚本的使用也要有限制的。
5.变量归档：很多用户对于归档都会提出较多或者全部的要求。实际上这样做非常的不好。过多的归档必定会带来大量的数据存储，如果不适用CAS服务器的话，所有的数据都存储在本机上，使得硬盘空间越来越少。虽然可以使用堆栈的方式，保留一定的硬盘空间；但毕竟归档的频率与数量会影响机器性能，也就间接的影响WINCC运行的效率。
6.计算机的配置：西门子都提供了不同版本的WINCC与PLC兼容的最低配置。当然这个最低配置是允许条件，但尽量还是按照推荐配置或者更高配置进行配置。机器的本身性能是系统好坏，稳定与否的关键。
7.通讯介质，方式以及速率：这方面当然目前最优选择是以太网。是提高通讯性能的关键。也是WINCC运行速度的一个保障。但往往这方面的配置不能以工程人员的意志转移的。
8.通讯距离：距离越短，速率就有提升的空间，自然通讯速度上来了；但这个速度也不要无顾虑的提升。毕竟速度越快其稳定性就相对不够。适中最好。PLC与WINCC的通讯如果很长的话，尽量使用光纤转换器OLM，中继器等设备；这样能保证长距离的通讯质量。
9.又想到一条：画面尽量减少3D效果，动画效果，图片调用等美工的做法。这样会加重运行负担。

暂时想到这么多，欢迎拍砖!
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

以前用国产组态软件的时候，这方面考虑的比较多，但是在SIEMENS上，考虑的就很少了。总是觉得有些东西是不公开的，也就搞不清楚了。
我个人的习惯考虑范围主要包括：
1.尽量减少脚本语言的使用。wincc的脚本功能很强，确实能实现一些明显的效果，但是从全局考虑的话，其执行效率就要降低了。比较简单的例子：切换画面，用WINCC自带的直接连接的切换效率明显是高于脚本的；并且曾经因为动作需要做了一个延时脚本，结果调试中就明显发现，延时过程中整个程序都被冻结了。所以我认为脚本的执行是纯粹的单线程运行，这样，众多脚本就必然因为先后的问题而相互影响。
2.不知道是不是国内的风格习惯，总是喜欢将上位画面做的非常漂亮，甚至说华丽，而这方面明显不是工控上位的强项。直接导致的结果就是系统资源消耗大，画面反应慢。所以应该尽量减少画面的绚烂程度。还是以功能的实现和操作的方便为主才好。
3.很多项目甚至是由于业主方的不熟悉，总是希望变量归档越多越好，这点上明显除了占用磁盘空间之外还要占用系统性能。所以，没必要的归档变量要尽可能的缩减，并且，根据实际数据的重要情况，分组的设置归档时间。尽量避免笼统的统一到非常频繁的变量归档。
4.至于硬件方面，众所周知了，性能高的当然优于性能低的，以太网好于DP，DP好于MPI，不过实际上，就我做过的项目来说，不少项目实际上用MPI也是可以的。只要能满足当前的实际情况就好。并且，CPU上的DP口基本极少会单独留给上位使用，在没必要的时候，将上位分配到另外的网络，对DP网也只有好处。

除了上面这些之外，再结合我以前用国产组态软件时的经验考虑一下：
1.首先一点，不太清楚的地方是WINCC和PLC之间更为具体的通讯数据的处理方法。在国产软件上，这2者之间的通讯数据是打包的形势，而变量的建立直接影响了这个包怎么打。比如说，同样是8个bit，如果变量建立的合适，并且上位的读取方法合适，那么这8个bit被打成一个包从PLC传输到上位，而如果处理不当，这8个bit就有可能被打成2个包甚至更多，这明显降低了总线的通讯效率并降低了上位画面的数据采集速度。当然，这里的8bit只是一个例子。
2.wincc在位的处理上有点单一。实际项目中是有很多开关量的，对于开关量的处理上，通常有两种方式，一种是按位建立变量，一种是按字节甚至是字或双字的方式建立变量。对于前者，处理上方便了，直接在画面中使用就成，而带来的直接问题就是变量数的大幅增加。另外的问题就搞不清楚了，不知道WINCC内部是如何处理的，对于bit变量的处理，我想肯定也不会是一个bit就耗用一个数据帧，但是多少数据形成一个帧，又是根据什么形成的。唯一能做的就是在PLC中建立变量的时候，把所有的数字量连续的建立在一起。而对于按字节或者字或者双字的方式建立变量，带来的问题就是需要在上位做解包处理。我还没有具体研究过解包的语句，但是这明显是要用到脚本来处理了，数字量众多，恐怕难以避免对系统性能的影响。从这点上引申来说，如果要细致的考虑通讯和优化，就要考虑在PLC中如何建立变量了，首先是地址的连续性，这点无可置疑，也就是说要尽最大可能避免变量中间有空闲的数据位。不过同时也要考虑程序的可读性的话，在不同的使用区域之间，有时还要预留出一段地址空间，以便于以后增加设备或者增加控制功能而备用。这2者之间需要平衡一下。
3.
3.1 此外，我也有一些不清楚的地方，同为SIEMENS的产品，相互之间应该是有一个最好的配合的，就是说，优化是不是也要从PLC有所考虑？那么哪些参数或者哪些处理方式上会有影响呢？
3.2 有一个问题也一直没弄清楚：在PLC中，是把大量的数据全部建立在一个DB块中还是建立在多个DB块中，对PLC程序的执行效率高呢？对于WINCC来说也同样，都是100个数据，是都从一个较大的DB块中读取快呢还是从多个较小的DB块中读取快呢？
3.3 用国产组态软件的时候，软件自带有通讯监视程序，从中可以看到通讯通讯的打包情况和传输时间，而在WINCC中好像没有这个功能。而我要提到的是这样一个问题：PLC中有不同的数据存储区域，上位对这些区域的读取速度是否相同？比如同样100个数据，从DB块中读取和从M区中读取，速度是否相同呢？因为我之前曾有过一次精力，某软件读取某PLC中不同数据区的速度差别居然很大，从上位画面的反应上都明显感觉的出来，所以后来在PLC中多写了一段程序，就是在数据处理完之后，将数据统一move到另一个数据区，上位统一从那个数据区读取，这样上下位之间的通讯确实快了很多。
罗哩罗嗦说了一堆，难免有不对之处，敬请指正、讨论。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

======================================================================


看了eaglesky 大侠的经验分享，很有收获呀！
您提到的关于“优化是不是也要从PLC有所考虑？”，我想答案是肯定的，对于WinCC和S7-300/400通信优化来说，在PLC方面还会考虑到以下几个问题：

1. PLC的循环读服务数（cyclic read services）。这是WinCC和S7-300/400通信时，比较独特的通讯优化方式，类似订阅的概念。基本过程可以简单的这样理解：每当打开/切换一幅画面时，系统会统计这画面中所使用的变量及这些变量的更新周期，将这些变量的请求按更新周期分类，形成“订单”并提交给PLC，PLC接受到“订单”后，按“订单”中所指定的更新周期，分批次的主动将数据定时的发给WinCC，而不需要WinCC再去定时的向PLC发请求。这样就可以有效提高数据交换效率。这里的一个“批次”就可以理解为一个“PLC的循环读服务”，而不同的PLC所支持的循环读服务数也可能有所不同，比如CPU416 最多支持32个，而CPU 412只有16个。多台WinCC同时访问一个PLC时，不但会占用PLC的连接资源，同时也会占用PLC的循环读服务数。
由于每个批次（循环读服务）所携带的数据数量是受到数据报文尺寸的限制，所以要把想要的PLC数据读上来，PLC就可能就会用到多个循环读服务。比如：当前WinCC画面中只有两个IO域连接了一个PLC 中的同一个地址：MW10，不同的是两个IO域的更新时间一个是500ms，另一个是1s，那么PLC会用两个循环读服务将数据发送给WinCC，一个是500ms的循环读服务，另一个是1s的循环读服务。这样的结果是不但多占用了循环读服务数，同时每个读服务的使用效率都不高。
画面，变量记录，报警，脚本系统等的变量请求对循环读服务的占用也是相似的。

关于循环读服务可以参考WinCC的在线帮助，里面有较详尽的解释。

2. WinCC使用的变量在PLC中的地址的是否连续，变量地址是否合理。连续地址意味着数据报文中携带的变量地址信息较少，可以简单理解：与数组的概念类似，起始地址信息+变量个数。虽然WinCC S7协议集具体的报文结构没有公开，而且地址排列也有特殊的算法，但对于地址不连续的情况后大概有何种结果，我想大家也能想到。而且也能用抓包和诊断工具看到变化。

变量地址是否合理：比如：同一个画面（也可以引申到变量记录，报警，脚本系统等）中所需的变量，在PLC中的地址最好连续排列。而若WinCC需要的所有数据都连续放在一个DB块中，但各画面所访问数据零星的分散在DB块中，这种情况下，一些夹在其间的无用数据也有可能被发给WinCC，即使WinCC并没有请求这些数据。
所以，变量地址连续、合理，可以有效提高PLC的循环读服务的使用效率，从而提高通讯效率。

另外, WinCC提供的通道诊断 （channelDiagnosis） 工具有很强的功能，在系统没有出现故障时，也可用来查看当前的通道信息，其中会反映所占用的循环读服务数、循环读服务的更新周期等等。建议可以试一试。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

今天细看了一下WINCC在线帮助，对我前面的说法又有了不同的观点，前面误导大家了，不好意思！
1.GetTagXXX函数是异步执行函数，当调用这些函数时，如果使用了周期性服务，并且周期性服务数量还没有用完，则要读取的变量就会在WINCC的映像区中注册。并且对于标准触发,周期性服务的更新周期是变量刷新周期的1/2，第一次注册完之后，以后AS的周期性服务就会主动的发数据给WINCC。所以如果变量刷新周期太短的话，则周期性服务的周期也会变短，这样通讯的负担就加重了。具体如下图所示：

2.对于GetTagXXX函数,如果不能使用周期性服务，WINCC将使用非周期性读取。但仍然进行注册，并从WINCC的映像区中读取。只不过AS不是主动发送，而是WINCC请求一次，AS发送一次，并且请求周期的排列也由WINCC来执行。
3.当一个画面关闭时或者被切换成非激活画面时，其使用的变量注册的周期性服务也停止了。但全局脚本中使用的变量注册的周期性服务会一直保留，直到WINCC停止运行，因为周期性服务数量是有限的，所以在全局脚本中建议使用加Wait的函数。
4.对于在象MOUSE CLICK这样的事件中使用GetTagXXX函数，当函数执行时，GetTagXXX函数首先要进行注册，然后就会周期性的从AS中请求数据(或者AS主动的发送数据)，当这个click事件结束，仍然还要从AS中周期性的请求数据直到画面关闭。这样就会加重WINCC的执行负荷。而解决的方法是采用GetTagXXXWait函数，虽然使用GetTagXXXWait函数会导致更高的通讯负荷，但不需要将变量在WINCC中进行注册，就不会进行周期性的请求数据。这样WINCC的执行负荷会减小。
5.如果在一个脚本中要读取的变量已经做为脚本的触发器使用过了，那么读取变量就直接从映像区中读取，而不会再去注册。因为在打开画面时，做为触发器的变量WINCC会自动进行注册,因为这种情况所有的变量一次性注册，效率是最高的。WINCC帮助中特别说明建议使用此种方式。
6.所有采用Upon change方式进行触发的脚本中使用的GetTagXXX函数，相当于1秒钟的循环读取服务。
7.在回调函数中一定要使用加WAIT的函数。
8.GetTagWait方式不进行注册，它只向AS请求一次数据。原理如下图所示：

9.WINCC的映像区的大小应该也是有限制的，注册的变量太多，WINCC的负担也会很重的。所以有时用一用WAIT的函数也是很好的,有时候并不是通讯过载，而是WINCC过载了，我前面说的关闭周期性服务，通讯就正常的情况，可能就是因为WINCC的负担太重了。
以上是我根据WINCC在线帮助和实际经验的理解，具体可以参考WINCC在线帮助，不过这一段是英文的，呵呵，我的英文不是很好，对内容解释的也不是很好！
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

关于影响WinCC通讯质量大家都不约而同谈到了如何优化WinCC组态项目的各种方法。如WinCC对过程变量的归档数量，和存取速度、精简脚本等方式。现我从Industrial Ethernet、PROFIBUS、MPI、ProfiNet这几种常见协议方式，与双绞线、光纤、同轴缆线等传输介质的选用角度，分析通讯质量。当通讯方式和传输介质确定后，在很大部分就决定了通讯质量，此外也将影响通讯质量。具体分析如下：
1。采用Industrial Ethernet协议和双绞线介质——这是目前WinCC通讯较流行和常见的方式，性价比高，兼容性也较好。它采用Internet使用的TCP/IP协议，应此还可连接上Internet网络。但该方式通讯采用竞争发送、冲突检测、载波侦听机制，速率不确定，无法做到实时性。取决于网络当前的通讯流量，由于采用双绞线，带宽有限、抗干扰能力差。因此，采用此方式通讯时，既不要与Internet网络相连，又不要与工控无关的电脑相连，这既可降低网络病毒攻击，又可减少网络数据包流量。
在WinCC组态项目中，应尽量减少循环的动态连接（如画面中的控件对象过多的与PLC中变量连接后，作动态位移运动，从而达到形象直观的效果），以降低WinCC与PLC间通讯负担。
但当WinCC在常态工作时，数据包流量都很大（即CP443-1模块上TXD指示灯几乎在任何时候都常亮不熄灭），这说明网络内有多台WinCC的Server与一台PLC通讯，或一台PLC与另一台、及多台PLC通讯，且约定的通讯Byte数也较多。解决方法是1：可采用光纤介质，改善网络带宽，提高传输的抗干扰能力；2：增加一台WinCC的Central Archive Server，从而减少WinCC的Server数量，这可大大降低PLC的通讯负担。
2．采用PROFIBUS协议和PROFIBUS缆线——这是SIEMENS工控网络的标准方式，大多数老一些的SIEMENS工控用户均采用此方式。PROFIBUS协议分DP、FMS、PA三种，其中DP协议较为常见。采用此方式时，安装有WinCC的OS站上必需一块CP5611，或CP5613网卡。这时每台WinCC监控站开启后都作为PLC的DP远程从站进行通讯。但当WinCC监控站电脑故障，或CP5611/CP5613网卡坏需关机更换或维护等情况时，极易造成其它的远程DP站通讯中断，而影响生产，所以采用此方式缆线应尽量连接成环网。
在生产要求高可靠性的地方，此时应采用FMS协议方式。但采用FMS协议需在PLC主站上增加一块Profibus通讯模块（如CP443－5或CP342－5）。这样，每台WinCC监控站与PROFIBUS通讯模块进行通讯联系，在物理上分开了与远程DP从站的联系，这除了对生产的安全可靠性得到提高外，还降低了远程DP从站的数量，从而降低了PLC的CPU处理DP从站的通讯负担，与每台WinCC监控站的通讯由PROFIBUS通讯模块完成。但此FMS协议方式需增加一块Profibus通讯模块（增加硬件成本）。
PA协议方式适用于现场智能设备（如一些智能变送器、智能传感器与PLC的连接）。总之，由于Profibus主站间通讯采用Token Ring（令牌环）方式轮转，WinCC通讯实时性较Industrial Ethernet好，通讯时间间隔相对稳定，网络遭病毒攻击的可能性小，网络安全性也较Industrial Ethernet高。
3．采用MPI协议——这是点对点的连接方式，通讯速率仅为187.5Kbps，类似于串口通讯。且WinCC只能与单台PLC通讯，所以速率慢，通讯范围窄，仅适用于单台现场控制设备和局部范围的通讯。
4．采用PROFINET协议——这是SIEMENS公司的一种基于PROFIBUS－DP和Industrial Ethernet之间的协议（即实时以太网）。它基于Industrial Ethernet，采用TCP/IP标准，所以可将现场级（I/O Field）设备连接到管理级，并且还能实时通讯（Real Time）能力，因此兼具两种网络的优点。这也是SIEMENS公司目前向市场首推的通讯方式。
但目前SIEMENS公司支持PROFINET通讯功能的模块较Industrial Ethernet通讯功能的模块价格贵，市场用量不大。因此如果管理层用户在办公室不需实时掌控现场级设备状况，可不必采用该通讯方式。现场级设备实时状况应更多的由操作人员，和工程师门去掌控和处理，这样更利于分级的管理和设备的运行安全。
以上就是我对SIEMENS公司PLC与WinCC间通讯的使用经验之谈，供大家分享。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

一同事做wincc与300通讯，激活wincc“通道诊断“里连接状态正常，但是变量管理中监测质量代码0x4C无值，而Step7在线有数值；
后来检查发现，其项目中没有调用过该变量，画面里添加I/O域显示后，正常。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

今天想到WINCC通过以太网的通讯方式有两种,一种是工业以太网，一种是TCP/IP。工业以太网方式采用ISO协议进行通讯，而TCP/IP呢？是直接采用TCP/IP通讯，还是网上有人说的ISO ON TCP？这两种方式，哪种方式的通讯效率更高呢？
带着这两个问题，我做了一下实验，采用WINCC和CP343进行通讯，组态硬件、下载、一切正常之后，启动WINCC通讯正常。在DOS窗口下，键入以下命令：
netstat -a
回车以后显示当前计算机所有连接的端口信息，WINCC TCP/IP连接的端口信息如下图所示：

可以看到，WINCC连接CP343(IP地址为192.168.0.197)的ISO-TSAP(102)端口。证明WINCC与CP343之间的TCP/IP通讯是采用ISO ON TCP协议。
因为TCP协议本身是基于字节流的，对于工业控制设备实现起来很不方便，ISO 协议是基于数据包的，对于工业通讯实现起来更简单，但ISO协议不支持路由功能，因为它没有IP层。ISO ON TCP通讯是在TCP通讯的基础上把数据进行分段和重组，使之符合ISO协议的标准，其底层仍然是TCP协议。
综上所述，ISO ON TCP通讯效率更低一些，所以，如果不使用路由功能，建议使用ISO协议进行通讯，因为省掉了分段和重组的时间，通讯速度应该会更快一些。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

客户机可以建项目（多用户分布式结构），也可以不建项目而直接访问服务器的项目（标准客户端）。
如果有了PDLCache进行缓冲画面文件，分布式项目一般要比标准客户机快，而且对服务器资源占用少。
若只对PLC的通讯负荷来说，两者的区别不大，它们都会将请求交与服务器，由服务器向PLC请求数据。举个例子：若两台客户机的当前画面的IO域同时对一个服务器的相同变量 tag1（MW10）进行访问，并且两个IO域的更新周期相同，那么在服务器上能看到：服务器对PLC的这个变量请求只有一个，也就是说：服务器在大多数情况下会对来自于多个客户端的变量请求进行自动优化（合并），有效减少PLC循环读服务的使用量，从而降低PLC和总线上的通讯负荷。这是客户机服务器结构的一个重要的优点。
当然这种优化效果在B/S结构中也可以看到，即web navigator的应用。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

Named Connection是基于S7协议，所有的Named Connection连接都需要先建立一个PC Station，然后在PC Station与CPU之间建立S7连接，这个连接是可以取名的，呵呵，也许这就是“Named Connection”的含义。这里PC Station与CPU之间的S7连接和两个CPU之间的S7连接应该没有什么不同，而且这个连接可以是单向连接，也可以是双向连接。如果是单向连接，则相当于PUT+GET，这时可能和OP协议也没什么不同了，关键是PUT+GET（SFB/FB14，SFB/FB15）方式一次最多只可以传送2百多个字节，而如果是双向连接(SFB/FB12,SFB/FB13)，则一次最多可以传送64K字节，这样对于大量数据通讯,通讯效率将会很大的提高。
WINCC采用Named Connection与PLC通讯，会通过应用程序访问点、S7连接名称，调用S7-API函数去执行S7读写服务。S7-API是SIEMENS提供的针对S7协议的应用程序接口,通过这个接口去执行S7读写服务，应该能获得S7通讯的最强大的功能。
而S7-OP协议可能是对S7协议进行了一些封装，使之比较适合各种屏或者通讯数据量不大的PC和PLC之间的通讯，通过S7 OP这个接口，WINCC不能获得S7通讯提供的全部功能。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

严重同意四书五经！！OP是一种特殊的S7协议，一种S7协议的变形。
说起BSEND/BRECV，有个现象很有趣：
当WinCC用BSEND/BRECV类型的RAWDATA时，需要在通道属性里打个勾，填上和PLC通讯的连接资源号。不打勾之前，是OP连接，但打了勾之后普通的TCP等连接也变成了S7连接。也就是说WinCC S7通道里并不是只有named connection可以是S7连接。故应该不能直接说named connection一定优于其他S7连接，至少S7和OP的连接类型的区别不能作为证据。
但问题又来了：
既然S7通道中的TCP等连接可以实现S7连接，为什么WinCC默认设置里，并没有打钩。是因为打了勾后，通讯设置变复杂了吗？很有可能，或者说是一个原因。但我认为也有可能是OP连接更适合上位机的应用特点。
正所谓尺有所短，寸有所长。
WinCC的BSEND 型RAWDATA，效率高，数据量大，但一般很难在WinCC中用到，不能归档，不能画面显示，只能用脚本拆，PCS7中使用到RAWDATA来传消息，但印象中好像也是普通的SEND/RECV（200多个字节）不是BSEND类型的。Bsend功能介绍的也很少，帮助里有一段，前一阵网上课堂有一个关于Bsend的文档。
即便使用S7连接，从通道诊断中一样可以看到通讯所使用的PDU：300是240字节，400是480字节。也就是说OP和S7的数据包大小是一样的，它取决于CPU类型而不是连接类型。而bsend的n KB尺寸是由7层模型中更上层来决定的，由第7层？说不好，也并不需要太关心。
循环读服务所携带的变量数才是要关注的，S7连接和OP连接一样也支持此服务，它直接影响到通讯性能和效率。而它又受到PDU的限制，但不会使用BSEND的尺寸。这一点从通道诊断中可以看出，但似乎看不出两者数量上差别。

另外，既然OP是S7的一种变种，少了部分不常用S7的功能（BSEND等），那有没有可能多出一些其他功能呢？很难排除这种可能性，我的观点是不排除。
综上所述，我的观点是：到目前来看还无法证明WinCC 的named connection 连接比其他方式能提供更高的通讯性能。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

不管是否使用周期读服务，只要不使用加Wait的函数，则WINCC都是使用异步通信机制与PLC进行通讯。昨天，我做了一个实验，硬件环境为CPU314C-2DP，CP343-1，装有WINCC的笔记本。
首先正确组态，下载硬件。然后在WINCC中建立S7-TCP/IP连接，再建立30个TAG，类型为浮点型，地址分别为MD0、MD4、...MD120。在全局动作中编如下程序：
float i,j,k;
i=GetTagDouble("NewTag_1");
j=GetTagDouble("NewTag_2");
SetTagDouble("NewTag_21",i+j);
...
脚本中含如上代码共10个,全局动作采用周期性触发，触发周期设为1S。使用周期性服务，采用异步通信机制,第一次运行时间较长，为1594MS，说明映像区里没有数据，需要从PLC读取数据（并在映像区中进行了注册），以后整个脚本的运行时间基本为0MS（不是毫秒级的），运行速度非常快，WINCC根本没有直接与PLC进行通讯，只是从映像区中读取了数据。把周期性服务关掉，函数不加WAIT，第一次运行时间为1250MS，同样，说明映像区中没有数据，需要从PLC中读取数据（并注册），以后脚本的运行时间基本为16MS，运行速度也很快，但比周期性服务的要慢一些，说明采用周期性服务对于数据采集还是很有效果的。
给4个Get加上WAIT函数后,第一次执行时间为1672，呵呵，第一次执行，不管是同步还是异步执行时间都差不多，以后执行周期基本为600MS，说明加WAIT的函数后是同步通讯，执行时间明显加长。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

对于WinCC服务器既有客户机，又有和PLC的以太网连接同时存在的情况下，用两块网卡将两种数据分开走，以提高性能，客户机走一块网卡，plc 通讯走一块网卡。
此方法可以推广至WinCC和多PLC通讯，走profibus，或以太网
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

同意四书五经。
一般Get...函数都是异步的，带Wait的是同步。
而使用周期服务和没有使用的区别应该是：是否采用订阅机制。
WinCC的S7连接和OP连接都支持基于异步的订阅发式
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。