labview中的的幾種定時(shí)器

首先看看Tick Count 節點(diǎn)的幫助說(shuō)明:
返回毫秒定時(shí)器的值.
基準參考時(shí)間(0 毫秒)未定義,也就是說(shuō),不能把返回的毫秒數直接轉換成現實(shí)世界的時(shí)間和日期.必須注意當你使用這個(gè)函數進(jìn)行比較的時(shí)候,毫秒定時(shí)器達到2^32-1后反轉成0.
基準參考時(shí)間未定義,說(shuō)法比較模糊,難道會(huì )是個(gè)隨機數,那顯然不可能,如果是隨機數,那兩次調用TICK COUNT取得差值就不可能表示經(jīng)過(guò)的毫秒數.無(wú)論如何,必須有個(gè)時(shí)間的起點(diǎn).
API函數中也有一個(gè)類(lèi)似的函數:GetTickCount,該函數返回計算機啟動(dòng)以來(lái)經(jīng)過(guò)的毫秒數.在9X中,它讀取的是BIOS中保存的系統時(shí)鐘的滴答數,早期PC的ROM初始化Intel8259定時(shí)器芯片來(lái)產(chǎn)生硬件中斷08H。這個(gè)中斷有時(shí)稱(chēng)為"定時(shí)器滴答"中斷。中斷08H每隔54。925毫秒產(chǎn)生一次,或大約每秒18.2次。BIOS使用中斷08H更新存于BIOS數據區的"時(shí)間"值.這就是長(cháng)說(shuō)的55MS的由來(lái).對于NT操作系統,常規的說(shuō)法是能精確到10MS,也就是說(shuō)精度在1MS時(shí)是不精確的.
經(jīng)過(guò)實(shí)際測試,LABVIEW的TICK COUNT的返回值和API的返回值是一致的,也就是計算機啟動(dòng)以來(lái)經(jīng)過(guò)的毫秒數.
毫秒數達到2^32-1后反轉成0,可見(jiàn)它的數值形式是U32,最大值是2^32-1,大概相當于49.7天.對于一個(gè)連續運行的計算機,用這個(gè)節點(diǎn)進(jìn)行比較的時(shí)候,在連續運行49.7天后,該值自動(dòng)恢復到零,如果在這個(gè)時(shí)刻進(jìn)行比較,可能會(huì )出現錯誤的結果.
wait(ms)節點(diǎn)幫助文件中的解釋是這樣的.
等待指定的毫秒數并返回毫秒定時(shí)器的值(上面提到的計算機啟動(dòng)以來(lái)的毫秒數).如果WAIT (MS)連接0會(huì )強迫當前線(xiàn)程放棄控制權.
WAIT 0MS是一個(gè)相當重要的特點(diǎn),相當于VB 的DOEVENTS,CVI中的PROCESSSYTEMEVENTS,實(shí)際是歸還控制權給操作系統,來(lái)處理隊列中的其他消息,如果沒(méi)有消息需要處理,系統馬上把控制權交給這個(gè)線(xiàn)程,繼續運行.
這里有兩種情況,如果系統消息隊列中無(wú)需要處理的消息,立即返回,如果系統消息隊列中有消息需要處理,并且是一個(gè)耗時(shí)操作,無(wú)法預料LV線(xiàn)程何時(shí)再次取得控制權.我們比較LV是否加WAIT?。埃停拥乃俣龋?br />


實(shí)驗過(guò)程中未執行其它任何操作,避免了處理其他消息造成的影響.兩者之間,差距是驚人的.這也體現了LABVIEW的一個(gè)優(yōu)點(diǎn),對于一個(gè)傾向于硬件控制的編程軟件,它有著(zhù)極強的任務(wù)搶先能力.
在一個(gè)循環(huán)里多次并行執行WAIT,是累加時(shí)間,還是按最長(cháng)的執行那,實(shí)際上是異步的還是同步的問(wèn)題.我們做一下實(shí)驗.

可見(jiàn),這三個(gè)WAIT是同時(shí)執行的.
由于WAIT是基于線(xiàn)程的,一個(gè)循環(huán)里的WAIT不會(huì )影響同時(shí)運行的其它線(xiàn)程的運行.
看看WAIT UNTIL NEXT MS MULTIPULE(等待下一個(gè)毫秒的整數倍).
一直等到毫秒定時(shí)器變成指定時(shí)間的整數倍.可以用于在一個(gè)循環(huán)中調節循環(huán)的執行速率.但是第一次的循環(huán)周期可能比較短.可以直接連接0到這個(gè)節點(diǎn),強迫當前線(xiàn)程放棄控制權,歸還給CPU.
評論