接到一个Case，SI（系统集成商）在现场调试一条锻压线，使用的S7-300 + WinCC。客户反应说WinCC画面上的变量刷新很慢，并且每次更换设备模型时，WinCC脚本的逻辑就不正常，关键是这个脚本在其它项目上工作是正常的，只是WinCC版本不同。由于区域同事去现场也没有彻底解决，并且客户调试正处在关键时期，因此需要马上去现场诊断解决问题。

• 现场情况：

        WinCC版本：WinCC 7.3 update12。C/S架构：服务器冗余，10多用户客户端。

• 现场问题：

1.  部分画面变量刷新比较慢，10秒左右。

2. 在生产线更换设备模型时，WinCC画面会卡死，变量不刷新，也无法进行画面切换，并且持续的时间会长达几个小时。

3. 修改画面的刷新频率，设置了WinCC客户机使用本地画面缓存，刷新速度有所改善，但也只能优化到10s刷新一次，这速度无法接受。
   

• 问题处理：

        发现WinCC 的TCP/IP通信连接的逻辑设备名称选择的是“网卡.TCPIP(Auto)”，这种使用是不推荐的。把逻辑设备名称 从 “网卡.TCPIP(Auto)“  改为  ”网卡.TCPIP ”后 ，通信速度改善明显，变量刷新速度客户接受。

        接着处理脚本逻辑问题，客户的脚本逻辑很简单：

        If （条件变量=1）

        {

             为200个变量赋值；

        }

        但是这段脚本执行后，发现即使条件变量不等于1了，脚本也会一直不停的写那200个变量。这就造成WinCC画面会卡死。同时观察到有大量的WinCC写请求（有时能达到几万个)。

        检查脚本，发现这段脚本在画面上并且是周期触发（触发周期1秒）的。这样就有问题了，正常情况下WinCC的通信都是“写优先”，当需要写入的变量数很多时，变量的刷新就会有延时。也就是说脚本中的“条件变量”由于写入的变量较多，并且一个触发周期无法处理完这些写操作，从而造成不能正常刷新“条件变量”。这样等到下一个周期还会继续执行“为200个变量赋值”的操作，这样就形成了死循环。

        找到了原因就好办了，把脚本放到全局动作下，并且使用“条件变量”触发这个动作。这样整个程序就工作的很正常，运行操作都很流畅。

• 节外生枝：

        大家也都知道现场解决问题，没有这么顺利的，这次也遇到了干扰项，为此又花费了好多时间去找原因。

        脚本放到全局动作后，开始时工作很正常，突然原来的故障又莫名其妙的出现了。

        这个时候就怀疑在WinCC项目中的其它地方也在操作这些变量。使用交叉索引后，搜索变量，没查到问题。

        后来才知道，是现场有操作工启动了WinCC客户端程序，原来有问题的脚本又在执行。但由于每个客户端距离服务器比较远，所以没有发现。

        最后把画面中的脚本部分全部删掉，问题彻底解决。

                                                                                                            -------来自 西门子技术支持工程师