LabVIEW的使用感受
由于课题的需要，接触并学习了虚拟仪器技术。
虚拟仪器技术源于美国，是美国NI公司在1986年提出的概念，它体现老美的一贯的行事作风。美国人在各行各业都把效率放在第一位（不像我们国家，自己的一点看法哈哈），而且非常强调和注重每个人工作的通用性即所谓的互换性（或者是移植性）， 尽量减少机械的重复"体力"劳动，科学技术的研究、开发、创新都似乎都有继承性，后人只要在前人的基础上进行自己的创新工作即可， 站在巨人的肩膀上才可以看的更远，想的更深。而且也把自己和巨人分的很清楚，不像我们，什么都要自己从头做，即使站在了巨人肩膀上，也不说是因为站在巨人肩膀上所以看的更高，非要人感觉是自己高。这些可能都是我们现在这个社会非常缺少的东西，尤其是我们研究生缺乏的一种能力，这也就造成了我们国家软件方面落后，还有就是现在的学术腐败现象。这方面我非常地佩服老美，当然要在短期内形成这种体系也不是很容易，不过我们国家似乎也在朝这个方向发展。
要提NI，就不得不提虚拟仪器，要提虚拟仪器就不得不提LabVIEW，LabVIEW是一个专业性相对较强的开发平台，它似乎是图形化编程语言的代名词，这也是为什么人们形象的称他为G语言，在这里我说个我经历的笑话，前些日子，我一个同学偶尔问我现在用什么语言，我说用G语言，你猜接下来它说什么？他说：“知道B语言（VB),C语言，C++，但就是不知道G语言，是不是还有D语言和F语言”，我当时直接没有晕倒。其实从他的名称上就能看出来LabVIEW的特点、优势以及与其他语言的区别。但我认为其优势和核心在于它的接口,某一专业的人员通过接口即可以方便地利用不同专业的技术成果， 正如NI的CEO
James
Truchard博士所说："实际上，LabVIEW本身既不是一种编程语言也不是一个测量工具。LabVIEW是一个连结高级开发理念和不同硬件平台的图形系统开发平台。"这样结果就是大大提高了各种技术利用效率和加快了技术的推广步，同时也减轻了人们利用技术的困难程度。LabVIEW的本质其实就是一种高级工具，使你能够按照你的最自然的方式对问题进行考虑。
什么是LabVIEW?如果让我用一句话概括我认为：LabVIEW是一种数据流驱动的图形化 自动多线程的编译型语言。之所以说是数据流驱动，是因为LabVIEW程序在执行时是按照数据在连线上的流动方向执行的；所谓的图形化主要体现在以下两方面：第一，程序有图形化的界面（前面板）；第二，代码也是通过画图的方式编写的（程序框图）；而自动多线程由是为什么？不知道你写VI是有没有注意过，如果程序中有两个并行放置、之间没有任何联系的模块，则LabVIEW会把它们放置到不同的线程中，并行执行。你可能会说，没有，这就对了，真因为你这样无意识的编写出并行运行的多线程程序来才能体现出所谓“自动多线程"中“自动”二字，至于最后能不能说LabVIEW语言和其他常用的VC++、VB等文本编程语言一样，是一种编译型语言，其他的可能你都认可了，唯独这个，你可能要和我争论了？你肯会强烈的反对。我认为你反对，可能以下三个原因：一，没有编译按钮；二，用户几乎感觉不到编译时间；三，用户看不到编译生成的目标文件。对你的反对，我表示理解，对你的疑问没有错误，你的概念也没有错，源代码必须编译后才能执行，说明你还有点编程基础哈！在这里我明确的告诉你LabVIEW是一种编译型语言，之所以看不到编译按钮是因为，LabVIEW中不需要用户来编译，LabVIEW帮助你完成这个工作，那为什么用户有感觉不到编译的时间呢？愿意是LabVIEW是在你编辑源代码的同时，就会对它进行编译，写完代码，编译完成，所以你感觉不到编译的时间；其实也不是你感觉不到编译时间，只是你没有意识到这一点，我相信你都有这样的经历，当用高版本的LabVIEW去打开低版本编写的程序时，打开过程需要时间很长，你有没有想过，为什么?这段时间LabVIEW在干什么？这段时间LabVIEW就是在编译，这段时间就是编译时间，好了，前两个疑问已经消除了，相信你现在肯定迫不及待的想知道为什么用户看不到编译生成的目标代码？这是因为LabVIEW和文本编程语言比如C，是不同的，它把源代码和编译后的二进制代码保存在同一个文件下即.VI这个文件下。现在明白了吧!呵呵！不知道，你是否同意我上面对LabVIEW语言的理解哈！如果有什么想法可以回复我。
一般情况，人们认为用LabVIEW来做界面可以事半功倍 ，这也是很多人使用它的原因之一，但也不是所有的界面用它都是最好的、最高效的。个人认为，如果要做windows环境中运行的一般界面窗口， 比如说系统设置对话框或者是别的不需要有仪器控件出现的窗口 就不要用LV了，这种情况，用VC要好得多，因为可以利用消息驱动的优势 避免在LV中使用一些特殊的技巧，比如说轮询什么的。，如果非用不可，那麽你就会会很矛盾的，也要付出很大代价。呵呵 看来数据驱动也有它的不好，呵呵
我们不得不承认，用LabVIEW来开发系统，特别是大型的复杂系统，确实在时间上有他的优势。记得以前我做程序的时候，曾经看过一个例子，据说这是用lv做过的最大的一个 软件系统了，大家可以去查一查 Spectrum Astro's Real-Time Data Acquisition and Control System 。 我在做课题调研的时候，比较过用VB、VC++和LabView开发所需要的时间， 用VB和开发，需要学习很多不相关专业的知识，要耗费很多时间， 用VC++所耗费的时间就更多了，而且用两个月做出来的所谓仪器很差劲，显得很外行，老板还认为你没用下功夫，真是比窦娥还冤呀。
但是同时我们也不得不承认，LabVIEW的运行效确实不敢恭维，当然是和其他语言比起来，这个也是可以理解的，似乎也是符合辩证法的哈哈。比如，我们前一段时间做的一个大型的系统，它在访问数据库是速度奇慢无比，当时我们的用户还以为系统死机了，我们智能告诉人家可能是因为数据太多，查询比较慢，其实不是地。不过NI好像也意识到这个问题，也采取了一些相应的措施，比如，和其他语言的混合编程方面如MatLAB、内存优化方面等等，我相信NI会做的越来越好，让我们期待吧！我对LabVIEW还是很有信心的！
NI在软硬件方面都积累了相当丰富的经验，使得我们可以省去不少的底层工作 ，比如NI现在大力推广他的FPGA模块，这个就非常的好，我们不必要去学习那些近似天书的硬件知识以及什么VHDL之类的硬件编程语言，就可以轻松的变成一个硬件高手，它可以替代ARM，当然也可以取代单片机了，我觉得这个可能也是NI的虚拟仪器概念在这个方面的一个延续和拓展。
因此，我建议大家在做系统测试时候，硬件方面就不用说了（NI的东西，绝对的在市场上处于垄断地位，既然是垄断价格当然是很高了！），咱们说说软件，在利用LV编程之前，首先在整个软件的结构体系上多下些功夫 ，尽量吸收一些成熟的结构而且在开发平台方面也不要仅仅局限于lLV要吸收各家之特长 。所以说我建议，针对底层的驱动接口开发还是用C比较好，运行速度比较快 用C做出的dll由LV来调用倒是没有什么问题 我觉得这种思想和我们解决VB运行速度慢采用的方式是一样的 仅仅用lv来做界面，而用c来写内码，效率就会大大提高 不过如果驱动部分lv自带的话就不用我们烦心了，呵呵
本人是非常喜欢LabVIEW的，唯一觉得遗憾的是，这个东东不是中国人人开发的，如果是的话就爽了，现在还不是地球一家人的时代，和异国人搞协作，总觉得别扭， 中国要赶上美国，还任重道远，不知道中国重庆大学研制的虚拟仪器开发系统VMIDS是否可以和LabVIEW抗衡，只是听过，号称是零编程，不过没用用过，期待他越来越强大！支持一下中国的软件产业。
特此声明：未经本人允许，不得转载
;){kind=link}