Labview提供了五种定时器：普通定时器3种： Tick Count (ms)、 Wait(ms)、Wait Until Next ms  Multipule（等待下一个毫秒的整数倍）

API函数定时器2种：Time Delay和Elapsed Time。

下面详细说明一下各定时器的作用于区别：

1、Tick Count(ms)-------返回毫秒定时器的值

基准参考时间(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天后,该值自动恢复到零,如果在这个时刻进行比较,可能会出现错误的结果.

2、Wait(ms)------等待指定的毫秒数并返回毫秒定时器的值(上面提到的计算机启动以来的毫秒数)。

等待指定长度的毫秒数，并返回毫秒计时器的值。等待时间指定要等待时间，以毫秒为单位。函数的等待时间不超过0x7ffffff，即2147483647毫秒。如需等待更长的时间，可再次执行函数。  
将0连接到毫秒计时值输入，可迫使当前线程放弃对CPU的控制。  
该函数作出异步系统调用，但是函数节点却是同步操作的。所以，直到指定时间结束，函数才停止执行。  
该内置函数在程序中通常被用来做定时器或延迟器使用。它的输入端为所期待的定时数值（以ms为单位），它的输出返回毫秒计时器的值。  
       由于等待（ms）是一个LabVIEW的内置函数，所以我们根本无法了解其程序内部的执行的方式或运行方法。但是我们可以通过不同的编程形式运行的结果来间接的认识和了解它。  
先看下面的例子，参见图1-2：

在图1-2中，我们为等待（ms）内置函数设定一个1000ms的定时值，程序运行后它的输出“毫秒计时值”则显示出一组无法确定的数据，并且每次程序运行后该输出值都是不一样的，但趋势是不断增加的。这里显然是等待（ms）定时器的起始时间是一个不断改变的数值，这究竟是为什么呢？

图1-3的运行结果显示，此时我们可以获得与输入设定值一样的“毫秒计时值”。很显然等待（ms）内置函数中包含了一个类似于“时间计数器”的内置函数，他们在某一时刻同步开始操作，这样我们就可以在等待（ms）的输出端获得稳定的“毫秒计时值”。

现在可以说是清楚了，等待（ms）内置函数和时间计数器内置函数的起始工作时刻是来自计算机启动以来所经过的毫秒数，所以我们才会看到图1-2程序运行后，它的输出“毫秒计时值”则显示出一组无法确定的数据，并且每次运行后该输出值都是不一样的，但趋势是不断增加的现象。而图1-3所显示的输出确实是定时器定时的毫秒计时值。  
 通过这样的分析，显然下面的这两个程序应该是完全等价的！（请注意：此时用等待下一个整倍数毫秒内置函数也会得到同样的结果）

但是无论怎样说，它们都是基于软件定时的，在定时精度要求高的地方不要使用它们，应该使用实时系统中的硬件定时。相比较而言，等待下一个整倍数毫秒内置函数的定时精度要高于等待（ms）内置函数。我们用下图中的程序验证了这个结论。 
图1-7（请注意：按下停止按键后程序要再次循环一次才停下来） 
图1-8 程序修改后，按下停止按键后可以马上停下来 
     定时大于10ms时，按上图分别使用等待下一个整倍数毫秒内置函数和等待（ms）内置函数进行测试，结果前者大概比后者的定时精度高一个数量级。即便是定时小于10ms，定时精度也是前者要优于后者。

如果WAIT (MS)连接0会强迫当前线程放弃控制权.WAIT 0MS是一个相当重要的特点，实际是归还控制权给操作系统，来处理队列中的其他消息，如果没有消息需要处理，系统马上把控制权交给这个线程，继续运行．

这里有两种情况，如果系统消息队列中无需要处理的消息，立即返回，如果系统消息队列中有消息需要处理，并且是一个耗时操作，无法预料LV线程何时再次取得控制权．我们比较LV是否加Wait  0MS的速度．

实验过程中未执行其它任何操作，避免了处理其他消息造成的影响．两者之间，差距是惊人的．这也体现了Labview的一个优点，对于一个倾向于硬件控制的编程软件，它有着极强的任务抢先能力．

在一个循环里多次并行执行Wait，是累加时间，还是按最长的执行那，实际上是异步的还是同步的问题．我们做一下实验．

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

3、  Wait Until Next ms  Multipule（等待下一个毫秒的整数倍）

一直等到毫秒定时器变成指定时间的整数倍.可以用于在一个循环中调节循环的执行速率.但是第一次的循环周期可能比较短.可以直接连接0到这个节点,强迫当前线程放弃控制权,归还给CPU. 
相比WAIT MS,这个节点在循环中更为常用,对于几个采用相同参数的WAIT UNTIL NEXT MS MULTIPULE,可以实现不特别精确的同步.由于LABVIEW的循环的特点,首次是立即执行的,所以第一次是不能保证同步的.如果必须要保证同步的话,可以在循环中第一次执行空循环来避免这个问题. 
LABVIEEW EXPRESS中也提供了两个快速VI,一个相当于WAIT MS,另一个可以实现非常复杂的定时功能.

要比较好的解释这个vi，需要知道系统（至少Windows里有）中有一个millisecond timer这样一个计时器，这个vi跟这个计时器有着千丝万缕的关系。 简单来说，这个vi将一直等到ms timer得到输入值的整数倍才结束，通过下面的example，将会更好的理解（Wait Until Demo 1.vi）。程序中，首先输入50ms给Wait Until，计算第一次Wait Until花的时间，再输入50ms，同样地计算出第二次Wait Until花的时间。

每次运行的结果都不相同，但是可以看到，第一次Wait Until所花的时间总不是50ms，而第二次花的时间肯定是50ms，并且Timer Value两次一般都是50ms的倍数；出现这样的情况是这样来解释：首先，在程序运行的时候，系统的Timer值并不会正好是50的倍数，假设为10450935，那么程序在运行了15ms后Timer达到10450950（50的倍数）从而结束第一个Wait Until；在之后又迚入第二个Wait Until，在达到后一个50的倍数（10451000）后完成。

因此，如果将Wait Until并行地放在While循环中时，可能会出现两个问题，首先是它的第一次的周期就是不确定的。如下面的例子（Wait Until Parallel Demo 1.vi）：

可以看到，在用Wait Until时，第一次（即第二个值）都达不到20ms，但用Wait时，第一次就能保证在20ms，这是由于程序刚开始时Timer值不是整数倍导致。 用Wait Until Next ms Multiple.vi的第二个问题见下面的链接，讲得也很清楚了：http://zone.ni.com/devzone/cda/tut/p/id/4120 
最后再看一个例子，当Wait Until放在顺序模式中时，大致可以起到Wait的并行模式的作用，但是在代码时间超过设定值时，两者还是有着很大的区别。

4、Time Delay

我们先把TIME DELAY EXPRESS VI转换成常规VI,跟踪一下它是如何实现的.

进一步跟踪SUBTIMEDELAY

5、Elapsed Time

在LV7.1之后新增加了这个ELAPSED TIME快速节点，这是一个非常有用的定时器．先介绍一个OPENG中提供的比较简单的定时器．

LV的elapsed time 功能远比上面的VI功能强大，可以实现复杂的控制功能。

5.1、循环定时触发一个事件

5.2、输出一个 方波（5秒）

5.3、PWM波形

5.4、系统时钟