|
接到一个Case,SI(系统集成商)在现场调试一条锻压线,使用的S7-300 + WinCC。客户反应说WinCC画面上的变量刷新很慢,并且每次更换设备模型时,WinCC脚本的逻辑就不正常,关键是这个脚本在其它项目上工作是正常的,只是WinCC版本不同。由于区域同事去现场也没有彻底解决,并且客户调试正处在关键时期,因此需要马上去现场诊断解决问题。
WinCC版本:WinCC 7.3 update12。C/S架构:服务器冗余,10多用户客户端。
- 部分画面变量刷新比较慢,10秒左右。
- 在生产线更换设备模型时,WinCC画面会卡死,变量不刷新,也无法进行画面切换,并且持续的时间会长达几个小时。
- 修改画面的刷新频率,设置了WinCC客户机使用本地画面缓存,刷新速度有所改善,但也只能优化到10s刷新一次,这速度无法接受。
发现WinCC 的TCP/IP通信连接的逻辑设备名称选择的是“网卡.TCPIP(Auto)”,这种使用是不推荐的。把逻辑设备名称 从 “网卡.TCPIP(Auto)“ 改为 ”网卡.TCPIP ”后 ,通信速度改善明显,变量刷新速度客户接受。
接着处理脚本逻辑问题,客户的脚本逻辑很简单:
If (条件变量=1)
{
为200个变量赋值;
}
但是这段脚本执行后,发现即使条件变量不等于1了,脚本也会一直不停的写那200个变量。这就造成WinCC画面会卡死。同时观察到有大量的WinCC写请求(有时能达到几万个)。
检查脚本,发现这段脚本在画面上并且是周期触发(触发周期1秒)的。这样就有问题了,正常情况下WinCC的通信都是“写优先”,当需要写入的变量数很多时,变量的刷新就会有延时。也就是说脚本中的“条件变量”由于写入的变量较多,并且一个触发周期无法处理完这些写操作,从而造成不能正常刷新“条件变量”。这样等到下一个周期还会继续执行“为200个变量赋值”的操作,这样就形成了死循环。
找到了原因就好办了,把脚本放到全局动作下,并且使用“条件变量”触发这个动作。这样整个程序就工作的很正常,运行操作都很流畅。
大家也都知道现场解决问题,没有这么顺利的,这次也遇到了干扰项,为此又花费了好多时间去找原因。
脚本放到全局动作后,开始时工作很正常,突然原来的故障又莫名其妙的出现了。
这个时候就怀疑在WinCC项目中的其它地方也在操作这些变量。使用交叉索引后,搜索变量,没查到问题。
后来才知道,是现场有操作工启动了WinCC客户端程序,原来有问题的脚本又在执行。但由于每个客户端距离服务器比较远,所以没有发现。
最后把画面中的脚本部分全部删掉,问题彻底解决。
来源:西门子工业技术论坛 |
|