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到另一个数据区，上位统一从那个数据区读取，这样上下位之间的通讯确实快了很多。
|
自动化资料下载
自动化产品
