現場用戶反映，更換CPU后，S7-300 通過集成的DP接口連接的驅動工作不正常了，控制的轉速突然增加，造成部分生產的產品不合格。用戶使用USS方式測試也沒有問題，所以Zui終懷疑是DP與驅動設備通信中斷造成轉速發生跳變。

現場工程師到現場后按照用戶的問題描述就測試DP通信了，結果什么也沒有測試出來，在CPU的診斷緩存區中也沒有掉站故障信息，然后就懷疑是不是這個批次PROFIBUS芯片有問題，這下就麻煩了，被帶進溝里了，而且很深，爬不出來了，沒有辦法找到我這里進行咨詢。

我聽了一遍問題的描述，首先排除產品問題，如果產品的問題，可以使用一個分布式I/O測試一段時間，如果沒有問題，就可以說明產品沒有問題。再說了，產品有問題也是可以正常工作一段時間或者通信完全不能建立，而且沒有報DP從站故障，怎么也不能懷疑產品問題吧。

不是產品問題那只能是程序問題了，我讓現場工程師問一下用戶，驅動是使用PID進行動態調速還是直接由主站發送一個設定的轉速？結果是使用STEP7 中集成的PID FB41進行調速的。我讓現場工程師再看看程序，是不是FB41在OB1中調用的，結果也是按照我猜想的那樣，這樣問題的原因就找到了。

下面是問題的分析：大家還記得FB41有一個參數 “CYCLE” 吧，這個參數是兩次調用FB41的間隔，如圖1所示：

圖1 FB41參數

如果是1s，就需要在設定循環中斷為1s的OB塊中調用，所以說參數“CYCLE”與OB35設置的循環中斷時間有關。“CYCLE” 設定完成后才能決定積分時間和微分時間，例如TI要求 >=5* CYCLE，如果在OB1中調用，參數 “CYCLE” 、 “TI” 和 “TD” 的值可能都是調試的結果而不是在正確條件下整定的值。TIA博途中新增加PID指令“PID_Compact” （只適用于S7-1200/1500），早期版本中帶有循環時間這個參數，如果設定的值與循環中斷OB的設置時間不匹配，在自整定時會報錯。

新版本中，自整定會自動計算出循環時間，根據這個值再修改循環中斷OB的設定值。新CPU更換后，掃描周期快了好幾倍，原來的PID參數當然就就不適合了。還是這個原則，CPU快了反而出錯了一定是程序編寫的不嚴謹。從另外一點也可以看到，后續推出的軟件也越來越智能，如果當時用戶使用了S7-1500，整定時報錯，可能就會避免上面的問題。

現場是一個零件加工設備，控制器使用一個S7-300的CPU。設備加工是按順序執行的，程序使用Graph編寫，Graph也特別適合順控，走完一步后再執行下一步，每一步都有確定的操作任務，執行完所有步驟后返回再加工新的設備。現場問題描述是這樣的：完整加工一個零件后再更換新的CPU，啟動設備后，加工過程就停止了，換回舊CPU后操作正常。

問題的描述是現場工程師告訴我的，我聽了也不相信，這種事怎么可能呢？更換新CPU不就是想提高CPU的掃描速度，從而加快加工的節拍嗎，按照常用的方法加延時，怎么也會正常啟動吧，結果這回不好使了，沒有辦法只能自己去現場了。

到了現場后，等零件全部加工完后，更換CPU，下載程序并啟動設備運行，設備好像嘗試動了動又停止了，CPU沒有報任何故障信息，換回舊CPU后設備可以正常運行。難道程序有BUG？再次更換新CPU并加延時程序，設備還是不能運行，說明現場工程師的描述是正確的。加延時程序也不行，說明不是程序的BUG，而是程序中的狀態保持了，沒有滿足當前的條件所以不能運行。

記得有一次到啤酒廠測試DP通信，控制也是一步一步按順序運行，在沒有全部運行結束前是不能停機測試的。借這段時間做了些準備工作，例如檢查網絡拓撲、DP接頭是否帶有編程接口等，結果卸下DP通信接口蓋板時不巧碰到了CPU的啟停開關，CPU切換到STOP模式，我趕緊再切換到RUN模式，表面一切正常，但是過程不往下執行了，就是條件不滿足導致順序被卡住了。現場看程序解決問題是不切合實際的，Zui后只能找熟悉程序的工程師手動一步一步往下走，完成一個循環后再切換到自動運行。

有了這個經驗后，判斷CPU中原先DB塊中肯定存儲著狀態值，下載硬件后導致狀態變化而不能正確運行。

  先初始化GRAPH的實例化數據塊，還是不能運行。既然這樣了也別一個DB塊一個DB塊的初始化了，使用CPU上的開關直接全部初始化DB塊，然后再次運行設備。設備也是經過了一段加工前的準備工作后才開始正常的加工工作。有點明白了，全新的設備開始運行時會進行準備工作，準備工作完成后記錄一些信息到DB塊中，第二次操作就不需要再次做準備工作了，更換CPU可能導致部分數據丟失（測試時使用新的MMC卡）。所以更換任何CPU都會導致加工過程中斷的，還有就是程序是上載的，DB塊中帶有過程值，如果使用Zui初始的程序，可能也就沒有問題了。