简单介绍一个有趣的LabVIEW 8.6的新功能，断点管理器。

      编写程序debug的时候断点是少不了的，Visual Studio对断点的管理功能已经相当强大了，LabVIEW中确实也有断点和单步的功能，但是一直缺乏一个对所有断点进行统一管理的地方，于是在LabVIEW 8.6中就新加了一个Breakpiont Manager。

      可以通过View->Breakpoint Manager菜单选择也可以通过选择右键点击某个连线或者SubVI进行选择。

      界面也很容易理解，就是把所有当前打开的VI中的breakpoint全部显示出来，并且可以进行一些简单的操作。这些操作包括enable、disable以及remove，还可以在选择多个断点一并进行这些操作，也算是增加了一点灵活度吧。

      这次介绍的新功能叫做“Quick Drop”（中文姑且就叫做“快速放置”吧）。这也是一个ease of use的问题，有时候我们在编写后面板程序的时候，总是记不起来想要的node在什么地方，我们可能依稀记得这个node的名字，只是实在想不起来究竟放在何处。比如我有时候要用Call Library Funciton Node，但是我一度总是想不起来这个node具体在什么地方（现在知道在Connectivity->Library & Executables中）。以前一般的做法是打开后面板的menu palette浮动面板，然后search，现在有了更为方便的方法：Quick Drop。

      Quick Drop理论上有个系统快捷菜单，Control键+空格键，不过这个在中文相关的操作系统或者键盘布局下面可能有点问题，比如我的系统，这个快捷键的组合就用来切换输入语言，不过还有一个传统的办法，在菜单View下面就有这一项。

      选择Quick Drop之后，就会跳出一个新的对话框：这个对话框几乎罗列了所有的后面板menu palette上的项目。

      这时候如果你依稀记得想要的node的名字，就比较方便了。比如我想要用TDMS Open，但是我总是不记得在哪里，这时候我只要在这个对话框中键入TDMS，这个对话框下面的内容就会自动模糊查找并匹配，然后你可以双击想要的TDMS Open，然后TDMS Open这个node会自动出现在你的鼠标上，点击后面板任意位置，就可以把TDMS Open这个node放置到后面板上了。

      看起来这个功能还是有点意思的，有些时候非常管用，可以加快开发的速度，我个人也比较喜欢。什么时候可以搞一个这样的小竞赛，给参赛者一副LabVIEW程序的图，然后让参赛者依葫芦画瓢画出同样的图来，这个时候，恐怕Quick Drop就能派上大用场了。

      LabVIEW 7.0其实是一个比较具有里程碑意义的版本，在7.0中增加了Express VI这个重要功能。如果我是LabVIEW的用户，我肯定会比较喜欢这个功能，Express VI将很多用户需要做的编程工作放到Express VI配置页面上来完成，用户只需要点击鼠标，配置一些基本参数，就可以完成原先需要大量编程的工作。举个不太恰当的例子，我以前写ASP的程序，其中连接、读取数据库的程序每次都要自己写，代码又相对重复、并且复杂（比如比较头疼的分页功能），写起这种程序毫无乐趣可言但又不得不做。后来发现ASP.net果然有了改进，类似的工作会交给一个控件去完成，用户需要做的就是把这个控件拖放到页面上，然后再配置页面中填入一些相关的参数，无需再做太多的编程工作了。Express VI也是类似的功能，解放了用户。

      Express VI看上去就是一个蓝色的矩形，它的接线端一般是可以拖拉的，可以让它收起来（如同一般的Sub VI），也可以让它扩展出来置于Express VI的下方。Express VI一般也都会有一个配置对话框，用户可以通过这个对话框配置这个Express VI的基本参数。以上是Express VI的一般特性。

      一直以来，用户只能用LabVIEW自带的Express VI，那么用户是否能创建自己的Express VI呢？到了LabVIEW 8.6，终于可以了。这是LabVIEW 8.6的又一新功能——Create or Edit Express VI（创建或编辑Express VI）。值得一提的是，在NI内部，我们用的是更为底层的技术来创建比较专业的Express VI，我进公司后的第一个正式的项目就是造了6个Express VI。这里要介绍的Create or Edit Express VI属于比较轻量级的工具，用户使用这个工具可以创建比较简单通用的Express VI。现在我们就想用这个工具来创建一个比较简单的Express VI，完成两个数相加的功能。

      这个工具位于Tools->Advanced->Create or Edit Express VI这里，点击之后就弹出这个工具的主界面：

      我们点击右上角的new按钮，可以选择三种方式来创建Express VI：

      我们在这里就选择第一种方式，从一个已有的VI（add.vi）中创建。点击Next，我们可以选择这个已有的Sub VI，然后跳出以下的界面：

      这里列出了这个SubVI的图标以及接线端的属性，可以在这里稍作配置。接下来，就要选择这个新创建的Express VI应该保存在什么地方：

      点击Finish之后就完成了基本的创建工作。这时候我们发现，在Create or Edit Express VI这个工具的主界面中会显示刚才创建的Express VI的项目，这个项目包括两个子项目，分别是Source和Configure两个Sub VI：

      这两个VI是干什么的呢？我们首先打开Source，发现这其实就是我们在一开始选中的那个add.vi的一个wrapper，它完成了add.vi的基本功能，又加上了一些Express VI的基本功能，我们在这里无需对它进行其他的操作。

      Configure就需要我们做一点配置了，首先要配置它的前面板，就是最终Express VI的配置对话框的前面板，我们在这里希望在配置对话框中能配置add.vi的两个输入值，所以把两个输入值的控件拖到主显示框中：

      接着打开后面板，程序还是稍微有点复杂的：

      大致讲，这个VI定义了配置对话框的一些行为，分为三个主要的部分：Initialize、Main While Loop和Reconfigure。我们想要达到这样的目标：我们在点击对话框的OK按钮之后就能计算出最后的结果，于是我们把两个输入的控件拖放入Main While Loop的event structure中并且计算。

      好了，到这里基本上创建工作可以告一段落了，我们看看创建出来的Express VI具体表现如何：我们首先可以在后面板的菜单中找到我们新创建的Express VI：

      可以发现，其实新增了两个项目，一个成为subadd，另一个成为add，后者就是我们新创建的Express VI，前者则是我们前文提到的Source中见到的那个Sub VI，它具有类似于Express VI的外观（不是蓝色的），但是没有配置框。

      我们可以拖拽Express VI到后面板上，随即跳出配置对话框，我们在对话框中配置两个输入都为1：

      点击OK，结果就计算出来了：

      Express VI的接线端也是可以伸展收缩的：

      总体来讲，这个工具使用起来还是比较方便快捷的，用户使用这个工具就能创建自己的Express VI了，还是有一定的成就感的。

      最近LabVIEW 8.6终于发布了，8.6里面有不少新的功能，早就想着可以稍微写点东西，终于等到了发布的日子。一方面，我为其中的一个新功能也工作了接近一年的时间，写点东西作作宣传也不过分；另一方面，其实我对这些新功能也不可能全部都很了解，借此机会自己也学习一下。

      先介绍一个我比较喜爱的功能——Clean Up Diagram，如下图：

      这个功能只有在后面板上才有，也不知道正式的中文翻译称为什么，姑且就叫做“清理”，功能很简单也很酷：毕竟LabVIEW的编程有点类似于画图，画图就要讲究是否好看，这个按钮的功能就是清理LabVIEW的后面板，让后面板上的图形更为整洁美观。我拿自己写过的两个VI做个例子。

      其实我自己编程画图的习惯也还不错，编写程序的时候比较注意整洁美观。下面这张图就是未经过“清理”的后面板截图，可以看出，尽管看起来也还算不错，不过有些地方还有待改进，比如左下角红色圆圈中连线可以排布得更好，右侧也有较大的空白部分，图中SubVI的摆放也不是很整齐。

      在LabVIEW 8.6中打开该VI，点击Clean Up Diagram的按钮，结果后面板就自动“清理”成如下图所示：

      仔细看看，好像确实是美观了很多，包括连线、图中SubVI的排布、空白部分的布局等等。再举个简单的例子：

      这是“清理”之前的VI后面板：

      这是“清理”之后的，确实更为紧凑美观一些：

      对于很多用户来说，这个功能还是相当有用处的，以后编程的时候在美观性这方面可以对自己稍微放松一点要求了，因为可以把这部分的工作留给LabVIEW自己来处理。这个功能看起来很简单很直观，用户用起来也很方便，但是可以想象为了这个功能、为了用户的“方便”，LabVIEW的开发者需要付出多少的努力，我对图形学不是很了解，但是也可以想象“清理”的算法有多么的复杂。

      此外，文本化的编程语言也会讲究美观，比如C++的编程，该怎么摆放大括号的位置，什么地方放一个空格等等，这些都属于coding convention的范畴，而这部分的内容虽然看起来对于所编写的程序并没有本质的影响，但是可能会影响到其他方方面面的问题，比如可读性、可维护性等等。

      LabVIEW这样的图形化编程也是编程语言的一个发展方向，MS的Silverlight也能画图，不知道他们是否也有类似的功能。

      我本科和研究生拿的都是计算机方面的学位，但其实我就是个半路出家，对软件稍微懂点皮毛，对硬件基本没什么概念，对电子、信号处理等更是一窍不通。但是NI是个硬件软件都有所涉猎的公司，我进公司以来一直觉得不太容易把握住公司真正核心的产品线，真正的核心价值。最近学习了一点NI DAQ（数字采集）方面的知识，觉得好像稍微开始明白了一点。

      在我理解，其实IT行业存在的意义在于改善这个世界，改善人类的生产和生活。有些公司的业务可能是主要面向个人和企业，提供通用的软件和服务，比如Google、微软。而有些IT公司面向的用户、行业更为狭窄和更有针对性，比如NI就是如此，主要是面向工程类的行业。所谓工程类，比如电子工程、机械工程。NI面向的是和这方面相关的企业，比如汽车公司以及其他的制造业企业。

      NI有个比较重要的拳头产品或者概念、服务就是数字采集。制造型企业经常需要采集一些数据，针对这些数据进行分析，并且得出有用的结果。一个比较通俗易懂的例子就是汽车的引擎。生产汽车引擎时总会对它进行一些测试测量，比如用传感器采集温度，可以用麦克风采集声音、振动（声音本质上就是振动引起的）。这些数据对于汽车引擎来说很重要，采集下来之后可以进行分析，得出结果，比如哪个部位振动比较大，哪个部位温度比较高，这样企业就可以做一些有针对性的改良。

      那么数字采集整个系统大致应该是什么样的呢？NI官方网站上有一篇介绍性文章，可以参考。

      可以看到，整个系统大致分为以下几个模块：首先是传感器（transducer），传感器采集出来的就是信号了，接着是有个信号调整（Signal Conditioning）的模块，接下来就是NI数字采集的硬件，比如大名鼎鼎的数字采集卡，接着呢，就把信号连入计算机了，在计算机上用软件做处理、存储、管理。

      再对各个模块进一步解释：传感器的作用在于把物理现象转变成可测量的信号。比如把温度转换成电压，这个电压是很容易被采集和测量到的。Transducer的含义其实不仅限于中文的“传感器”，比如还可以用麦克风采集声音信号。采集出来的信号，无非也就是模拟和数字两种，这时候的信号可能比较不适合直接输入到数字采集卡和计算机中，为什么呢？比如温度转换成电压之后，这个电压的单位可能是微伏，太小了，最简单的一个方法就是把它放大，比如放大一百倍一千倍，这样就容易采集和测量了。这个功能就由“信号调整（Signal Conditioning）”模块来完成。我们最终的目的是把信号传入到计算机中，这就需要一个媒介和桥梁，这个桥梁就是DAQ设备，如数字采集卡，它一端连接着采集的物理信号，另一端连接着计算机，主要的功能就是将信号连入计算机，中间可能做一些简单的转换和处理。到了计算机中，就利用软件对信号进行处理、分析。

      为什么说NI公司还是厉害的？因为他提供了这一个系统的几乎所有部件。这整个系统、流程中的每一个模块和步骤，其实都有很多很复杂的内容（比如光采集就是一门很深的学问了），只要能在其中一个环节当中有所建树，就完全可以在行业中有一席之地，难能可贵的是NI在几乎每个步骤中都有产品，软硬件通吃。我猜测一下，说不定也就是NI自己提出了这个系统的概念吧。这样一来，NI其实提供了一整套的解决方案（Solution），当然这个solution他是不卖钱的，NI只卖产品，你要数字采集卡我有，你要数字分析的软件我也有，但是我不负责帮你搭整个系统，搭建系统的事情得你自己去完成，所以很多联盟商做的就是这件事。

      这个概念其实还是很多人都了解的，只是我以前不太明白。了解了这方面的概念之后，对我自己也有一定的帮助，就知道自己做的东西到底发挥了什么样的作用，到底在整个NI的战略中处于什么样的一个地位。对自己的工作、对NI的产品线有了更多更深的理解。理论结合实际，方能融会贯通。

      终于写到TDMS了，千呼万唤始出来啊，其实所有前面的相关文章都是为了TDMS作铺垫。正是由于用户提出的种种需求以及其他种种文件格式的缺点，才有了TDMS的出现。

      1. TDMS文件的逻辑格式

      TDMS文件的逻辑格式遵循TDM三层结构，仍然是文件、通道组、通道三层。用户在使用时只需要关心这三层就行了。

      2. TDMS文件API

      TDMS文件格式基本上可以称为NI用在测试测量领域的通用数据文件格式，LabVIEW, CVI/LabWindows, Signal Express, DIAdem中都可以使用，也常看到在Excel, MatLab被中调用。TDMS最核心的内容都在一个dll中，用户如果安装了LabVIEW，就会发现在Program Files\National Instruments\Shared\TDMS文件夹中有个tdms.dll的文件。其他软件正是通过调用这个dll的API来操作TDMS文件的。

      在LabVIEW中操作TDMS文件其实相当方便，有专门的TDMS面板，提供了TDMS绝大多数的功能。虽然我们一直说Write/Read Measurement Files, Storage VIs, TDMS分别面向初级、中级、高级的用户，但是我个人觉得LabVIEW中的TDMS用起来十分方便，即便是初级用户，也能很容易的上手。在面板上一共就10个SubVI，无论是什么样的数据类型，都可以用这样同一套SubVI，无需大量额外的编程工作。

      这里可以简单介绍一下TDMS面板上的两个SubVI，我个人觉得十分有用。一个是“TDMS File Viewer”，当用户写完某个TDMS文件之后，就可以用这个SubVI来方便的查看文件的内容，只要输入TDMS文件的路径即可，运行VI就会跳出一个Viewer的界面，可以查看数据、属性，并且可以根据数据简单的绘制出一些波形图。另外一个是“TDMS Defragment”，通常用户写完TDMS文件之后，可能会发现这个文件非常大，那么这时就可以使用这个SubVI，可以大幅度的减小文件的size。

      3. TDMS二进制文件

      TDMS从设计之初就确定它必须是二进制的。二进制文件带来两个优点：第一，与一般的文本式文件相比，二进制文件通常比较小；第二，二进制文件读写通常比较快。这两个都是其他二进制文件都具备的优点，就不再多说了。

      4. TDMS头文件

      用户写完TDMS文件之后，会发现硬盘上其实有两个TDMS文件，一个是.tdms，另一个是.tdms_index文件，我们通常把前者称为主文件或者数据文件，而把后者称为头文件或者索引文件。头文件与主文件相比，最大的区别就是把主文件中的raw data都去掉了，只留下属性等信息。这样做，有两个目的，第一，可以使得读文件加快速度，并且支持随机读取文件数据，这个稍后再解释，用户看完后面的内容就可以理解。第二，可以使得某些软件的搜索TDMS文件功能加快。比如在DIAdem中搜索TDMS文件，可以根据文件名、通道组名、通道名（其实这些也是属性），或者其他某些属性进行搜索，这个时候，仅将TDMS的头文件载入进行搜索，其速度远远比将TDMS主文件载入搜索快得多。

      5. TDMS的内部结构

      TDMS文件的内部结构，也就是物理结构，可以在这里找到原文。一般的用户并不需要了解这方面的知识就可以方便的使用TDMS文件。在这里介绍这个内部结构，是为了更好的解释TDMS文件格式的优点。

      TDMS内部结构的核心概念是segment，如下图。为了避免混淆，在这里必须澄清的是，这个segment的概念与TDM的三层结构（即逻辑结构）没有任何对应的关系，也就是说，一个通道可能对应着多个segment，一个segment中也可能有多个通道。segment是什么意思？我们在写TDMS文件的时候，数据本来可能存放在内存中，那么总要往硬盘上写这些数据的，每次往硬盘上写（flush to disk）就会产生这样一个segment。同样，我们在读TDMS文件的时候，也是一个segment一个segment的把内容读出来。

      再稍微深入介绍一下这个segment中的内容。一开始有一些头信息，比如这个segment中是否含有meta data，是否含有raw data，version是多少。下面的东西就很重要了，有个“next segment offset”的信息，指向下一个segment的起始位置，这个有什么用呢？比如我要读某个通道的数据，发现这个segment中并不包含这个通道的内容，就可以使用这样的信息直接跳到下个segment中看下个segment是否有要找的信息。同样，还有一个“raw data offset”的信息，比如用户只想读raw data，并不关心属性之类的信息，那么这个“raw data offset”的信息就派上用场了。说到这里，就可以明白，TDMS是怎样支持Random access，怎样支持独立的读属性信息和raw data的信息。

      此外，这个segment还有一个极为重要的特点。我们每次写数据，每次往TDMS文件中flush to disk的时候就在文件的后面添加这样一个segment，而不去关心之前的segment中包含了什么样的信息。这个特点非常关键，这就可以使得我们写文件的速度非常快，我们并不关心之前文件中包含了什么信息，也就使得我们写TDMS文件的速度并不和TDMS文件的大小成正比或者有任何关系。

      6. TDMS文件格式的优点

      我在以前的文章中提到几个数据文件格式的技术要求，我们现在再来回顾一下，看看TDMS文件是如何实现这些技术要求的，这样也就能看出TDMS文件的优点来。

      1）写文件速度必须要快——通过segment实现以及二进制。 

      2）向文件追加（append）数据的时候，速度要快——segment。

      3）写文件的速度不能与文件大小成正比——segment。 

      4）支持随机的读取——segment以及头文件。

      5）支持分别读写描述性信息和原始数据——segment以及头文件。

      6）对读文件的速度也有一定的要求——segment以及头文件。

      7）文件不能太大——二进制。

      7. 其他

      TDMS文件格式目前（LabVIEW 8.5）只支持Windows和PharLap（一种实时操作系统）平台上。不过我还看到一个基于VI的TDMS API，这个完全基于LabVIEW，既然LabVIEW能在其他平台上工作，那么这个小工具也能在其他平台上工作。当然，效率、性能的会差很多了。

      通常总有人拿TDMS文件格式和一般的基于Windows API文件流操作比较，然后会说TDMS比那样的Win32 streaming API慢嘛，是不是TDMS不行？比如在某些磁盘阵列的配置下，Win32 streaming API可以达到650MB/S，而TDMS只能600MB/S左右。我在这里需要澄清的是，TDMS在保持着数据良好逻辑结构（TDM的三层结构）、良好的数据管理的前提下，还能保持着这样高速的性能，这才是TDMS最大的优点。Win32 streaming API只是纯粹的追求速度（也仅比TDMS快5-10%左右），并不能将测试测量的数据良好的组织好、管理好，用户如果片面的追求速度而不管写入文件的数据如何保存如何管理，那就有点得不偿失了。

      当然，TDMS文件也并不完美，同样存在着种种缺点。比如不能支持方便的删除某个通道的功能，目前还不支持其他操作系统等等。相信将来都会有改善的。

      最后，用一个不是很恰当的例子来结束这篇文章。测试测量数据的文件格式，有很多种，文件格式就像我们中午带饭的饭盒一样。其他的数据文件格式就是把饭菜都放在一起，吃起来不方便（速度慢），而且味道都混杂在一起（组织不好）；而TDMS文件格式就像是内部有分隔的饭盒，不同的饭菜分开存放，吃起来又方便（速度快）味道又好（组织良好）。

      接着介绍LabVIEW中的另外两种文件格式。首先是Bytestream。

      这个文件格式说穿了就是二进制文件。就两个VI，分别是读和写。基本支持LabVIEW中的任何类型的数据。只要你在LabVIEW中能造出的数据，都可以用这种文件格式存储。可以猜测，其实这两个VI做的事情也比较简单，直接把LabVIEW在内存中的这部分数据写到文件中就行了，当然这样做的话，效率也比较高，因为没什么运算的步骤。但是也有部分缺点，比如直接把数据写到文件中也不见得好，真正的问题是如何管理这些数据。例如，读文件的时候也需要知道究竟这些文件存储了什么类型的数据，究竟存储在文件的什么位置等等。

      总的来说，如果用户追求纯粹的写文件的速度，并且不在乎将来读文件是否遇到困难（其实如果一个文件只写不读那就没什么意义了），那么用这样的文件格式还是可以的。

      接下来介绍TDM文件格式。

      TDM文件是指后缀名为.TDM的文件。文件的逻辑存储模型遵循NI的TDM Data Model，三层结构。TDM文件主要分为两个物理文件，一个是主文件，后缀名为TDM，存储原始数据以及属性等信息；另一个是头文件，后缀名为TDX，主要存储属性信息，方便查找，作为一个索引文件。主文件是类似于XML结构的，而头文件是一个二进制文件，理由也很简单：头文件主要用来索引搜索数据，所以对读的速度有较高要求，因此作为二进制文件更合适。

      对于TDM文件的操作，LabVIEW中主要通过Storage VIs来完成。TDM的文件格式，我个人感觉，最大的优点在于对于数据的管理。以前介绍的文件格式，没有对数据的管理做太多的考虑。TDM文件格式分为三次结构并且可以加入用户定制的属性，使用更为方便。举个通俗易懂的例子：很多人中午要带饭，放在饭盒里。普通的文件就是一个大杂烩，饭、菜混合放在一起，吃起来不方便并且看上去就杂乱；而TDM文件就像是有分隔的饭盒，饭菜可以分开放置，方便整洁。

      随着NI在测试测量文件方面的进步，TDM的文件格式已经逐步被TDMS文件格式取代，下次专门介绍TDMS。

      前段时间稍微忙一些，每天被bug缠身，终于改完了，暂告一段落，可以多写点文章了。

      LabVIEW中有个功能叫做Mass Compile，具体可以从Tools->Advanced->Mass Compile中选择。然后就可以选择某个文件夹，然后对这个文件夹中的文件进行Mass Compile，运行完之后会出一个结果。

      我们自己在开发过程中也经常用到这个功能，运行完这个之后，可以完成某些功能，比如重新link一下所选择文件夹下面的所有VI，可以改掉不少错误并且发现一些潜在的问题。虽然很多人在用，但是好像谁也说不清楚到底做了些什么事情。我在网上搜了一下，发现了一篇文章。

      概况起来，Mass Compile做了三件事情：1）relink所有的SubVI。我们经常遇到这样的情况，打开某个VI的时候，跳出一个搜索框，需要找一些SubVI，自动找了一段时间，发现找到了，这样就成功地打开了这个VI。Mass Compile可以自动做这些事情，记住SubVI的位置，这样，再打开这些父VI的时候就不需要再次花费时间搜索了。2）自动更新了VI的版本并且保存，把VI更新成当前LabVIEW的版本。3）发现一些问题并报告。比如这个VI的某些SubVI没找到，最后运行完之后的报告中会报错；还有诸如某些VI是broken的这样的信息等等。

      这篇文章中还介绍了一个比较有趣的功能，比如可以按住Control和Shift键，再点击运行VI的按钮，之后可以发现，这个VI被改动了（VI的名称后面多了一个*）。这个操作做了哪些事情呢？大家知道VI其实是个二进制的文件，可以理解为是一些程序（比如C++、汇编代码）生成出来的。打开一个VI，这个时候用户看到的是前面板、后面板的LabVIEW程序，在内存中其实是一段Generated Code，我们刚才所说的那个操作，就是把Generate Code这个过程重新做了一遍。

      今天先来谈谈Datalog文件，这种文件格式也有点年代了。基本上可以认为这种文件格式是二进制的。准确的讲，如果仔细研究，可以发现这种文件的内部结构比较奇怪。举个例子：如果往这个文件中存储3个int32的数字，用二进制的文本编辑器打开，可以看到内容类似于：

      这个还比较还理解，前面是一些头文件，后面是1、2、3三个数字。但是如果写入a、b、c三个字符，情况就比较复杂了：

      中间再省略若干行0。。。到文件的最后是：

      由此可见，该文件格式对于不同的数据类型、不同的存储方法有不同的内部结构。我个人看来，对于后一种结构，还是有不少的冗余信息的。这种文件使用起来也不是太复杂，有一整套的API可以调用，具体的使用方法可以参考帮助文档。

      总体来讲，这种文件格式，性能、使用的建议度、可读性均在中等水平，仅适用于LabVIEW软件。对于性能有一点要求，但要求不是很高的用户来说，可以采用该文件格式。

      再介绍一种文件格式，在LabVIEW中就叫做“二进制文件(binary file)”，其实很多文件格式都是二进制的，包括刚才介绍的Datalog，以及以后要介绍的TDMS。为了区别于其他二进制文件，我们有时候叫这种二进制文件为“bytestream”。具体操作这种文件格式的API非常简单。

      这种文件格式的性能非常高，使用起来也非常方便（就两个VI，一个负责写，一个负责读），但是数据的组织，也就是内部数据的结构（在这里无法透露具体的内部结构），可以说是比较差的。如果用户对于写入文件的性能要求比较高，但是并没有太多后续维护、管理数据的需求，可以考虑采用这种文件格式。

      针对于测试测量行业的数据存储，LabVIEW提供了数种不同的文件格式，先来介绍一下LVM格式。

      LVM(LabVIEW Measurement File)总体来说是一种比较轻量级的文件格式。它基于ASCII编码，用一般的文本编辑器打开都能看懂。当然，这个特点优劣参半，非二进制代码的文件，总体来说性能较低，并且不够紧凑（即存储相同信息量，文件稍大）。所以，LVM文件格式适用于对性能、文件大小并不具有太高要求的情形。

     上图显示的就是用普通的文本编辑器打开一个LVM文件的情形。可以看到第11行文字为"***End_of_Header***"，可见lvm文件具有header信息，header中的每一行都是一个键值对，表示该文件的一个属性，属性名与属性值之间目前以Tab分开。

      第13行开始就是文件的主体部分，LVM文件中也有类似于"segment"的概念。每次往相同的文件中写入信息都会往这个文件的末尾增加一个segment。segment也可以含有自己的header，header中自然也是存着针对于这个segment的属性信息。在segment的header之后就是真正的原始数据。比如一个波形图的数据。在上图中，我们存储了一个一维数组的数据。LVM文件最多可以支持二维数组的数据，如果打开存储二维数组的LVM文件，其原始数据部分看起来会与上图稍有不同，很像一个excel中存储的数据。

      在LabVIEW中操作LVM文件格式的API主要是Read/Write Measurement File，如下图所示：

      LVM文件还有一个缺点，就是header中的属性是固定的，仅通过LabVIEW的API并不能增加用户自定义的属性，这是一个限制。当然，不排除这样的情况：用户自己用文本编辑器打开LVM文件，向其中写入或者修改一些属性。

      世上没有完美的文件格式。LVM文件格式也有其自己的优缺点，有其独特的应用条件。并不能根据某个单一的指标判断它是好是坏，使用时应先判断自己的应用要求，作出合适的选择。

      今天谈谈如何选择合适的文件格式。

      在LabVIEW中可以使用的文件格式有好几种，争对于测试测量数据的文件格式也不少。每种文件格式都有自己的优缺点，很难说孰优孰劣。关键的问题在于要选择合适自己的文件格式。

      那么，在选择具体的文件格式时，有哪些指标可以参考？

      1）性能。测试测量数据的一个比较重要的use case就是要一边采集数据一边存储数据，NI现在采集数据的速度已经非常快了，性能的瓶颈往往是在存储数据到文件中去这个步骤上。当然，有些use case对于读取数据的性能也有要求，比如要做实时的数据分析等。因此，在选择合适的文件格式时，需要考虑性能的问题。

      2）兼容性。采集数据、存储数据、分析数据，用的可能不是同一套软件，很有可能在不同的平台、不同的软件中完成这些不同的功能。那么就需要采用一种比较通用的文件格式。打个比方，XML就是一种比较通用的文件格式。

      3）支持的数据类型。并不是每种文件格式都支持所有的数据类型。有些可能不支持存储二维数组、不支持存储时间、日期等等，在选择文件格式时需要注意到这一点，以免将来带来不必要的麻烦。

      4）是否方便使用。有些人可能喜欢定义一套自己的文件格式，对于高手来讲也未尝不可，但是对于一般的用户就需要考虑是否有这个必要。有些文件格式，在LabVIEW中已经有现成的、丰富的API，那就直接拿来用吧。

      5）可维护性、可移植性。写完的文件很有可能将来还会修改，还可能会拿去给别人去修改。别人是否看得懂这样的文件？别人是否方便修改这样的文件？

      6）文件大小。存储相同的信息量，当然文件越小越好，信息存储紧凑一点好。

      当然还有其他很多方面的指标可以参考。暂时先说这些，以后还会有更深入的内容介绍。

      在分析TDM模型的优劣势之前，我想最好先罗列一下一些数据文件格式的技术要求。

      NI软件平台上针对于测试测量的数据，有很多不同的文件格式，其中有几种是支持TDM模型的。并不是说这些文件都能满足以下技术要求，我只是先罗列出来：

      1）写文件速度必须要快。很多情况下需要一边采集数据一边就把数据写到文件中，采集卡的速度已经相当快了，这时候瓶颈常常是在写文件这个步骤上。相反，读文件可能并没有如此高的要求。

      2）向文件追加（append）数据的时候，速度要快，这个时候不能读取文件中的信息。这其实也是常用的一个use case，采集数据写入文件的动作可能经常要进行（比如在一个循环中），往往又是往同样的文件中写入信息。

      3）写文件的速度不能与文件大小成正比。我们希望不管文件有多大，写文件的速度总是保持相对恒定，不能文件越大就写得越慢。

      4）支持随机的读取。比如我想读文件中某个位置的某些内容，不能要求把这个位置之前的所有数据都先读出来（即读到内存中）。

      5）支持分别读写描述性信息和原始数据。这是上一条的延伸，读描述性信息（meta data）的时候不要求把原始数据（raw data）读进来，同样，读原始数据的时候也不要求把描述性信息读进来，否则，势必影响读文件的速度。

      6）对读文件的速度也有一定的要求。这个要求主要来自于搜索数据。无数浩瀚的数据，怎样才能快速的找到用户需要的数据，这一直是一个难题。

      7）文件不能太大。存储同样的数据量，文件自然越小越好。

      技术要求暂时就写这么多，其实总结起来，无非两点：1）快；2）方便。我们对照TDM的数据模型，对于“快速”，暂时看得不明显（以后可以谈谈为什么TDMS文件可以达到“快速的要求”），但是说它“方便”，还是可以理解的。

      这个模型的设计完全是依照用户的应用实例。首先，它是分层次的。比如说我们需要测试汽车发动机的各个指标。我们用8个通道的采集卡采集发动机振动的数据，8个通道分别采集8个部位的振动，存到文件中，作为一个组（group），组的名字就叫做“发动机振动”。我们还需要采集发动机的进气管、排气管压力，又作为一个组。还要采集发动机的温度，可能也用8个通道的采集卡采集8个部位的温度，每个部位的温度数据作为一个通道（channel）存到文件中，8个通道作为一个组，叫做“发动机温度”等等。我们可能会采集多次，其他参数都不变，只是数据每次都附加在文件的后面。我们有很多的测试工程师，每个工程师做的测试分别存成一个TDM模型的数据文件。可以发现，这样的三层结构还是很清晰的。这就好比用LabVIEW些程序，VI大了，就不知道怎么管理了，那就多用几层SubVI嘛。

     其次，它具有描述性信息。比如可能需要把测试的日期、测试者的名字、测试的环境配置等信息写下来。有些描述性信息是针对“文件”这个层次的，比如测试者的姓名。有些信息可能针对“组”这个层次，比如采集的是“温度”，单位是“摄氏度”。有些信息则可能针对“通道”，比如采集的是发动机哪个部位的温度等等。描述性信息比较利于他人阅读文件，并且，在搜索文件数据的时候，可以派上大用场，可以先利用这些描述性信息进行定位。当然，这些信息最好能和“原始数据”（raw data）放在一起，要是放在两个文件中，一是难以对应起来，而是不利于维护。这也好比是写LabVIEW程序，你写的程序，别人也要能看到，没太多的好办法，就多写点注释吧。

      这样的TDM模型也有其缺点。至少看起来有点复杂，同时有原始数据和描述性数据，还要实现那么多的技术要求，着实有点困难啊。其次，这个模型写下来就固定了，一共就3个层次，说到底在某个文件中也就2个层次，不能扩展，不像XML那样方便。我有时候就想要把数据写到一个“通道”中，我还非得先造一个“组”出来（其实可以不写，默认会造一个出来，但是逻辑结构上不能缺少）。还有其他限制条件，比如原始数据必须写在“通道”这个层次，不能写在“组”这个层次等等。

      总体来讲，TDM数据模型利大于弊，比较适合测试测量领域的数据的存储，是一套不错的解决方案。

      这里说的测试测量数据是指配合NI的硬件，如PXI卡采集所得的测试测量数据。对其他的测试测量应用场景我还不熟悉。

      NI原先是缺乏一个比较优秀的测试测量数据存储方案的，NI后来也意识到了这个问题，于是在德国收购了一家公司，这家公司专做数据存储（也包括显示、报表等），于是NI在数据的采集、存储、显示这方面的产品线已经比较齐全了。

      NI现在主推的一个数据存储逻辑模型叫做TDM(Technical Data Management)，具体的方案可见：

     NI TDM Data Model

      这个模型的特点可以简单概括为：清晰的层次结构以及支持各层次的描述性信息。具体来讲，一个TDM模型的数据文件可以分为三层，分别为文件（File）、组（Group）和通道（Channel），在每个层次上，都有NI定义好的一些属性，同时，用户也可以自定义属性。

      这样的一种数据模型很容易被理解和接受。比较符合实际的应用需求。比如用NI的采集卡采集电压数据。一块卡上一共8个通道。每个通道每次采集的数据都可以保存为一个“通道（channel）”，8个通道一次采集的数据可以组成一个组（group），每天采集一次，n天就形成n个组，每个组都有8个通道，所有的数据都写在同一个文件（file）里。其他卡采集的数据放在不同的文件中。

      除了直接采集到的数据（可称之为Raw Data）之外，总要写点其他信息的，比如采集卡到底是什么型号，每次采集都是谁来完成，采集的是电压还是电流，单位是伏特还是千伏等等。这些信息就称为描述性信息（Meat Data）。这些信息写在别的文件里面总不太容易管理，最好写在一个文件中。因此TDM模型也支持将这些描述性信息写在同一个文件中。

      注意一下，我在这里说的是TDM的“逻辑”模型，并不是指他的物理存储结构。在NI，有数种文件格式都支持TDM的模型，但是他们的物理存储方式大相径庭，这个以后再写。

      这种TDM模型的测试测量数据文件，是NI软件平台中通用的文件，除了LabVIEW外，很多其他的NI软件产品都支持这种模型，比如DIAdem、CVI、Singal Express等等。

      在LabVIEW中，分别有三套API支持TDM模型的数据文件，他们分别是：

      Measurement File/Storage VIs/TDMS

      （图片采自LabVIEW 8.5.1 Professional）

      这三套API分别对应着三种应用的难易级别，由易而难。具体以后再介绍。

      下次写一下我对TDM数据模型的看法（优缺点），以及简单介绍相关的文件格式。

      我第一次接触LabVIEW应该追溯到大一大二的时候。依稀记得当时有一次金工实习，不知道为啥没下车间，老师给我们介绍了一种图形化的编程语言。当时感觉这个东西真是厉害，老师说是最强大的图形化编程语言云云，其实早已不记得当时说的是不是LabVIEW了，现在回忆起来肯定是它没错。大学本科的同学看到可以帮我考证一下：）

      LabVIEW其实在业界还是比较出名的。老婆和她单位的领导说我在NI工作，他们领导马上就说NI有个LabVIEW嘛，老婆自豪的说，“我老公就是做LabVIEW的！”虽说如此，我工作后刚开始正式接触LabVIEW的时候，心里还是有不少问号的。

      作为一个程序员，我不敢说精通什么编程语言，但是谈得上了解或者接触过、用过的语言，少说也有十种八种吧，所以看待新语言的时候，自然带着批判性的眼光。我一直在想，LabVIEW为什么能够得到业界的认可？什么是虚拟仪器？LabVIEW在NI提出的虚拟仪器中究竟扮演着什么样的角色？LabVIEW有什么优缺点？LabVIEW还有什么改进之处？等等。

      要了解LabVIEW，最好先能了解一下什么是“虚拟仪器”。虽然在公司工作了两年的时间了，但是要问我，什么是虚拟仪器，我还真回答不好。一方面自己也没仔细去想，另外一方面我算是CS出身，对仪器、DSP知之甚少，对整套的解决方案更加是没有任何接触。上一篇文章中推荐的Blog中就有一篇文章解释了什么是虚拟仪器，应该是我看到的中文文章中解释的最好的，可以参考一下：（此处转载链接并未得到博主的许可，如有冒犯，敬请见谅！）

      什么是“虚拟仪器”？

      什么是“虚拟仪器技术”？

      好了，谈谈我的理解。先从编程语言角度谈一下。虽然Jeff K（LabVIEW的发明者）也说不能把LabVIEW当成一种通用编程语言，但是不可否认LabVIEW在编程语言领域也还是占有一席之地的。我大概在半年前看到TIOBE上看到过LabVIEW的排名，今年2月份又看了一下，虽然排名还是30多位，没有太多的变化，但是对比MATLAB，半年前LabVIEW的数据还是MATLAB的一半，现在已经迎头赶上。当然，一个指标的排名也说明不了太多，况且也有可能是MATLAB自身在退步，但是至少可以看出LabVIEW还算是不错的。

      作为图形化的编程语言，LabVIEW应该可以算得上首屈一指。图形化的编程语言，也并不是什么新奇的想法（现在都快用语音来编程了），但是NI做了，并且做得还行，就不能不说是一种成功。其实市面上还有一些其他的编程语言，比如微软的Robotics Studio，还有Yahoo!的Pipes，我没有仔细研究，不过初看下来，感觉作为编程语言，LabVIEW相对还是功能强大的。不能老是拿LabVIEW和c/c++比较功能、性能等等，这个自然比不过，但是LabVIEW也有其自身的特点和不可取代之处。

      既然是图形化的编程语言，理论上讲，比文本化的稍微好学点，比如中国人学C/C++编程，最好还是要懂点英语的。图形化的则不然，比较容易上手。前段时间，同事给了我好多张PSP游戏的DVD盘，我就想生成一个游戏的list，这样以后我要查询起来就方便很多。那就写个程序吧，在VBScript和LabVIEW中我最终选择了后者，用了几分钟的时间就写好了程序，非常方便。这就是LabVIEW的一个好处。

      个人感觉，LabVIEW最大的优势还是在于“虚拟仪器”这个概念中的角色。Acquire -> Analyze -> Present，在这个流程中，LabVIEW至少可以用在后面两个步骤广泛的使用，第一个步骤也有。其他的编程语言则不具备这个功能，或者说不够全面、不够容易，比如Matlab，也能Analyze和Present，估计在配合硬件做Acquire的时候就有点力不从心了，（而且不是图形化的）。LabVIEW与其他NI的硬件也号称“无缝连接”，用户使用NI的软硬件搭一套solution是不困难的。NI从来不说自己是做solution的，我的理解是：NI做的是solution的solution（其实就是产品，搞得这么高深。。），solution嘛，就留给联盟商和其他人去做吧。

      其他特性就不多说了，跨平台等等。这个并不难，其他很多语言也一样。LabVIEW缺点也很多（这个用多了就更有体会），比如性能、编写大规模软件等等。这个世界上没什么通吃的编程语言，根据自己的需求进行选择就行了。

     我曾经亲自问过Jeff K，当时为什么要创立这个公司，他说很简单，make the world a better place.我前段时间还看到过一些文章，LabVIEW被使用在救护车的便携式设备上，取得了不错的效果。救死扶伤，这也算是LabVIEW对这个世界的一点贡献吧。

      LabVIEW已经有20多年的历史了，在图形化编程领域也小有建树，在国外，尤其是美国，应用的还是比较多的，但在国内算是刚刚开始吧，并不是太流行。正好在NI中国成立10年之际，我也打算开始写点关于LabVIEW的东西。

      当然我准备写这些文章的初衷，并不在于中国公司成立10年，而是受到网上一位博主的启发。今天这篇文章不干别的，就先推荐两个关于LabVIEW的博客。

      LabVIEW (Q^Q 是我的眼镜)

      公司的同事总要先推荐一下的。此人被我称为“中国LabVIEW第一人”，不知道这个帽子是不是扣的太大了。此人姓阮，我们组做LabVIEW的同事皆师出此人名下，因此我戏称我们这些“徒弟”为“阮饭”。。。言归正传，这个博客中有很多关于LabVIEW的文章，而且比较有深度。阮同学加入NI也已经有9年的时间了，平时他也比较勤奋好学，LabVIEW基本功比较扎实。公司同事但凡有LabVIEW方面的问题，大多会来问他，在公司绝对算得上LabVIEW的泰斗级人物了。

      一切随缘

      这个就是我前文提到的博主，我认识他（他不认识我）是在NI Days 2007的时候，据称他当场把我们R&D一个正在做Demo的同事给问倒了。他不是我们公司的，但是LabVIEW掌握的比较透彻，公司的一些AE也认识他，因为他经常打电话来，问的问题AE也并不是每次都能回答得上。

      这个博主年过半百，有着丰富的相关项目经验和扎实的技术功底（不像我，只对编程稍有了解，对数字信号处理之类的一窍不通）。更难能可贵的是，他一直保持着浓厚的学习兴趣，对LabVIEW也情有独钟。对一些人生的问题，看得也比我们更为透彻。读他的博客，获益良多。

      由于我是NI的员工，因此在将来关于LabVIEW的文章中，我也会避免涉及到任何公司机密。下次简单写写我对LabVIEW的认识过程以及对LabVIEW的一些看法。

