關于“優化是不是也要從PLC有所考慮？”，答案是肯定的，對于WinCC和S7-300/400通信優化來說，在PLC方面還會考慮到以下幾個問題：
1. PLC的循環讀服務數（cyclic read services）。這是WinCC和S7-300/400通信時，比較獨特的通訊優化方式，類似訂閱的概念。基本過程可以簡單的這樣理解：每當打開/切換一幅畫面時，系統會統計這畫面中所使用的變量及這些變量的更新周期，將這些變量的請求按更新周期分類，形成“訂單”并提交給PLC，PLC接受到“訂單”后，按“訂單”中所指定的更新周期，分批次的主動將數據定時的發給WinCC，而不需要WinCC再去定時的向PLC發請求。這樣就可以有效提高數據交換效率。這里的一個“批次”就可以理解為一個“PLC的循環讀服務”，而不同的PLC所支持的循環讀服務數也可能有所不同，比如CPU416 最多支持32個，而CPU 412只有16個。多臺WinCC同時訪問一個PLC時，不但會占用PLC的連接資源，同時也會占用PLC的循環讀服務數。
由于每個批次（循環讀服務）所攜帶的數據數量是受到數據報文尺寸的限制，所以要把想要的PLC數據讀上來，PLC就可能就會用到多個循環讀服務。比如：當前WinCC畫面中只有兩個IO域連接了一個PLC 中的同一個地址：MW10，不同的是兩個IO域的更新時間一個是500ms，另一個是1s，那么PLC會用兩個循環讀服務將數據發送給WinCC，一個是500ms的循環讀服務，另一個是1s的循環讀服務。這樣的結果是不但多占用了循環讀服務數，同時每個讀服務的使用效率都不高。畫面，變量記錄，報警，腳本系統等的變量請求對循環讀服務的占用也是相似的。關于循環讀服務可以參考WinCC的在線幫助，里面有較詳盡的解釋。
2. WinCC使用的變量在PLC中的地址的是否連續，變量地址是否合理。連續地址意味著數據報文中攜帶的變量地址信息較少，可以簡單理解：與數組的概念類似，起始地址信息+變量個數。雖然WinCC S7協議集具體的報文結構沒有公開，而且地址排列也有特殊的算法，但對于地址不連續的情況后大概有何種結果，我想大家也能想到。而且也能用抓包和診斷工具看到變化。
變量地址是否合理：比如：同一個畫面（也可以引申到變量記錄，報警，腳本系統等）中所需的變量，在PLC中的地址最好連續排列。而若WinCC需要的所有數據都連續放在一個DB塊中，但各畫面所訪問數據零星的分散在DB塊中，這種情況下，一些夾在其間的無用數據也有可能被發給WinCC，即使WinCC并沒有請求這些數據。
所以，變量地址連續、合理，可以有效提高PLC的循環讀服務的使用效率，從而提高通訊效率。另外, WinCC提供的通道診斷（channelDiagnosis）工具有很強的功能，在系統沒有出現故障時，也可用來查看當前的通道信息，其中會反映所占用的循環讀服務數、循環讀服務的更新周期等等。建議可以試一試。
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
