LABVIEW提供了幾種定時器(包括DELAY),如下圖所示 首先看看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是一個相當重要的特點,相當于VB 的DOEVENTS,CVI中的PROCESSSYTEMEVENTS,實際是歸還控制權給操作系統,來處理隊列中的其他消息,如果沒有消息需要處理,系統馬上把控制權交給這個線程,繼續運行. 這里有兩種情況,如果系統消息隊列中無需要處理的消息,立即返回,如果系統消息隊列中有消息需要處理,并且是一個耗時操作,無法預料LV線程何時再次取得控制權.我們比較LV是否加WAIT 0MS的速度. 實驗過程中未執行其它任何操作,避免了處理其他消息造成的影響.兩者之間,差距是驚人的.這也體現了LABVIEW的一個優點,對于一個傾向于硬件控制的編程軟件,它有著極強的任務搶先能力. 在一個循環里多次并行執行WAIT,是累加時間,還是按最長的執行那,實際上是異步的還是同步的問題.我們做一下實驗. 可見,這三個WAIT是同時執行的. 由于WAIT是基于線程的,一個循環里的WAIT不會影響同時運行的其它線程的運行. 看看WAIT UNTIL NEXT MS MULTIPULE(等待下一個毫秒的整數倍). 一直等到毫秒定時器變成指定時間的整數倍.可以用于在一個循環中調節循環的執行速率.但是第一次的循環周期可能比較短.可以直接連接0到這個節點,強迫當前線程放棄控制權,歸還給CPU. 相比WAIT MS,這個節點在循環中更為常用,對于幾個采用相同參數的WAIT UNTIL NEXT MS MULTIPULE,可以實現不特別精確的同步.由于LABVIEW的循環的特點,首次是立即執行的,所以第一次是不能保證同步的.如果必須要保證同步的話,可以在循環中第一次執行空循環來避免這個問題. LABVIEEW EXPRESS中也提供了兩個快速VI,一個相當于WAIT MS,另一個可以實現非常復雜的定時功能. 我們先把TIME DELAY EXPRESS VI轉換成常規VI,跟蹤一下它是如何實現的. 進一步跟蹤SUBTIMEDELAY 可見,實際上還是調用的WAIT MS,不過是數據類型換成的DOUBLE,表示秒數,同時增加了錯誤簇,有利于實現順序延時動作.其他完全等同于DEALY MS. 可能是在LV7.1后新增加了這個ELAPSED TIME快速節點,這是一個非常有用的定時器.先介紹一個OPENG中提供的比較簡單的定時器. 這是一個周期軟件定時器.可用于周期性地循環觸發事件. 看看它是如何實現的. |