LabView vs LabWindows/CVI

[belight]

Thanks for your quick response.

1. When we develop the executable on LabWndows for example, it includes NI's LabWindows libraries in it.  Do I have to pay NI for the licence fee if my executable runs on each system shipped ?

2. Sorry I didn't know LabWindows uses ANSI C only.  So I would be able to take the codes developed in LabWindows, and tailor them to fit into Visual C# in the future if we develop our own application in Visual C#.

3. Thanks for the info.

[smercurio_fc]

For (1): If you're using just LabWindows then there is no additional license fee for the executable. The required libraries are contained in the run-time. However, some components, like NI Vision, have their own run-time licenses. You can read more here: http://digital.ni.com/public.nsf/allkb/61B2E57FE964392586257706005B7738 and here: http://zone.ni.com/devzone/cda/tut/p/id/9561

For (2): You would be able to in as much as it applies to any C code being ported to C#. However, if you think you're going to get into C# you might want to look into Measurement Studio.

[Euler's_ID]

I'm looking into LabView vs LabWindows/CVI, and I ran across this thread in the NI forums, and also had the time to read it all; however, based on the dates it covers, I'm hoping there is still response. 😞

Of all the posts in this thread, one post, by altenbach, actually, albeit briefly, addressed the issue I was questioning in my initial Google search:

Altenbach said:

"The inherently parallel nature of LabVIEW automatically takes care of utilizing all available CPU cores if needed and I have written many programs that would be very difficult to do in anything else in their current form. A single LabVIEW program can acquire data, control multiple instruments, run a simulation, react to cursor movements, do realtime analysis, etc. etc. all at the same time and without missing a beat and without having the programmer jump through flaming hoops."

The key phrase there is "realtime analysis."  Granted I'm asking about "real-time" analysis, but I'll presume that's what was meant when it was said.

Computers only do what you tell them, and despite the speeds now, they still run, at their core, on machine code, sequential instructions of ones and zeroes to a processor.  Hence, when I see LabView (if the VIEW is supposed to be uppercased, I don't know why yet -- please tell me) and parallel paths in its "programs" diagrams, I question just how parallel it can really be.  For what I do, it's very important that when something happens it is known when it happened, not just get LabView's result when it finally comes in.

For instance, looking at LabView's diagram-based program, it might be easy to see a control system easily implemented in LabView.  Take a simple operational amplifier circuit, for example.  The output is the result of the input signal compared ( Vo=A(v+ - v-) ) with the feedback from the output while being multiplied by the open-loop gain.  However, is this really how LabView works?  I have my doubts, knowing what I know about how a computer works.  LabView still must be handling events in sequence.  In other words, that comparison with feedback, using my operational amplifier analogy, isn't actually happening in real-time, but yet that is a requirement lest the operational amplifier not operate like an operational amplifier but rather an amplifier with an enormous gain.

LabView is being marketed to hardware folks, and it is the diagram-based versus text-based interface that is the appeal, but can it really accomplish the real-time operation as it would appear, given the parallel paths of its diagram "programs," or is there a lot of overhead involved that causes the seeming real-time operation of C running very fast to become quite noticeably more of a real-time operation than LabView?

Lastly, if I wanted to give LabView a whirl without investing anything but time (and time still is money!), what would the LabView-experienced here recommend?  I'm no stranger to circuits nor LWCVI, but I certainly am quite the stranger to LabView, aside from the diagrams I've seen but haven't even closely examined which are LabView's programs.        

[tst]

I didn't read the thread now, so I'll try to focus on your questions (hopefully).

First, the easy one - VIEW stands for Virtual Instrumentation Electronic Workbench, so it is indeed capitalized.

Second, you are correct that LabVIEW, like any other programming language, eventually comes down to machine instructions being processed on the CPU. In that respect, it is as sequential as any other language (I'm ignoring multi-core processing, which should allow parallel execution and which LV does support fairly transparently, and also FPGAs, where there the operations are truly parallel).

The point of the parallism is usually more about the fact that you can (and often must) write it as parallel code and the LV compiler will do the work of splitting the work up into parallel threads, etc., so that it can be run in an efficient manner. The code might or might not actually execute in parallel, but if you have multiple CPUs and know what you're doing, you should be able to achieve parallel execution.

Third, "real time", as I'm sure you're aware by your use of quotes, is a problematic term. In this case, I'm assuming Altenbach would have meant either "not after the fact" or "you can run LV code on some RT operating systems, thereby allowing you to achieve real-time performance". I think that if you ask an actual technical question about what you want to do, someone might be able to give you a better answer.

Fourth, LV vs. CVI - I can't say anything about that, because I never used CVI. I'm assuming the rest of the thread did cover this reasonably well. Personally, I was never particularly impressed by the look of CVI compared to other IDEs, but I haven't seen any recent versions.

Lastly, NI used to have an online trial for a few hours, where you basically log into a remote machine, but I don't see it now on the main LV page. You might find it if you search. You can download LV and run it in a fully functional eval mode for 30 days and then activate it if you like it (or ask your local NI office if you can get an extension on the eval). I usually point beginners to these tutorials, but I don't know if they'll help you. You could try asking your local NI office if there are any user groups in the area if they can give you an actual demo of the software, which might help you decide.

If you want, here are some relevant links:

http://www.ni.com/white-paper/11472/en

http://zone.ni.com/devzone/cda/pub/p/id/1177

http://zone.ni.com/devzone/cda/pub/p/id/1675

http://zone.ni.com/devzone/cda/pub/p/id/1020

http://www.ni.com/white-paper/11473/en

[JÞB]

A few things need a response.

"Laboratory virtual instrumentation engineering workbench" Is the source of the anaogram LabVIEW.

LabVIEW is a development environment that obey the requirements of the OS it supports developing applications to run in.

LabVIEW isnot an operating system, it is a software development environment that may build applications that obey rules imposed by many operating systems. (Mac winx Linux and several "Real Time" targets)

LabVIEW generated code will not be ( & CANNOT BE ) more time deterministic than the OS it operates within.

all that being said.. this rapid development environment. .... keeps my clients profitable.

[yenknip]

The rule of thumb for a good software engineer, is to learn a new language every year. This is to help the developer satisfy rule number 1 of writing software; use the right language for the job. Have a go at learning both LabVIEW and the LabWindows libraries, even if it's just part of your learning routine, and see if it would be suitable for you.

I would consider that I have a good basis in C and LabVIEW; I have an expired Microsoft developer certification, and in 99% of cases I would go to LabVIEW for any control or automation projects

As an aside, LabWindows/CVI works perfectly happily in any C IDE; I always use it in Visual Studio.

[drjdpowell]

---

Euler's_ID wrote:

For instance, looking at LabView's diagram-based program, it might be easy to see a control system easily implemented in LabView.  Take a simple operational amplifier circuit, for example.  The output is the result of the input signal compared ( Vo=A(v+ - v-) ) with the feedback from the output while being multiplied by the open-loop gain.  However, is this really how LabView works?  I have my doubts, knowing what I know about how a computer works.  LabView still must be handling events in sequence.  In other words, that comparison with feedback, using my operational amplifier analogy, isn't actually happening in real-time, but yet that is a requirement lest the operational amplifier not operate like an operational amplifier but rather an amplifier with an enormous gain.

LabView is being marketed to hardware folks, and it is the diagram-based versus text-based interface that is the appeal, but can it really accomplish the real-time operation as it would appear, given the parallel paths of its diagram "programs," or is there a lot of overhead involved that causes the seeming real-time operation of C running very fast to become quite noticeably more of a real-time operation than LabView?

 .        

---

Hi Euler_ID,

You're making a common initial misconception about how LabVIEW's "Dataflow" works.  It isn't like a signal in a physical circuit, with continuous and near-instant flow. Instead, it's a discrete operation of output values flowing to input values, with functions only executing when all inputs are avilable.  Download LabVIEW and give a few exmples a try with "highlight execution" enabled in order to get the idea.

So in fact, your right, LabVIEW does not, and can not, work the way you imagined it to work.

-- James

[Romsky]

If you favor your left (objective) side of the brain, then LabWindows/CVI (LW) is the best choice.

If you favor your right (subjective) side of the brain, then LabVIEW (LV) is the best choice.

I can do either but prefer CVI.

LW is code that is compiled down to machine code, LV can also be compiled down to machine code but there seems to be a bit more overhead left after the conversion from a "graphical language", thus LW often runs a bit faster than LV when performing very intensive number crunching.

In LW, your variables connect by "names" (logiclly in the "ether").

In LV, your varibales mostly connect by "wires" (physically on the "screen").

In LW generally your program flow is from top to bottom as you read.

In LV generally your program flow is by wires/frames you follow.

Although LV may look like a schematic, it is not, and if you don't "graphically" code properly, what may look like sense is not sense at all.  This is especially ture for those new to LV or any programming langugae for that matter.

In LV you constanly have to hover over an icon (a "vi" as it is called) to determine what something is. Which is a bit slower to read. Comments are possible just about anywhere, but I do not see it as often as it should be in LV.  At first the vi's had nice little diagrams that gave you a hint of what they did, but now there are so many vi's they just appear as blocks on the screen.  So, essentially the way most people code in LV, you need the LV editor just to read it.  But in LW, I can just hand over code and anybody can read the code using any text editor they wish (emacs, notepad, etc) - even if they don't have LW installed.

In LW you simply read text. However, you rely on good comments by the author to tell you what is going on.

In the end, only good coding practices in both worlds make LW and LV code very easy to read and follow. 

LW Code is easily shared, just cut and past text, LW code is a bit more complicated, you can't always cut and paste graphical images like you can with text.  For example, LW code you can paset the text into a forum, by LV you need to attach a graphic.  Then in LV if you can't see what the vi's are doing, you need to code it into LV to really get the idea of what it is doing.

For me the show stopper for LV is that I find that a lot of my time is spent connecting wires and making them "pretty" (easier) for the next person to read, where in LW only some of my time is just indenting to make it "pretty" (easier) for the next person to read.

I write "clean" code and document my code very well from the get-go (in fact most of it is self documenting becuse of the variable and function names I call things), so little effort is made along the way, but in LV with the constanly drwing boxes around things to move them around, moving wires, and such, it is simpler in LW to cut and paste text and not have to worry about all those "connections" in the physical sense.

Some people can code pretty fast in LV, but by the time you can bring up your vi list, click and drag it into position, and connect the wires, I am already done typing that function "line" and on to the next line of code in LW.

so..another way to sum it up is...

Aglinet VEE is like a KIA with Automatic Transmission (a weak but easy to use tool similar to LV)

National Instruments LV is like a Cadilliac with Constant Velocity Transmission

National Instruments LW is like a Formula Car with Manual Transmission

The arguments go on an on, but it all boils down to Left/Right side of brain.

[altenbach]

---

@Romsky wrote:

The arguments go on an on, but it all boils down to Left/Right side of brain.

---

No! That's a myth and since it is a premise for all your other ramblings, you probably should start over with the entire argument. 😄

Most of your statements are highly biased and just opinions that might not apply to most people. I understand that some people have problems dealing with 2D. Some of my ideas on this same subject can be found here.

---

Romsky wrote:

Aglinet VEE is like a KIA with Automatic Transmission (a weak but easy to use tool similar to LV)

National Instruments LV is like a Cadilliac with Constant Velocity Transmission

National Instruments LW is like a Formula Car with Manual Transmission

---

The problem with such analogies is the fact that they are flawed. The only reason that F1 race cars don't have automatic transmissions, is the fact that they are illegal by some arbitrary current rule. Except for the gear selection with tiny paddle shifters, everything else IS pretty automatic, including throttle control. Besides, race cars have huge disadvantages, making them pretty useless for any typical use (unlike text programming languages!!!?). F1 race cars only seat one person, they cannot carry any luggage, they are not street legal, they require constant maintenance, and they also crash quite often. Not a good comparison! (... or maybe it is a good comparison after all! :D)

[Hooovahh]

I agree with Christian that many of the things you stated are a matter of opinion.  Listed below are the things I find are subjective and would need further proof before agreeing with you on.

---

@Romsky wrote:

• If you favor your left (objective) side of the brain, then LabWindows/CVI (LW) is the best choice.
• If you favor your right (subjective) side of the brain, then LabVIEW (LV) is the best choice.
• LW often runs a bit faster than LV when performing very intensive number crunching. - Depends on the way the code was developed
• In LV you constanly have to hover over an icon (a "vi" as it is called) to determine what something is.  At first the vi's had nice little diagrams that gave you a hint of what they did, but now there are so many vi's they just appear as blocks on the screen.  So, essentially the way most people code in LV, you need the LV editor just to read it. - Similar issues exist with text code when calling a function you have no idea what the function does, bad developers don't make a bad language, make a damn icon.
• LW Code is easily shared, just cut and past text, LW code is a bit more complicated, you can't always cut and paste graphical images like you can with text.  For example, LW code you can paset the text into a forum, by LV you need to attach a graphic.  Then in LV if you can't see what the vi's are doing, you need to code it into LV to really get the idea of what it is doing. - Attaching a zip with a project is better than pasting a string of text, same for LV attach a zip with all the files not a screenshot
• For me the show stopper for LV is that I find that a lot of my time is spent connecting wires and making them "pretty" (easier) for the next person to read, where in LW only some of my time is just indenting to make it "pretty" (easier) for the next person to read. - When coding LV name your data in a cluster, used named states and most of the documenting is done for you, add comments as needed like any other language, style in LV is just as important as style in other languages
• [In LW] little effort is made along the way, but in LV with the constanly drwing boxes around things to move them around, moving wires, and such, it is simpler in LW to cut and paste text and not have to worry about all those "connections" in the physical sense. - Style in LV is just as important as style in other languages
•  Some people can code pretty fast in LV, but by the time you can bring up your vi list, click and drag it into position, and connect the wires, I am already done typing that function "line" and on to the next line of code in LW. - QuickDrop
• The arguments go on an on, but it all boils down to Left/Right side of brain. - No it doesn't

---