For new project, why use cvi instead of Labview or. vb.net

[cgantz2000]

I may be starting a project using cvi shortly. I know C/C++ and have used Labview, and my languaage of choice is vb.net or C#. So at risk of starting new flames I am asking this question.

First, if I were giving advice on what to use to someone who did not know how to program on what to use to control instrumentation, I would tell them to use Labview, since they could be doing a reasonable job measuring in a couple of weeks.  In vb it would take a few months to figure out things well enough to write a windows program to measure, and in C/C++/C#, which includes cvi, probably close to a year.

But for someone experienced in Labview and/or vb/C/C++/C#, even if they know cvi, I don't see a reason to use cvi. Labview vs. vb seems just a matter of choice. As far as I can tell anything that is done in LV can be done in vb, especially if you have measurementStudio. I am not a big LV fan because it is hard to maintain and document properly, but I like it for doing a quick prototype. vb.net I think is much better for designing the GUI and for writing a complex program. For example, I recently wrote a measurement program that had to perform about half a dozen measurments. The measurements could be different for different modules. The program I wrote stored measurements and the specs in an xml file, used serialization to save things like technician name and type of measurement between sessions, allowed the modules to be operated manually if desired, or would run tests automatically by using events to operate the same radio buttions that would be clicked if operated manually. While this may be possible to do in LV, I think the complexity would make the LV program very hard to write, let alone maintain or extend. The program used the ni488.2 dlls to talk to the oscope and other GPIB instruments.

But for cvi, I just don't see a reason for using it for new programs. I could see it for legacy programs, or if you only know C and didn't want to learn vb or C#. But C is messy even for those that know C, and of course you can't use  modern programming concepts such a OOP. And things like lists and hashtables (which I've always liked using) just aren't really there.

So the question is, why use Labwindows/cvi?

[RobertoBozzolo]

ACcording to what you told us, the answer to your question is: there is no reason to use CVI instead of VB and / or LV! Since you are exerienced in these languages and since all of them are powerful and flexible, there is no reason to invest time to learn a rather new language.

Based on my esperience, I personally disagree with your estimated learning curve of CVI but this is a matter in which personal habits, experience and knowledge have a great influence. Just to point it out, I firstly approached CVI in 1996 and in approx. 4 months I developed a complex ATE application with double buffered data acquisition, sound measurements (which were new for me) and two computers interacting via TCP/Ip in an environment as friendly as Windows 3.11! Well, the application is still running in its original configuration, and even if in the following years my knowledge and degree of usage of CVI has greatly improved, I can say that that experience has given a great impression on me for what concern power and flexibility of the environment and speed of development (and on the level and experience of NI support service!)

On the other hand, we had to remake and old application for endurance testing on devices originally written in Basic for DOS and we thought that moving it to VB could have saved us some time in development due to the similarity of languages. It was en error! The operative part of the software (the only that could be ported more or less "as is" to the new environment) was less than one third of total code, but the difference in GUI approach is so relevant and involved so much time in porting the application that after that experience we decided to move the entire application to CVI. What we satisfactory did when we had to produce a new equipment.

What I am saying is that in my opinion is better that you continue using your well known instruments which can give you satisfactory results without real need to approach a new one. While it is rather difficult to use at a professional level two different up-to-date develompent environments, I tend to think that it is impossible to use three of them!