WinCC 与 S7-300-400 通信优化技巧

作者: admin 分类: 房产 发布时间: 2019-07-11 10:53

  前用国产组态软件的时候,这方面考虑的比较多,但是在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.用国产组态软件的时候,软件自带有通讯监视程序,从中可以看到通讯通讯的打包情况和传输时间,而在WINCC中好像没有这个功能。而我要提到的是这样一个问题:PLC中有不同的数据存储区域,上位对这些区域的读取速度是否相同?

  比如同样100个数据,从DB块中读取和从M区中读取,速度是否相同呢?因为我之前曾有过一次精力,某软件读取某PLC中不同数据区的速度差别居然很大,从上位画面的反应上都明显感觉的出来,所以后来在PLC中多写了一段程序,就是在数据处理完之后,将数据统一move到另一个数据区,上位统一从那个数据区读取,这样上下位之间的通讯确实快了很多。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!