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