我們日常編程中在使用定時器后，發(fā)現定時器并沒有按照自己的意圖去計時，出現了不計時的錯誤，進而懷疑是否是硬件故障，CPU是否正常等等，浪費了很多的時間去排查，實際上就是由于我們對定時器的特性不了解所造成的誤解，下面我們來看看幾個例子：

程序設計的本意是：I4.2的上升沿觸發(fā)T50和T60定時器，并在T60定時結束后復位M12.0。

可是在仿真發(fā)現，I4.2可以觸發(fā)T50和T60定時器，但有時即使I4.2再次將M12.0置位為1，但T50不計時，現象如下圖：

問題分析：首先明確不是硬件故障，也不是語句錯誤引起的，而是定時器使用不正確引起的：

1 某個掃描周期：I4.2的上升沿置位M12.0，I4.2恢復為0

2 數個掃描周期后，假設第N個掃描周期，當T60計時到時，網絡2中的M12.0被復位(注意在SD T50語句的后面)，此掃描周期末M12.0由1變?yōu)?。網絡3中的T50和T60被復位。

3 在第N+1個掃描周期，如果此時I4.2恰好出現上升沿，盡管M12.0在上個掃描周期曾經變?yōu)?，但在本周期開始就變?yōu)榱?，定時器T50在上個掃描周期接受到M12.0狀態(tài)為1，定時器T50在本掃描周期接受的M12.0的狀態(tài)也為1，所以T50不會工作。

定時器的錯誤分析如下圖所示：

定時器的正確使用應如下圖所示：

說的再明白些就是定時器的使用在掃描周期N和N+1之間正確接收到上升沿的變化，這樣定時器才會正確工作。

本例中的故障很隱蔽，在我們使用中可能幾天運行都不會有定時不工作的情況，突然偶爾出現一次，排查起來很費勁，所以在我們編程中要遵守定時器要想計時工作必須接收到輸入端上升沿的變化。

那么遇到這種情況應該怎么改呢？

小編這里提供個思路：可以在置位M12.0之前增加一些限制條件。

另外要說的就是定時器的定時與程序掃描周期

在S7系列CPU中，定時器的最小時基為10ms，也就是說，S7CPU的最小定時時間為10ms，如果用戶程序的代碼量比較大，程序掃描周期過了10ms可能會出現如下情況：盡管定時時間已經到了，但CPU還沒有執(zhí)行到相關的程序邏輯。

針對這種情況：當用戶程序需要非常短的定時功能時，需要考慮程序掃描周期對定時器狀態(tài)讀取的影響，由于CPU中的定時中斷是由硬件來保證的，并且高于0B1的優(yōu)先級，所以這種情況下，考慮使用定時中斷功能來替代定時器的功能。

另外的問題就是當編程時遇到CPU提供的硬件定時器不夠用的時候，這時候可以使用系統(tǒng)提供的軟定時器，例如SFB4，此功能塊需要一個背景數據塊。

時序圖如下：

在使用SFB4的時候要注意的一個問題就是CPU重啟后軟定時器復位的問題。

由于SFB的定時,計時值存在DB中，由于CPU斷電或停機后，DB數據時保持的，如果定時器計時到在停機前已經計時，那么當CPU重新運行后(定時器輸入端仍然為1的情況)，定時器將會在原來計時位置繼續(xù)計時，為了避免這種情況的出現，可以在0B100中添加如下語句來初始化SFB4的背景數據塊

總結

以上是生活随笔為你收集整理的spring定时器突然不执行了_编程中常常遇到了定时器不工作的问题分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。