labview vs labwindows

[vishi]

I haven't used LabView, as I am very comfortable with LabWindows CVI. Now Boss wants me to only use LabView. I am an experienced C guy. I am trying to convince my boss that whatever anyone can do it LabView I can do it in CVI. Yes, it does take a bit while to write the CVI code, but being simple C, if we need to we can hire any of the available C programmers and make them learn CVI faster than LabView. What do you guys think?

I am not picky on languages, each one has its points. The key is to use the right language depending on the project, but tough to explain to the boss. Any comments to help the poor guy.

[SachaE]

Hi,
this is always a tricky one that gets asked time after time.
The key is exactly as you've said - you can do everything in CVI that you can in LabVIEW. In terms of development time, I've known things take longer in LV than in CVI, but they've been really large projects.
The two main advantages of LabVIEW are 1) the learning curve - for someone who's not done a lot of programming before, but has a fair idea of what they're trying to acheive, you can learn LabVIEW a lot quicker than CVI, and 2) it's graphical - you can show your program to almost anyone and they can get a good idea of what's trying to be acheived.
However,
it can take a long time to learn all the tricks of LabVIEW including all the memory management techniques, and really tweaking the best
out of the environment.
In short, if I was writing something time critical, I'd use Ada, if it was obviously based on a class heirarchy, I'd use Visual C++, ActiveX based, probably VB. Data Aquisition / instrumentation control prototypeing LabVIEW, Lower level / speed issues with NI / third party hardware / drivers - CVI -> The list is endless.

I don't think you're ever going to convince your boss that he could be making more work for himself by "demanding" that all projects are in LabVIEW, but get him to come up with a "simple" proof of concept project and compare the development times in LabVIEW and CVI. When they turn out comparable, you might have a chance of getting him to allow you to develop in both languages - you can always modularise the project, and make .DLLs in both languages, tieing things together later.

Hope that helps (although it's really only confirming what you've already said)

S.

[layosh.b]

Years ago I did look into whether to use Labwindows of Labview.
No question, if your project is simple and more or less trivial, LabView is
easier and faster to implement.
However if you want to do something more complex or abstract or something
that is not easy to fit into the Labwiew paradigm, you are stuck, and that
is it.
So if flexibility has any value in your projects, stay with Labwindows.
In addition (with my C backgound) I had trouble to learn to see things
through LabViews components and blocks and connectoions, for me the learning
curve was very steep. Finally I gave up to use it even for the simple
things.
Similarly, the gigabytes to read and tonns of stuff to learn about
Microsoft Visual C++ and MFC was too much for me. As somebody that uses
programing to beco
me a "value added" molecular biologist, I was looking for
someting that is simple and easy to handle. Maybe CVI is not the fastest,
but it does the job reliably, and its libraries are excellent and its
simplicity and ease of use is amazing.
I would not complain about the speed of development in CVI either. Although
it does not involve labview, but we did a small test with a friend of mine
by solving a relatively simple problem that involved acces to some hardware
features. He used pascal, and it took him 4 afternons to accomplish
something that I was able to do in 3 hours. He is an avid CVI fun ever since
🙂
regards: Lajos

[vishi]

Thanks for your input.

As I write this, I am in a LabView class. Company paid for it so I am not compalining. Somthing new to learn and add to the resume. Having played with labView in the class for the last 4 days, it seems for big projects, CVI is the way to go. If you don't know C, labView is very good. But I can type faster than draw code. Also for instrument drivers and low level stuff, I still need C. Something like the power users sticking with command line options and not going the GUI route.

[Nick J]

No discussion of Labview versus LW CVI would be complete without mentioning the
issue of code portability. The CVI compiler is ANSI standard C compliant, so
that code you develop under the CVI IDE can be recompiled with another
ANSI-compliant C compiler and targeted for most any platform, including embedded
systems. Where I work, we often develop software algorithms using CVI, then
recompile the exact same code to run on an embedded target system (sometimes
using conditional compiler directives to isolate platform-specific code,
sometimes not). Conversely. you can take any ANSI C code (of which there is a
great wealth of open source available on the Internet as well as from numerous
good books such as "Numerical Recipes in C"), compile it under CVI and
assimilate it into your program. This way, you can leverage the hard work of
many highly skilled C programmers and save yourself having to "re-invent the
wheel", thus enabling a much broader spectrum of applications than Labview will
ever be able to support.

Kernighan and Ritchie created the C language out of the need for porting
Operating Systems to various hardware platforms and hence, portability is a key
aspect of the language. C compilers are available for more platforms and
processors than for any other programming language, which is why Bjarne
Stroustrup originally harnessed this widespread C compiler technology by making
his original C++ compiler ("C-Front") generate intermediate C code instead of
native assembly language.

C has been called, "portable assembly language" because of its speed and code
size efficiency which Labview cannot match. Of course that can be a
"double-edged sword" that, when used carelessly, could potentially lead to
system crashes and lock-ups, if it were not for the fact that CVI has many
built-in features that are characteristic of so-called "safe" languages like
BASIC and Java e.g. run-time array index bounds-checking, run-time checking of
printf() arguments, null-pointer dereference checking etc. These features make
CVI an invaluable time-saving tool for rapid prototyping of software that
eventually will be recompiled and embedded into analytical instruments and
similar products which demand "real-time" performance.

