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是一个相当重要的特点，相当于ＶＢ　的ＤＯＥＶＥＮＴＳ，ＣＶＩ中的PROCESSSYTEMEVENTS,实际是归还控制权给操作系统，来处理队列中的其他消息，如果没有消息需要处理，系统马上把控制权交给这个线程，继续运行．
这里有两种情况，如果系统消息队列中无需要处理的消息，立即返回，如果系统消息队列中有消息需要处理，并且是一个耗时操作，无法预料ＬＶ线程何时再次取得控制权．我们比较ＬＶ是否加ＷＡＩＴ　０ＭＳ的速度．

实验过程中未执行其它任何操作，避免了处理其他消息造成的影响．两者之间，差距是惊人的．这也体现了ＬＡＢＶＩＥＷ的一个优点，对于一个倾向于硬件控制的编程软件，它有着极强的任务抢先能力．
在一个循环里多次并行执行ＷＡＩＴ，是累加时间，还是按最长的执行那，实际上是异步的还是同步的问题．我们做一下实验．

可见，这三个ＷＡＩＴ是同时执行的．
由于ＷＡＩＴ是基于线程的，一个循环里的ＷＡＩＴ不会影响同时运行的其它线程的运行．
看看WAIT UN ......

>>返回讨论的主题