1. 什么是VI Scripting

      VI Scripting是LabVIEW中一项非常重要和强大的功能，简而言之，就是使用LabVIEW编程语言创建LabVIEW中的程序元素。这些程序元素当然包含一般的node, wire, structure等等。有个不太恰当的比方，比如众所周知，Eclipse是一套开发java程序语言的工具，但是Eclipse本身也是用java自己编写的，也就是说我们在使用java开发java。VI Scripting也类似，我们可以用LabVIEW开发LabVIEW。

      一种比较准确的定义是：VI Scripting是LabVIEW提供的一种基于VI Server技术，让用户创建、修改以及了解VI信息的强大功能。使用VI Scripting可以得到VI的属性和行为，此外，我们还可以用VI Scripting改变VI的属性和行为。VI Scripting包含了一个接受指令的引擎，这些指令可以通过VI Server得到翻译，用来传给LabVIEW本身。VI中的所有东西都可以被认为是一种VI对象（object），包括FP/BD上的任何对象、Connect Panel、Icon以及几乎所有保存在VI中信息。所有对VI对象的修改都可以在编辑时期利用Property Node和Invoke Node完成。比如，VI接线柱的位置、颜色、接线情况都可以在编辑时期得到或修改。

2. 如何使用VI Scripting

      VI Scripting在LabVIEW6.0以后的版本中均可以使用。但使用之前需要得到VI Scripting的license，关于如何得到license，可以与NI公司联系。

      使用VI Scripting需要安装VI Scripting的menu，当中有三个node，这三个node会经常被使用到，如下图所示：

      此外，Application Control面板中的Property Node和Invoke Node也被广泛地使用到，常常与以上VI Scripting面板中的三个node配合使用，如下图所示：

      配合使用以上几个node，几乎可以完成VI Scripting的所有功能。

      下面首先介绍一下VI Scripting面板中的三个node。

      首先是New VI。

      这个node的主要功能就是新建一个VI，新建一个VI又有什么作用？一方面，正如字面意思，它能够创建一个新的VI，而这个新的VI便是接下来后续工作的母体，或者称为容器；另一方面，通过创建一个新的VI，可以极大的方便调试其余主要VI Scripting程序，你可以清楚地看到你是如何创建node，如何连线，甚至可以逐步地看到这些步骤。笔者就经常将某些VI Scripting的程序，单独拿出来，然后再用这个node创建一个新的VI，后面连上要调试的VI Scripting程序，事实证明，这样的调试，效率还是颇高的。

      关于这个node，还有一点补充，笔者在使用这个node时，经常还在后面关联上一个Property Node，用来打开创建的VI的前后面板，如下图所示：

      接下来是New VI Object。

      顾名思义，就是创建一个新的VI Object，这个object可以说多种多样的，node、structure、SubVI，甚至连XNode都可以创建。

      这个node，需要提供一个owner refnum，通常是一个diagram的refnum，比如可以是上面介绍的New VI输出的refnum。还有些情况下，比如使用XNode或者External Node时，程序会自动提供一个diagram的refnum。

      接下来比较重要的是这个node上方的一个接线柱，vi object class。通常我们可以create constant来提供这个参数，这个constant是一个class specifier constant。可以通过单击它选择要创建的VI Object的类型，比如我想创建一个SubVI，可以按照下图所示操作：

      当然，接下来还需要指定这个New VI Object的其他参数，比如variety、path、position等等。这个node的输出就是创建好的这个object的refnum，可以连上Property Node或者Invoke Node得到或修改这个object的属性和行为。

      最后是Open VI Object Reference。

      这个node的功能在于取得一个已有的VI Object的refnum。比如说我们已经创建了一个Wait (ms) 函数，这个函数有一个terminal输出，现在我们向得到这个terminal的refnum以便于后续操作，这时候就可以用这个Open VI Object Reference node了，如下图所示：

      下面将举一个简单的例子说明如何使用VI Scripting。

      利用VI Scripting编写程序还是有一点工作量的。因为需要对程序中的每个object作处理，所以，即便是一个比较简单的LabVIEW程序，如果用VI Scripting写出来也需要耗费相当的工作量。比如，我们想利用VI Scripting编写如下的程序：

      程序运行结果大致应如下图所示：

      这在LabVIEW中应当说是一个比较简单的程序，但是用VI Scripting来写这个程序，还是有一定的工作量的，下面我们将逐步演示如何编写。

      我们先仔细观察该程序的Back Diagram。

      我们首先需要一个Waveform Chart，还需要一个Stop Button，以及一个While Structure，并且需要把While Structure设置成为Stop if true我们的程序中必须首先构造这些部分，如下所示：

      接下来我们还需要把Waveform Chart和Stop Button放置到While Structure的里面去。

      接下来，显然，我们还需要构造一个Random Number和一个Wait Until Next ms Multiple Node。当然，这两个node可以同时构造，如下图所示：

      这还不够，还需要把Random Number和Waveform Chart的输入接线柱连接起来，我们也可以用VI Scripting配合Property Node和Invoke Node来实现：

      同时，需要给Wait Until Next ms Multiple node的左边接线柱和一个值为100的整数连起来，这个整数可以通过create constant来构造，这里，我们利用Open VI Object Reference Node来得到Wait Until Next ms Multiple的接线柱，如下图所示：

      好，接下来是最后的步骤了，将While Structure的Stop if true与Stop Button连接起来，并且处理error code。

      到此为止，我们的程序才告一段落（以上程序在Windows XP SP2 + LabVIEW 8.2下运行通过）。

      可能读者会有疑问，既然用VI Scripting来编写程序这么麻烦，比直接使用LabVIEW写程序麻烦多了，为何还需要VI Scripting呢？答案是，VI Scripting的强项以及优势就在于可以在LabVIEW的运行时期，生成这些代码，这个功能十分强大，具体可以参考下一节中给出的解释。

