上周，客戶反映當(dāng)wincc集成到step7中做變量上傳時(shí)，發(fā)生了很詭異的事情：當(dāng)選擇db塊中的operator control and monitoring選項(xiàng)時(shí)，對(duì)鉤出現(xiàn)后瞬間消失？！如下圖所示（僅示意）。
一開(kāi)始真心不相信。眼見(jiàn)為實(shí)，客戶發(fā)來(lái)了項(xiàng)目，果真如此。進(jìn)一步檢測(cè)，發(fā)現(xiàn)該db為fb背景數(shù)據(jù)塊，找到相關(guān)fb，做了如下測(cè)試：
1. 項(xiàng)目中其它的fb和db塊沒(méi)有問(wèn)題
2. 新創(chuàng)建的fb和db塊沒(méi)有問(wèn)題
3. 使用reorganize進(jìn)行項(xiàng)目重組無(wú)效
4. 創(chuàng)建新項(xiàng)目，拷貝原項(xiàng)目中的問(wèn)題fb和db塊無(wú)效
由此，推斷問(wèn)題出現(xiàn)在該fb中，打開(kāi)fb，也未發(fā)現(xiàn)異常。如下圖所示。
事到如今，只能采取笨方法 —— 排除法了。
1. 將問(wèn)題fb復(fù)制，刪除所有network程序
編譯存盤(pán)后，重新生成db，設(shè)置監(jiān)控屬性無(wú)效。推斷問(wèn)題出現(xiàn)在interface的接口參數(shù)中。
2. 刪除interface中所有wincc監(jiān)控變量（標(biāo)記為綠色三角）
編譯存盤(pán)后，重新生成db，設(shè)置監(jiān)控屬性有效。推斷問(wèn)題出現(xiàn)在interface中的wincc監(jiān)控變量中。
3. 逐一取消interface中wincc監(jiān)控變量的s7_m_c屬性，如下圖所示
發(fā)現(xiàn)問(wèn)題所在！interface中定義的輸入?yún)?shù)的結(jié)構(gòu)變量control.manual_auto_chain的s7_m_c屬性被取消后，db設(shè)置監(jiān)控屬性有效！
經(jīng)過(guò)反復(fù)測(cè)試，fb中定義的結(jié)構(gòu)變量超過(guò)24個(gè)字符，即可產(chǎn)生先前描述的詭異現(xiàn)象。刪除多余的字符（control.manual_auto_chain-> control.manual_auto_chai），問(wèn)題解決，如下圖所示。
在step7幫助中未發(fā)現(xiàn)對(duì)于變量名稱長(zhǎng)度有24個(gè)字符的限制，而在wincc中，變量定義rawtag時(shí)有24個(gè)字符的限制，可能和此有關(guān)。
db中的結(jié)構(gòu)變量名稱定義過(guò)長(zhǎng)，雖然是小概率事件，但也給了我們一個(gè)很好的參考。