How do I choose between LabView and LabWindows?

[Thayer79]

We have been using LabView for a project, but are considering migrating to LabWindows/CVI as part of an upgrade.  How do I choose between the two?

We have a LabView app. written by a grad student (but out-of-date and not that well documented) and modified by someone with little programming experience of any kind.  Now it's my turn.  The hardware is getting a major upgrade and we're trying to decide whether to patch the current program, extract only the vis we need and do a new LabView app, or migrate to LabWindows.

I have many years' experience with a variety of languages, but am not proficient in any. I've used LabView a little, and think I could pick up either LabView or LabWindows.

The project involves  motion control, data acquisition and analysis. The outside contractor doing the major hardware upgrade recommends LabWindows, but they have more experience in C programming than in LabView. LabWindows is attractive because although I don't know C well, I have much more experience in command line languages than in GUIs.  I'm also big on documentation and writing well-structured code - both those seem difficult in LabView.

I've looked on the web and haven't found much about LabWindows, so I'm concerned it's a bit of a dead-end and maybe not used much, or won't be supported in the future.  There's also a cost factor - we have LabView 8 (current version) even tho the app is written in 7.1, but we'd have to buy LabWindows which is not cheap.

[MJF]

I honestly don't believe LabWindows/CVI (CVI for short) is going away anytime soon. There is an active community using it as this board should adequately demonstrate.

Both platforms have their strengths and weaknesses. LabView (LV for short) tends to be liked more by people who are not programmers first. The graphical nature of it tends to allow for quicker development of simpler programs. It gets a bit dicey when doing large projects and can be very unweildy and cluttered when you have complex program flow. There is a tendency for many instrument manufacturers to provide drivers for LV over ones for CVI. I personally find this to be an issue in rare instances because I have no problem with diving into the intstrument manual to find out what I need to do to get the results I want from the instrument in question.

