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