labview中的的幾種定時器
加入技術交流群
首先看看Tick Count 節(jié)點的幫助說明:
返回毫秒定時器的值.
基準參考時間(0 毫秒)未定義,也就是說,不能把返回的毫秒數(shù)直接轉換成現(xiàn)實世界的時間和日期.必須注意當你使用這個函數(shù)進行比較的時候,毫秒定時器達到2^32-1后反轉成0.
基準參考時間未定義,說法比較模糊,難道會是個隨機數(shù),那顯然不可能,如果是隨機數(shù),那兩次調用TICK COUNT取得差值就不可能表示經過的毫秒數(shù).無論如何,必須有個時間的起點.
API函數(shù)中也有一個類似的函數(shù):GetTickCount,該函數(shù)返回計算機啟動以來經過的毫秒數(shù).在9X中,它讀取的是BIOS中保存的系統(tǒng)時鐘的滴答數(shù),早期PC的ROM初始化Intel8259定時器芯片來產生硬件中斷08H。這個中斷有時稱為"定時器滴答"中斷。中斷08H每隔54。925毫秒產生一次，或大約每秒18.2次。BIOS使用中斷08H更新存于BIOS數(shù)據區(qū)的"時間"值.這就是長說的55MS的由來.對于NT操作系統(tǒng),常規(guī)的說法是能精確到10MS,也就是說精度在1MS時是不精確的.
經過實際測試,LABVIEW的TICK COUNT的返回值和API的返回值是一致的,也就是計算機啟動以來經過的毫秒數(shù).
毫秒數(shù)達到2^32-1后反轉成0,可見它的數(shù)值形式是U32,最大值是2^32-1,大概相當于49.7天.對于一個連續(xù)運行的計算機,用這個節(jié)點進行比較的時候,在連續(xù)運行49.7天后,該值自動恢復到零,如果在這個時刻進行比較,可能會出現(xiàn)錯誤的結果.
wait(ms)節(jié)點幫助文件中的解釋是這樣的.
等待指定的毫秒數(shù)并返回毫秒定時器的值(上面提到的計算機啟動以來的毫秒數(shù)).如果WAIT (MS)連接0會強迫當前線程放棄控制權.
WAIT 0MS是一個相當重要的特點，相當于ＶＢ 的ＤＯＥＶＥＮＴＳ，ＣＶＩ中的PROCESSSYTEMEVENTS,實際是歸還控制權給操作系統(tǒng)，來處理隊列中的其他消息，如果沒有消息需要處理，系統(tǒng)馬上把控制權交給這個線程，繼續(xù)運行．
這里有兩種情況，如果系統(tǒng)消息隊列中無需要處理的消息，立即返回，如果系統(tǒng)消息隊列中有消息需要處理，并且是一個耗時操作，無法預料ＬＶ線程何時再次取得控制權．我們比較ＬＶ是否加ＷＡＩＴ?。埃停拥乃俣龋?br />
實驗過程中未執(zhí)行其它任何操作，避免了處理其他消息造成的影響．兩者之間，差距是驚人的．這也體現(xiàn)了ＬＡＢＶＩＥＷ的一個優(yōu)點，對于一個傾向于硬件控制的編程軟件，它有著極強的任務搶先能力．
在一個循環(huán)里多次并行執(zhí)行ＷＡＩＴ，是累加時間，還是按最長的執(zhí)行那，實際上是異步的還是同步的問題．我們做一下實驗．
可見，這三個ＷＡＩＴ是同時執(zhí)行的．
由于ＷＡＩＴ是基于線程的，一個循環(huán)里的ＷＡＩＴ不會影響同時運行的其它線程的運行．
看看WAIT UNTIL NEXT MS MULTIPULE(等待下一個毫秒的整數(shù)倍).
一直等到毫秒定時器變成指定時間的整數(shù)倍.可以用于在一個循環(huán)中調節(jié)循環(huán)的執(zhí)行速率.但是第一次的循環(huán)周期可能比較短.可以直接連接0到這個節(jié)點,強迫當前線程放棄控制權,歸還給CPU.
評論