寫在前面:之前做過一次1200的s7通訊,當時一方面是時間比較緊迫,另一方面也確實沒有用過s7通訊;在甲方的催促下匆忙的進行了程序調試;并未進行諸多的現場的各種可能性試驗,草草的就交了工.一直沒有接到甲方的程序故障,及其他的故障反饋.還沾沾自喜的認為S7-1200的s7通訊用的比較好.今年又一個項目用到了siemens S7-1200 s7通訊,下面分享下.

項目的簡單描述:項目使用的硬件就不進行詳細描述了,項目中共用到3塊PLC CPU模塊 (1GE31 v3.2兩塊,1BG31為之前項目s7通訊使用;1BG40 v4.0一塊);這個項目定義為之前項目的升級項目.今年新采購的v4.0版本cpu實際上可以理解為新增的”從站”；迅速的進行了程序編寫。調試過程中問題來了：

問題1；’get’’put’指令都拿不到v4.0版本CPU的數據。

針對這個問題反復的檢查’網絡組態’、’get、put’指令配置，幾經檢查均為發現問題；期間發生過幾次v4.0CPU的故障報錯，故障內容通俗點講是’錯誤的伙伴端口’．繼續查看書冊，詳細的通讀系統手冊，仍然沒有發現問題所在。身處地下室且大周末的，我們的4288客服電話也不無法接通。百無聊賴中發現了v4.0版本CPU中之前版本CPU版本中從未見到的一個復選框，如下圖：

順著箭頭向下我看到了個東西：

至此問題1得到了解決，緊著了問題2來了：

         問題2；1個1BG31主動去找另一1BG31和1BG40進行s7數據交互，一點時間觀察后發現數據不動了，幾次在線查看程序執行狀態發現：我認為是隨機的出現在’put’/’get’指令間。更明白的表述是會出現’status’=0x19;這個在手冊里是下面描述的：

為什么會出現這個狀態呢？反復的進行了測試后發現，如果v4.0CPU突然掉電，而s7通訊主動端的CPU沒有斷電，問題來了，整個通訊全部卡到這里了。持續觀察后總結為：s7通訊應該是單線程通訊，即，相同時間點相同端口只能執行一個通訊命令，無論是rj45口還是485口，不允許程序在相同時間相同端口執行不同的通訊命令，盡管s7基于rj45口數據交換時間短到ms級別，還是要求’順序執行’通訊程序。手冊中有這個說明：

那好吧：執行完一次’put’或者’get’命令后使用當前功能塊的’NDR(GET指令)’或者’DONE(put指令)’上升沿去觸發后續的’get’或者’put’指令。如同Modbus那樣一個完成去觸發后面的功能塊。處理完畢后問題不但沒有解決，進一步模擬后發現問題2有了新的升級

         問題2+；在s7非主動發起方突然掉電后，主動發起方程序執行不會給出’NDR’或者’Done’位，盡管使用的上升沿評估通訊請求是否執行完畢，程序停留狀態是’error’=false,’status’=

0x19;也就是說整個s7通訊會一直停留在這個狀態。看下程序塊的管腳（put與get比較類似，管腳舉例使用的是手寫中管腳，TIA V13打開太慢了--!）

其中是不是缺少了’reset’或者’timeout’?無奈只好個人在程序中添加了段’req’接通2s后強制復位所有的’REQ’請求！然后進行了被請求者斷電、發起者斷電、已經其他的現場可能出現的狀況。

結語：對于s7通訊來說，還是處于初學階段，而且PLC程序經常進入java思維，可能s7協議使用的就不規范，僅以此希望對那些剛剛接觸s7的人能有一點幫助，足矣！