WinCC與S7-300400通信的過程中要考慮的內容主要包括：

　　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到另一個數據區，上位統一從那個數據區讀取，這樣上下位之間的通訊確實快了很多。