Nick J.

[Al_S]

Labview is available for MS-Windows, Mac OS, Sun Solaris, and Linux. That sounds pretty portable to me.

Labview Real-Time is also available so you can move your code directly to hardware running a real-time operating system.

So even though you can't easily port Labview code to other compilers, you have a lot of choices of where you can run Labview, including embedded real-time systems.

Don't dismiss the wealth of Labview resources which exist. From sample programs to Labview forums and code libraries, there's a lot of help out there so you can avoid reinventing the wheel.

If you have some existing C routines you want to use in Labview, you can use DLL calls in Windows, shared library calls on a Mac, or Code Interface Nodes (CIN's)
on any Labview platform.

Labview doesn't produce small code. But smaller doesn't necessarily mean faster.

I have programmed in assembler, BASIC, C, C++, CVI, Lisp, LabView. I don't think any language is one-size-fits-all. Your applications may have some specific requirements that guide you to choose a development tool. For most test and measurement applications, there are no show-stoppers for Labview.

[Jeremiah Cox]

Greetings Nick,
Yes, ANSI C is very portable. However, keep in mind that if you use the CVI libraries (GUI, Analysis, Serial, Formatting, Utility, ...), you will be limited to those operating systems on which you can acquire a CVI runtime library (Windows, Solaris, and a few others if you can find them (no longer for sale I believe)) - or you end up reimplementing the functionality yourself which defeats the purpose. The CVI integrated development environment (with the interactive debugger that I agree is awesome) is available on even fewer platforms, and only Windows has the latest version and features. I just wanted to reinforce proper expectations on where CVI can and cannot go.

Sincerely,
Jeremiah Cox
Platform Services Product
Support Engineer
National Instruments

[Nick J]

Both Labview and LabWindows are excellent programming tools and but like all
tools, they both have strong points and weak points. The pros and cons of either
tool for Test & Measurement apps have been hashed over before in this group. I
was addressing R&D and product development apps.

I didn't say that Labview is not portable. The point I was trying to get across
is that ANSI C is portable across far more platforms and target systems than any
other language. We've often taken modules containing algorithms that were
developed and debugged on a workstation and recompiled them to run on 8051 and
PIC microcontrollers, without modifications to the code. I'm not aware of any
other language that has this much adaptability. Of course there are
cross-platform IDEs which target specific processors but those development tools
typically can't be adapted for other target processors and they usually lack the
facilities for simulating a target system's user interface, which is easily done
under Labwindows CVI.

The convenience of debugging algorithms and UI code under a safe, protected-mode
workstation environment that will eventually reside in an embedded system is
hard to beat for the kind of work we do. You can easily simulate the embedded
system's front panel and user interface with the CVI GUI tools and simulate the
hardware inputs and record the outputs with stimulus/response log files. This
approach lends itself nicely to automated system regression testing and
validation. After adopting this methodology, the only reason we have to resort
to using a debugger on an embedded target system anymore is mainly for hardware
debug. Labview Realtime is great for high-end embedded systems but it doesn't
meet the cost objectives of high-volume embedded systems like ours.

Calling a DLL from Labview in order to utilize existing C code may work but it
requires building a DLL shell around the code first and then compiling/debugging
under a different IDE and toolchain. I think there are also restrictions on the
types of data that can be passed back and forth and well as limitations with how
the data is passed and there is no access to global variables. Its also
inconvenient because you have to keep switching back-and-forth between different
IDE's and languages to edit, debug and compile the code. For cross-platform,
embedded systems development its not a good solution.

But heres a suggestion: Why doesn't NI combine Labview/Labwindows into one IDE
so we could have the best of both worlds under one product? That would put the
Labview vs. Labwindows debate to rest forever! Just kidding. I know thats
"easier said than done" and theres probably not a lot of demand for it from the
T&M world that comprises NI's main customer base.

Nick J.

[Wendy L]

Hello everyone,

In an attempt to try to catch everyone who might have a LabWindows/CVI and Linux or Real-Time interest, I'm going to repost this information in this thread as well. I know this thread has been going on for a few years now, but I wanted to update whoever is interested in the latest LabWindows/CVI modules that we've released to try to address your multiplatform support needs:

So we now have a Real-Time Module, which allows you to develop LabWindows/CVI apps on a Windows machine and run on a real-time PXI or PC target.

Also, to partly address the main subject of this thread, in August, we release the Run-Time Module for Linux, which similarly allows you to develop on a Windows machine as you always have with CVI, and then run your application on multiple Linux distributions.

That's a brief overview of the latest modules, but if you want more information on what hardware is supported and also a more in-depth discussion on the module, take a look at the following resources:

Real-Time Module: www.ni.com/lwcvi/realtime

Run-Time Module for Linux: Introduction to the Run-Time Module for Linux Whitepaper

Thanks.