大家聊一聊LabVIEW的不足吧，

peizhirui

参加过几次LabVIEW的研讨会，听NI的讲过一些LV各个版本的重大改进，比如，引入事件结构，网络支持，引入类，面向对象的编程，这些自我摆不讲了,翻过来讲，LV基本上落后于主流的经典编程特性一代。

我主要使用LabVIEW7.1，觉得有几个方面LV很不好：1 版本问题，只支持保存为前面一个版本；2  迭代，他不支持； 3  与C的代码接口过程太复杂。


大家发表一下意见讲一下你的看法吧

master2002

平心静气的讲，LabVIEW入门的开始阶段会很容易，这一点给大多数人一个错觉，以为LabVIEW很容易用来开发项目。客观的看一些小型项目的确开发周期会很短、很容易上手。但稍微复杂一些的东西，用它越做越麻烦，反倒不如传统经典的开发工具啦。当然，凡事不可求全责备。各有所长，软件平台也都是此消彼长嘛，一点肤浅杂感欢迎大家继续讨论，关注中！

peizhirui

您的意思是大型项目的话，不适合用LabVIEW开发了？那用什么？VC，C#？还是传说中的measure studio啊，它们不过多一些资料，还有多一些面向对象的特性啊，个人觉得，如果项目大了之后，不遵守一些规则写程序（软件工程的？），写出来的程序极其难以维护，这个在那个平台都是一样的吧？

peizhirui

有一个问题请教一下方家，象birdeye这样的免费程序，如果用C来实现，大概要多少行代码？我不知道多大的程序规模算是大型程序，哪位能够给个例子吗？

Jon Conway  和Steve Watts倡导的LCOD方法，觉得还是很有生命力的，可惜我学习囫囵吞枣，加上没有什么硬件验证，不知道自己吸收了多少精华。

lishuping

我现在也觉得LCOD是Labview的有效方法，但要理解LCOD需要其他的编程技术文档来深入理解，那本什么《面向组件的编程*labview》的书我是看了N次也没完全看懂，但大致了解了作者要怎么干，

8.0,和8.2鼓吹的所谓面向对象编程在我看来就是在忽悠我们,本来我想就此观点进行论证和表述，所以在我的Blog   http://g-labview.spaces.live.com/里面开始了对它的批驳，写了3篇了，但后来发现这样很没意思，也没有时间，就暂停了。

labview给我的总体感觉是现在开始沦为自我繁殖的时候，自我繁殖的意思就是用自己的东西编制自己的操作平台了，就像那个生成EXE的模块就是。这就使得一些缺点会被无限放大。

简单举几个例子：
一个单一的while 循环，里面不加任何动作，运行，会占用CPU系统50%以上的资源，除非加一个1毫秒的延时

再来一个，event时间结构，无论你怎么弄，都不如在VB等其他文本语言来的高效，

我感觉图形化编程也需要开放源程序，让大家一起来优化才有出路，

而且需要增加一些特征，例如我放一个小点或者字符，就代表了连线，太多的连线真的太烦人，不能意味的舍弃文本编程思维，需要增加文本的优势

应该把C语言整合进来，我的意思是有一个类似Matlab那样，装一个runtime,来个框就可以处理C语言的语句

多了，真的多了，当文本方式编程问题也不少

interlope

程序本身越来越封闭,马上就是另外一个windows了,简直把客户当傻瓜

luhanhua

我也用它写了几个东西，灵活性较差。

kneken

感觉入门简单，但学深入进去后发觉，代码运行效率一般

paulbin

用了两年以后已经很少用LabVIEW了，至于上面延时来降低CPU占用，这个在.net里面是一个常识，LabVIEW天生多线程写的，而在写C#的多线程的时候再每个线程的循环中适当延时使得整体的运行效率高出很多。
个人观点，LabVIEW只是在和TestStand做配合的时候达到不错的效率，正好发挥了2者的特长，但是用LabVIEW来做较大工程，即使有不错的软件工程的思想和文档的支持在编写的时候仍然时常感到力不从心，当然这也有个人水平的问题了。

yxs1

就我而言，用LV开发复杂的测控系统可能不如其他语言代码工具，因为逻辑关系过于复杂

peizhirui

