編程通過OPC方式實現(xiàn)PC機(jī)與西門子PLC通訊
在上一次發(fā)表的<運(yùn)用VC#編程通過OPC方式實現(xiàn)PC機(jī)與西門子PLC通訊>主要講的是同步通訊，本文將主要講解如何編程實現(xiàn)異步通訊，通過講解你也將會知道同步通訊與異步通訊的區(qū)別，以及在什么情況下使用異步通訊。

1、 配置OPC服務(wù)器
　　對于服務(wù)器的配置與同步通訊的配置一樣，這里不需再講解，若有不清楚的，可以參閱之前發(fā)布的<運(yùn)用VC#編程通過OPC方式實現(xiàn)PC機(jī)與西門子PLC通訊>

2、 OPC編程
　　變量組、項的命名規(guī)則與同步通訊的一樣，這里不再描敘，下面主要就開發(fā)一個異步通訊類 AsynServer來講解如何編程。

<2>、編程
　　異步編程的原理就是在OPC服務(wù)器那邊檢測當(dāng)前活動的變量組，一但檢測到某一個變量，譬如變量Q0.0從1變成0，就會執(zhí)行一個回調(diào)函數(shù)，以實現(xiàn)針對變量發(fā)生變化時需要實現(xiàn)的動作，在這里可以采用委托來實現(xiàn)該功能。

 上周，客戶反映當(dāng)WinCC集成到STEP7中做變量上傳時，發(fā)生了很詭異的事情：當(dāng)選擇DB塊中的Operator Control and Monitoring選項時，對鉤出現(xiàn)后瞬間消失？！如下圖所示（僅示意）。

 一開始真心不相信。眼見為實，客戶發(fā)來了項目，果真如此。進(jìn)一步檢測，發(fā)現(xiàn)該DB為FB背景數(shù)據(jù)塊，找到相關(guān)FB，做了如下測試：
1. 項目中其它的FB和DB塊沒有問題
2. 新創(chuàng)建的FB和DB塊沒有問題
3. 使用Reorganize進(jìn)行項目重組無效
4. 創(chuàng)建新項目，拷貝原項目中的問題FB和DB塊無效
 由此，推斷問題出現(xiàn)在該FB中，打開FB，也未發(fā)現(xiàn)異常。如下圖所示。

 事到如今，只能采取笨方法 —— 排除法了。
1. 將問題FB復(fù)制，刪除所有Network程序
編譯存盤后，重新生成DB，設(shè)置監(jiān)控屬性無效。推斷問題出現(xiàn)在Interface的接口參數(shù)中。
2. 刪除Interface中所有WinCC監(jiān)控變量（標(biāo)記為綠色三角）
編譯存盤后，重新生成DB，設(shè)置監(jiān)控屬性有效。推斷問題出現(xiàn)在Interface中的WinCC監(jiān)控變量中。
3. 逐一取消Interface中WinCC監(jiān)控變量的S7_m_c屬性，如下圖所示

 發(fā)現(xiàn)問題所在！Interface中定義的輸入?yún)?shù)的結(jié)構(gòu)變量CONTROL.MANUAL_AUTO_CHAIN的S7_m_c屬性被取消后，DB設(shè)置監(jiān)控屬性有效！
 經(jīng)過反復(fù)測試，F(xiàn)B中定義的結(jié)構(gòu)變量超過24個字符，即可產(chǎn)生先前描述的詭異現(xiàn)象。刪除多余的字符（CONTROL.MANUAL_AUTO_CHAIN-> CONTROL.MANUAL_AUTO_CHAI），問題解決，如下圖所示。

 在STEP7幫助中未發(fā)現(xiàn)對于變量名稱長度有24個字符的限制，而在WinCC中，變量定義RAWTAG時有24個字符的限制，可能和此有關(guān)。

 DB中的結(jié)構(gòu)變量名稱定義過長，雖然是小概率事件，但也給了我們一個很好的參考。