labview计时器.docVIP

Wait（ms）内置函数的探讨（1）——基本功能 12/22/2009 0 Comment(s) ? ?????? 图1-1 ?????? 1、ms）内置函数的功能 ??? 等待指定长度的毫秒数，并返回毫秒计时器的值。等待时间指定要等待时间，以毫秒为单位。函数的等待时间不超过0x7ffffff，即2147483647毫秒。如需等待更长的时间，可再次执行函数。??? 将0连接到毫秒计时值输入，可迫使当前线程放弃对CPU的控制。??? 该函数作出异步系统调用，但是函数节点却是同步操作的。所以，直到指定时间结束，函数才停止执行。????? 该内置函数在程序中通常被用来做定时器或延迟器使用。它的输入端为所期待的定时数值（以ms为单位），它的输出返回毫秒计时器的值。??? 由于等待（ms）是一个LabVIEW的内置函数，所以我们根本无法了解其程序内部的执行的方式或运行方法。但是我们可以通过不同的编程形式运行的结果来间接的认识和了解它。先看下面的例子，参见图1-2： 图1-2 1-2中，我们为等待（ms）内置函数设定一个1000ms的定时值，程序运行后它的输出“毫秒计时值”则显示出一组无法确定的数据，并且每次程序运行后该输出值都是不一样的，但趋势是不断增加的。这里显然是等待（ms）定时器的起始时间是一个不断改变的数值，这究竟是为什么呢？?????? 下面我们对图1-2所示的程序进行一下改动，看看改动后的运行结果。 图1-3（请注意：此时用等待下一个整倍数毫秒内置函数则不会得到同样的结果） ????? 1-3的运行结果显示，此时我们可以获得与输入设定值一样的“毫秒计时值”。很显然等待（ms）内置函数中包含了一个类似于“时间计数器”的内置函数，他们在某一时刻同步开始操作，这样我们就可以在等待（ms）的输出端获得稳定的“毫秒计时值”。????? 关于时间计数器内置函数的介绍，这里不想多谈了。Csxcs366在本站的“csxcs366手记”专栏的“LV深入探索（30）——谈谈LabVIEW中的几种定时器”有专门的描述。我们这里仅借用他的结论。???? “基准参考时间(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的返回值是一致的,也就是计算机启动以来经过的毫秒数”。（这里得感谢csxcs366用他的智慧为我们做出了这样的结论，这样的工作绝对是我力所不能及的——labview7i）????? 现在可以说是清楚了，等待（ms）内置函数和时间计数器内置函数的起始工作时刻是来自计算机启动以来所经过的毫秒数，所以我们才会看到图1-2程序运行后，它的输出“毫秒计时值”则显示出一组无法确定的数据，并且每次运行后该输出值都是不一样的，但趋势是不断增加的现象。而图1-3所显示的输出确实是定时器定时的毫秒计时值。?????? 通过这样的分析，显然下面的这两个程序应该是完全等价的！（请注意：此时用等待下一个整倍数毫秒内置函数也会得到同样的结果） 图1-4 ?????? csxcs366却在文中展示出了另外的实验结果。 图1-5（来自csxcs366） 图1-6（来自csxcs366） ???? 1-6要比图1-5花费更多地时间来处理程序运行。因为它的程序内部多了一些可执行的节点，每次叠代必将常数0送到等待（ms）的输入端，而等待（ms）内置函数则在判断输入为零后，会通知系统关闭等待（ms）的线程，所以将消耗更多地时间。???? 而为什么等待下一个整倍数毫秒内置函数的第一次总是不对的，这涉及到该内置函数的运行机理。对于等待下一个整倍数毫秒内置函数而言，LabVIEW通过一个毫秒计数器来监测等待的时间量，等待会一直持续，直到您所指定的整数倍毫秒时间量。由于毫秒计时器一直在工作，所以首次进入毫秒计数器会得不到所期待的计时时间，参见图1-3的说明，但是它可以实现图1-4的效果。?????? 但是无论怎样说，它们都是