哈哈，楼上各位周末都泡在这个版上，值得学习啊，lishuping兄经常熬夜？
大家能不能猜一下下一个LabVIEW的大的改进是什么？  LabVIEW1.0，2.0的时代，它本身是不是用C写的，好像现在很多特性就是用LabVIEW写的了，所谓“自我繁殖”，封闭的根源？

客户选择LabVIEW开发工具，  一个是小型项目比较简单，二是和硬件结合比较紧（NI本身是做GPIB卡起家的？），三是NI的市场推广做的不错，技术支持凑合，反对盗版也不是那么彻底，（暗含先用盗版占领市场的意图，用结合的最紧密的硬件赚钱？）。  国内外都有一些专业做数据采集卡，或者提供LabVIEW的驱动的公司，cpubbs上可以看到一些，但是处于经济利益的考虑，NI不会公布足够的细节，提供完美的驱动开发包，不然，不是自己创造跟自个抢饭碗的？

所有的公司都希望自己能够提供统一，完美，易用的平台， 所以，整合了Mutisim， 推出各种版本，平台的LabVIEW，以后会不会和Matlab正面冲突？后者也提供了图形编程块，前者有什么仿真，控制之类包。

lgh269

如楼上所说,好像已经发生了
LabVIEW中的mathscript 已经试探性的来进行了与Matlab的相关处理

使用Labview做个小程序实在是方便，这点不大家是有目共睹的，
大的程序利用Teststand也不错，
但是总感觉NI过于夸大了labview

文本编程自有它的好处，
而且编程语言的不同自有它的用处
不然单片机为什么还有用汇编写的呢，

其实我觉得现在的经际时代，完成一件事的性价比最高就是好的
这个引用到编程中也不错，

peizhirui

程序本身越来越封闭---------同意；
灵活性较差               ---------能不能具体说一说，和谁比？哪方面？
代码运行效率一般   ----------这个高级的语言运行效率都比低级语言低，但是我们还是不会用0 1编程吧， 你是指的哪一方面， 我知道它占用资源比较大，空while循环cpu占用率高，编译时间长....  
文本编程自有它的好处，而且编程语言的不同自有它的用处性价比最高就是好的-------同意

perch88

我prefer纯编程，那个后台流程图太难用了，图标那么大，这不是欺负咱显示器小么，才21

我用一个exe 凡出现VISA什么的错误就要重新启动电脑和其他设备，不重起干什么都不行
每次见到这个错误就像被判死刑。。10分钟起码就没了

edison9513

没有右键功能，呵呵

hfhwz

最好不用

hfhwz

最好不用

peizhirui

楼上说话思路有跳跃啊，不用先得有个理由吧？能细说一下吗
从工程的角度看，哪种语言都是有缺陷的，我们不能都不用吧，反馈出bug或重大缺陷，或许您无意中和LV的新版本的改进方向合拍呢，

mcusir

我感觉就是比较贵，每添加一个功能，就做成一个模块，又需要钱。
NI应该把LabVIEW定位在更高领域的操作系统，普及了，降到低价，也应该比较赚钱的。其它都好，用起来很舒服，不那么特累。当然用的是D版，这样导致学习过程走了好多弯路，因没服务，也不能去邀请NI的同志来解决问题。
跟着NI方向是对的，就怕因太昂贵而不得不退缩，而被抛弃……

dengdeyi

abview 的突出的优点：
   对简单的功能实现非常方便非常傻瓜，你想想如果调试一台通用的新设备，一条命令都不用你写，直接把program guide 的例子放入 labview 自带的例子中去，还有什么程序比这个软件更方便的呢？所以简直就是初学仪器控制者的福音。
   版本问题确实非常麻烦，如果要转换版本，那只好动用一定的工作量了。不过我觉得大多数情况下，时间主要花在功能的实现上，能够实现如果只是过程复杂一些，往往不是耽误进度的主要方面。因此我想考虑版本的问题，一般出现在要利用或参考其他人的代码，这时候就只好安装各个版本的引擎了。但是第一次遇到这种情况或者是急用的时候，相信都是对labview的版本兼容大跌眼镜。但是如果能在装软件时按照提示把所有之前的版本都兼容，然后在labview升级的时候，及时保存以前的老版本，相信可以解决。我觉得在这方面，本论坛可以做的一个重要方面就是大家共享各个版本的 example ，因为很多东西其实都来源于这个；以及互相转换不同版本的代码。对于高级的用户可能帮助不大，但是对于初学的很多都有用，因为有时候不管有用没有就是希望看一眼呵呵