CVI on the other hand is an ANSI C implementation with an IDE and a lot of libraries to support control of instrumentation and the GUI elements of a program. The GUI elements are part of the CVI run-time environment and not native Windows implementations (which believe me, you would really not want to have the native WIndows API exposed, it's a MAJOR pain to use). As an old-school C programmer who has been using the language since long before it became a subject of an ANSI standard, my personal preference is CVI (CVI 3.0 was my first exposure to the environment, things have changed a lot since then). I really do not like the LV way of doing things, I find it does not fit well with the way I solve programming problems.

So really, it comes down to personal preference. You can download the latest versions of both LV and CVI and install them in demo mode so you can try them out. That would be my personal recommendation on how to choose, see which one works better for you.

[Ian.W]

Below are some links to similar threads. I believe both would serve you well. A close look at driver availability, real-time needs might swing you to LabView. Its structure comes from the VIs.

Probably the biggest factor is, in the long term, what type of people do you expect to be involved in your projects? Are they likely to have programming backgrounds that make them predisposed to use C, or avoid it? 

http://forums.ni.com/ni/board/message?board.id=180&message.id=5473&query.id=60233

http://forums.ni.com/ni/board/message?board.id=180&message.id=230&query.id=60264

http://forums.ni.com/ni/board/message?board.id=180&message.id=10797&query.id=60269

Good luck!

[menchar]

I would echo Martin's comments.

Capable C programmers tend to like CVI over LV.  I don't think it'll go away very soon.  It's used extensively in the defense industry.  I've been using it since the days of DOS.  Currently we use a license server for CVI to lower costs a bit, and we have an in-house CVI support team.  It is somewhat pricey.

I think it's fair to say that LV appeals more to scientists in the sense that they can visualize a solution that doesn't require them to be competent programmers.  The high level of abstraction provided by LV does require quite a bit of support, which NI is happy to provide.   Their sales and field engineers tend to be adept at LV more so than CVI by my experience.

An engineer / software person is likely comfortable with the C programming language (it's still the lingua franca of the technical world) and more readily envisions solutions with C.  I will say hacking out gobs of procedural code with C gets old ( not OO ) but you can use the CVI libraries with VC++ if you like, or the .net languages.

NI attempts to remove some of the harshness of dealing with the Win32 API and Windows OS environment  with their libraries.  There's nothing standard about a CVI library ( as compared to a formal standard) , but it does let you get something going with a shallower learning curve.  I find in some cases (e.g. multi-threading) I'd rather use the Win32 API directly than the relevant CVI library.

Personally, I'll concede it'll take a lot of C code to implement a solution, but I am better able to estimate the time required and that I'll ultimately succeed, because I can get "under the hood" so to speak, it's a much lower level of abstraction.  LV fans will point out you can incorporate procedural code (i.e. C) into LV apps.

I'm also able to implement concurrent (multi-threaded) software designs in a straightforward manner with CVI.   Not sure how that works in LV.  

A little knowledge is a dangerous thing though - I've seen some very poor CVI implementations.  The paradigm with C is "trust the programmer" to be self disciplined and not do stupid things.  If the implementors can't be trusted to do this, they shouldn't be using CVI.  It's remarkable how much you have to know to be a genuinely good C programmer, given that it's a relatively small language that's been around a long time now. 

75% of NI's software sales are LV from what I've heard.

Post this same question on the LV forum and you'll get a different take on this, I'm sure.

[Thayer79]

Many thanks for all your insights, links, and  good advice. I actually did post to the Labview forum and it's been interesting to see the different takes.  Much appreciation for everyone's time.

Margaret

[mvr]

To add a bit more:

CVI has been around for years.  Porting applications in and out of CVI to other C compilers is very practical, so in that sense you are never really locked into CVI. 

For your requirements of data acquisition, motion control etc, the toolkits and other features of both Labview or CVI make both very well suited to this type of application.  Both LabView and CVI are far better tailored for use in development by Engineers turned programmers than most other development environments.  Both make it very easy for someone with a limited software background to acquire data, process it and display it.  The LabView model insulates the user from the need to learn low level syntax for basic tasks and as such is often a better than CVI for simple applications written by someone with limited software experience.   But as the complexity of the application increases so does the need for someone with software design skills.  At that point both CVI,  LabView or any development language are not trivial for anyone who does not have a software background.  The effort in learning to use LabView or CVI at the master level is not really that different.

Many CVI and Labview developers are hardware engineers who have made there way into the software world.  Some engineers have a real software aptitude and find the adjustments easy, others struggle.  Software development for anything but the most trivial applications is an skill.  Handing someone a copy of LabView does not make them a skilled programmer any more than getting a copy of Microsoft Word makes you a technical writing and publishing guru.  Both CVI and LabView are tools for the application developer.  It is the skill of the developer in application design and their ability to use their tool of choice that contributes most to the development outcome

Basic features are:

LabView syntax is initially easier to learn for EEs without sw experience because of the similarity to the hardware schematics you already use.  The data flow model of LabView is very applicable to FPGA design or designs where the flow of a set of data from acquisition to processing to display is the dominate feature of the program.  For applications that are built around actions (not data flow) LabView still works fine but CVI has advantages when dealing with complex interaction between asynchronous events, actions or states.  CVI has traditionally been better at the event driven programming model, but LabView has added more capability in that area as time goes on. 

CVI integrates with modules from other languages easily, dlls, activex, handling of variant data types etc.  CVI also provides low level access to windows SDK interface with means that CVI is really never limited in what actions can be taken.  There are a lot of LabView developers, and finding an third party LabView developer is not much of a problem.  NI provides in depth support for LabView.  CVI developers are a little less common, but far from scarce.  Any competent C/windows programmer can get very comfortable with CVI in a short period of time so finding resources to work on CVI programs is not usually an issue.  Engineering support for C based solutions and routines is never an issue as so much C based engineering material exists.  Incorporating these into CVI is usually pretty easy.  CVI has traditionally been much easier to use in a distributed development project where many individuals are working on separate tasks for a common project.  The latest version of LabView has made big gains in that area, but the modularity of C/CVI has allways made it a great choice for large scale development projects.

Ultimately I suspect both are good choices for your application unless it is very complex.  The environment that your programmers are most comfortable with and their understanding of the application they are trying to design will be far more important than the difference in features of each package.  I have seen skilled programmers write  some excelent applications in very poor programming environments and languages.  But as I am sure you know, the best programming tools do not make anyone an instant software engineer.

Good Luck.