《labview计时器》由会员分享，可在线阅读，更多相关《labview计时器（4页珍藏版）》请在金锄头文库上搜索。
1、Wait（ms ）内置函数的探讨（1）基本功能 12/22/20090 Comment(s)Wait（ms）内置函数，在 LabVIEW 开发环境下，选择程序框图中的函数选板，在编程定时中就可以找到该内置函数。参见图，右边是该内置函数的图标。图 1-1Wait（ms ）内置函数在中文版的 LabVIEW 中被译为：等待（ms）。1、等待（ms）内置函数的功能等待指定长度的毫秒数，并返回毫秒计时器的值。等待时间指定要等待时间，以毫秒为单位。函数的等待时间不超过 0x7ffffff，即 2147483647 毫秒。如需等待更长的时间，可再次执行函数。将 0 连接到毫秒计时值输入，可迫使当前线程放弃
2、对 CPU 的控制。该函数作出异步系统调用，但是函数节点却是同步操作的。所以，直到指定时间结束，函数才停止执行。该内置函数在程序中通常被用来做定时器或延迟器使用。它的输入端为所期待的定时数值（以 ms 为单位），它的输出返回毫秒计时器的值。由于等待（ms）是一个 LabVIEW 的内置函数，所以我们根本无法了解其程序内部的执行的方式或运行方法。但是我们可以通过不同的编程形式运行的结果来间接的认识和了解它。先看下面的例子，参见图 1-2： 图 1-2在图 1-2 中，我们为等待（ms）内置函数设定一个 1000ms 的定时值，程序运行后它的输出“毫秒计时值”则显示出一组无法确定的数据，并且每次程
3、序运行后该输出值都是不一样的，但趋势是不断增加的。这里显然是等待（ms）定时器的起始时间是一个不断改变的数值，这究竟是为什么呢？下面我们对图 1-2 所示的程序进行一下改动，看看改动后的运行结果。 图 1-3（请注意：此时用等待下一个整倍数毫秒内置函数则不会得到同样的结果）图 1-3 的运行结果显示，此时我们可以获得与输入设定值一样的“毫秒计时值”。很显然等待（ms）内置函数中包含了一个类似于“时间计数器”的内置函数，他们在某一时刻同步开始操作，这样我们就可以在等待（ms）的输出端获得稳定的“毫秒计时值”。关于时间计数器内置函数的介绍，这里不想多谈了。Csxcs366 在本站的“csxcs36
4、6 手记”专栏的“LV 深入探索（30）谈谈 LabVIEW 中的几种定时器”有专门的描述。我们这里仅借用他的结论。“基准参考时间(0 毫秒) 未定义的说法比较模糊，难道会是个随机数？这显然是不可能，如果是随机数，那两次调用 TICK COUNT 取得差值就不可能表示经过的毫秒数。无论如何，必须有个时间的起点。API 函数中也有一个类似的函数:GetTickCount,该函数返回计算机启动以来经过的毫秒数。在 9X 中，它读取的是 BIOS 中保存的系统时钟的滴答数，早期 PC 的 ROM 初始化 Intel8259 定时器芯片来产生硬件中断 08H。这个中断有时称为“定时器滴答”中断。中断
5、08H 每隔 54.925 毫秒产生一次，或大约每 18.2 次。BIOS 使用中断 08H 更新存于 BIOS 数据区的“时间”值。这就是常说的 55ms 的由来。对于 NT 操作系统，常规的说法是能精确到10ms，也就是说精度在 1ms 时是不精确的。 经过实际测试,LabVIEW 的 TICK COUNT 的返回值和 API 的返回值是一致的,也就是计算机启动以来经过的毫秒数”。（这里得感谢 csxcs366 用他的智慧为我们做出了这样的结论，这样的工作绝对是我力所不能及的labview7i）现在可以说是清楚了，等待（ms）内置函数和 时间计数器内置函数的起始工作时刻是来自计算机启动以来
6、所经过的毫秒数，所以我们才会看到图 1-2程序运行后，它的输出“毫秒计时值”则显示出一组无法确定的数据，并且每次运行后该输出值都是不一样的，但趋势是不断增加的现象。而图 1-3 所显示的输出确实是定时器定时的毫秒计时值。通过这样的分析，显然下面的这两个程序应该是完全等价的！（请注意：此时用等待下一个整倍数毫秒内置函数也会得到同样的结果） 图 1-4这种情况下，结论果真如此吗？是的，在通常的情况下这个结论是正确的。可是csxcs366 却在文中展示出了另外的实验结果。图 1-5（来自 csxcs366）图 1-6（来自 csxcs366）是这样的，当无数次叠代发生时，图 1-6 要比图 1-5
7、花费更多地时间来处理程序运行。因为它的程序内部多了一些可执行的节点，每次叠代必将常数 0送到等待（ms ）的输入端，而 等待（ms ）内置函数则在判断输入为零后，会通知系统关闭等待（ms ） 的线程，所以将消耗更多地时间。而为什么等待下一个整倍数毫秒内置函数的第一次总是不对的，这涉及到该内置函数的运行机理。对于等待下一个整倍数毫秒内置函数而言，LabVIEW通过一个毫秒计数器来监测等待的时间量，等待会一直持续，直到您所指定的整数倍毫秒时间量。由于毫秒计时器一直在工作，所以首次进入毫秒计数器会得不到所期待的计时时间，参见图 1-3 的说明，但是它可以实现图 1-4 的效果。但是无论怎样说，它们都
8、是基于软件定时的，在定时精度要求高的地方不要使用它们，应该使用实时系统中的硬件定时。相比较而言，等待下一个整倍数毫秒内置函数的定时精度要高于等待（ms）内置函数。我们用下图中的程序验证了这个结论。图 1-7（请注意：按下停止按键后程序要再次循环一次才停下来）图 1-8 程序修改后，按下停止按键后可以马上停下来定时大于 10ms 时，按上图分别使用等待下一个整倍数毫秒 内置函数和等待（ms）内置函数进行测试，结果前者大概比后者的定时精度高一个数量级。即便是定时小于 10ms，定时精度也是前者要优于后者。下面是来自 NI 网站上的一则问题解答。问题:在 LabVIEW 中，等待（ms）和等待下一个
9、整倍数毫秒 两个内置函数有什么区别？解答:等待（ms）函数等待的是您指定的时间量。而对 等待下一个整倍数毫秒函数而言，LabVIEW 通过一个毫秒计数器来监测等待的时间量，等待会一直持续，直到您所指定的整数倍毫秒时间量。可以考虑这样一种情况，以方便您来理解这两个函数的区别。假设您需要某个特殊任务每小时执行一次，您有两种方法供选择：1）.获取当前时间，并决定在 60 分钟后执行任务。2）.您可以决定在每小时的开始执行任务(12:00, 1:00, 等等)。例如，如果完成该任务需要 5 分钟，而您使用第一种方法，在 12:00 开始这个任务，并在 12:05 结束。那么您接下来需要等待 60 分钟
10、直到 1:05，才开始再次执行并于 1:10 完成。然后您又需要再等 60 分钟，以此类推。随着时间的推移，您每次开始任务的时间也将随之变化，从小时的开始，慢慢变化到结束，并再次循环。这就是在 LabVIEW 中关于等待（ms）函数的类推。另一方面，如果您使用第二种方法，它不会关心任务是花 5 分钟还是 15 分钟来完成，任务开始的时间总是在每个小时的开始。需要注意的是，取决于您开始的时间，第一次的等待时间也许会相当短，这是因为系统时钟在您开始等待前已经开始计时了。所以，如果您于 12:50 开始您的第一个任务，那么很快，您将在 1:00 开始您的下一个任务。这就是在 LabVIEW 中关于等待下一个整倍数毫秒函数的类推。 其实上面的解答中，对于“使用第一种方法”的说法未必很准确，通过下面对数据流的分析将会看清这一点（除非你使用的是顺序结构，参见下图 1-9）。图 1-9 第一种用法的图示