3. VI Scripting的地位以及与LabVIEW中其他组件的关系

      VI Scripting在LabVIEW中的地位至关重要，LabVIEW的几乎每个功能，都会有对应的VI Scripting属性和方法。如果某个LabVIEW的新功能对VI Scripting有影响，那么，该新功能的开发者就将被要求开发对应的VI Scripting属性和方法。因此，可以说，VI Scripting是LabVIEW中的一项核心功能，具备强大的功能，处于较高的地位。

      在LabVIEW中的其他组件中，VI Scripting得到了广泛的应用。可以这么说，如果没有VI Scripting，那么这些组件将不能充分发挥其功能。笔者有一些编写External Node以及XNode的经验（这两项功能仅限于NI公司内部使用，没有对外开放）。可以提一句，External Node和XNode都提供了一种编写用户自己的Node的功能。因为是用户自定义的node，那么就需要定义其编辑时期和运行时期的行为，而运行时期该node所生成的LabVIEW程序将完全使用VI Scripting来编写。如果没有VI Scripting，External Node和XNode也就只剩下了一副空骨架。

4. 如何调试VI Scripting的程序

      如果是类似于上文中示例的纯粹的VI Scripting程序，那么调试也不外乎以下几种，Highlight Execution，设置断点，单步跟踪等等。

      但是，VI Scripting常常与其他LabVIEW组件配合使用，如在External Node和XNode中得到使用。在这种情况下，往往，diagram的refnum是由VI Scripting的母体程序（即External Node和XNode）自动提供的，而VI Scripting用来完成在运行时期生成LabVIEW程序。这个时候，调试就变得比较复杂。笔者曾经也常常因此困惑，而最常采用的调试方法就是将母体程序中的VI Scripting代码拷贝到一个比较干净的VI中，运行该VI，便能方便地得到错误信息。

5. VI Scripting的发展展望

      VI Scripting在LabVIEW中处于一个核心的重要地位，因此，可以肯定地说，VI Scripting在未来的岁月中将会得到一个长足的发展。另一方面，NI公司已经将VI Scripting技术对用户开放，VI Scripting技术也将逐步走向成熟。

      开始VI Scripting的神奇之旅吧！