現場去多了，就會遇到各式各樣的問題，有的比較簡單，有的比較復雜（多個原因疊加是比較難解決的）?，F場問題一定是由各種原因造成的。只要按部就班，循序漸進的對問題進行分析和測試，通常都可以解決的（除產品自身的原因外，自身原因也是可以通過測試驗證的）。

經常聽人說有的現場問題很奇怪，究其原因，可能獲知的信息不全，例如現場操作人員不了解PLC，故障描述往往就會漏掉了一些關鍵點。也可能自己的思路被人帶偏了，例如，有人說，現場PLC DB1中保持的數據丟失了，而DB2中的數據沒有丟失，是不是CPU受到干擾，正好干擾到DB1，結果DB1中的數據就丟失了。這樣的問題描述往往都是從現場人員的描述中提煉再轉達給你的，信息失真的同時也帶有別人的猜測，如果你信了，就會按照別人的思路去思考問題而陷入迷局，這也和自己沒有全面思考這個問題有關。下面分享三個案例，這三個案例都與CPU的更換有關，更換CPU后就出現問題了，讓我們一起分析一下這些奇怪的問題。

1

案例1：

這個案例是一個C7的改造項目，西門子Zui早推出C7/S7/M7，M7可能過于超前淘汰了。C7是西門子操作面板+S7 PLC集成一體的控制器，節省空間，PLC與操作面板也不需要連接線。不清楚是不是要淘汰，現場要求將C7換成S7-300 PLC和新的操作面板，真是合久必分呀。

現場除了面板的分辨率變化了，需要重新布置一下各元素的位置和大小外，PLC沒有任何改變，連移植都算不上，就是舊S7-300換成新S7-300了，程序直接下載就完成了。

設備運行后，現場調試工程師說出問題了，操作面板顯示的值不正確了。我第一反應就是連接的變量是否正確，需要確認一下數據源的值是否正確，結果在PLC的變量監控表監控，數值也是不正確的，這樣可以排除操作面板變量連接的問題。又換回C7，問題消除了。有人說是不是C7與現在PLC的處理機制發生變化了？我一聽，這是往溝里帶的節奏呀！

都是S7-300的CPU，處理程序當然是一樣的，唯一的區別就是新CPU比舊CPU掃描周期快了好幾倍，數值顯示有問題一定是程序的BUG。這下麻煩了，設備更換的總費用不包括解決程序BUG的費用，但是不解決問題就不能交工呀，所以還必須解決遺留的問題。在家里看了看程序，沒有前因后果的，又不在現場，沒有人解釋一下這些變量的出處，腦子就大了。只能想一個簡單的方法屏蔽程序的BUG了，我讓現場工程師查看一下舊CPU的循環周期，然后再查看一下新CPU的循環周期，之間相差了幾十毫秒。

然后讓現場工程師在新CPU中增加 “WAIT” 指令，讓新CPU的循環周期變慢，與舊CPU的循環周期相當就可以了。添加“WAIT” 指令也不需要考慮掃描變慢而影響工藝的控制要求，因為原來就是這樣的。指令增加后，數值顯示正常了?，F場工程師Zui后查看程序也找到了問題的原因，這個顯示的數值是一個計算結果，數據源來自一個傳感器，CPU一個掃描周期采樣一次并記錄，然后計算出兩個周期采樣值的差值，Zui后用這個差值再計算得到需要的顯示值。傳感器輸出值的變化率比較低，原來舊CPU的掃描周期也比較慢，正好每一個周期都能采集到不同的數值，這樣差值就不會為0。而新CPU掃描快了好幾倍，經常兩次或者三次采集的數值是相同，結果差值就為0了。使用0再進行計算，就會導致顯示的值不正確了。

問題的原因歸根結底就是源程序有BUG，應該使用一個時間中斷采樣并計算差值，總不能說CPU性能提高了反而不能使用了吧！這也是一個評判程序有問題的原則?，F場調試時間有限，也不想在這個問題上耗費太多的時間，使用簡單的方法處理這個問題何樂而不為呢！即使找出問題的所在也不好解決，因為你也不知道到底多長時間采樣一次才是Zui合適的。