Differences between Labview and LabWindows?

[UKnowWhat]

beside the obvious that one is a graphical language and other is text based. We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. What would be the ideal platform to do the job described above? Why would NI build 2 products when one can do the job so it must be something in it to differentiate the 2 products, right? TIA.

[m3nth]

beside the obvious that one is a graphical language and other is text based. We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. What would be the ideal platform to do the job described above? Why would NI build 2 products when one can do the job so it must be something in it to differentiate the 2 products, right? TIA.

5750[/snapback]

I found myself evaluating this same question a long time ago.

You're right, they kind of do the same things. It just depends on your needs and resources as to which you might choose.

If the person(s) working on your project are fluent in C you may want to go with LabWindows. LabWindows facilitates people with previous experience in that arena. It also does not require a customized compiler that is controlled by NI--any standard compiler should work right (to the best of my knowledge). Also since it is text based, it suits itself very well to version control and software quality assurance or configuration management. From your problem description, that might be a pertinent thing to regard if you work for a company with established policies and procedures. While LabVIEW can be used with VCS systems, it's really clunky, you can't do easy compares on the code since it's graphical, and other issues like that (such as the fact that files are tens to hundreds of k's, instead of small text files, and that no two compiles of identical code turn out identical executables). Something else to consider about LabWindow is that if you ever have the need to integrate non-standard functions such as OS calls, it's probably a lot easier to do. In LabVIEW, it is much more complicated to make function wrappers for kernel calls or non-standard LabVIEW functions that NI or third parties haven't developed. Often third parties develop C/C++ code for just about everything, which you can find on the web and easily adapt with LabWindows, but not necessarily LabVIEW since it is not nearly as common.

If you don't have experienced programmer(s) however and everyone working on the project will be generally new to programming, LabVIEW may be the way to go. It's intuitive at some level if you have any kind of computer or programming background (even if you're not fluent in anything in particular). Like I said earlier, it does not lend itself real well to VCS or SQA/SCM sometimes. It can also generate very large applications in terms of disk space, which also has associated costs in terms of VCS and network transfer speeds (depending once again, on your company resources and needs). It can also be extremely difficult to upgrade in the future if someone makes a project that's their first project and then leaves it be for several years. The problem is that people usually do that with not enough time and not enough experience and their coding style and archictecture is horrible. Just because LabVIEW is graphical doesn't mean it's self documenting in the slightest (in my experience, that's the furthest thing from the truth). So be careful if you're giving this to someone as their first project and you or they decide to use LabVIEW. Make sure they get trained--send them to the NI training if necessary which is really good, both basic and intermediate. Make sure their coding style is going to be readable and usable by someone else with LabVIEW experience. Make sure they're going to use a flexible archictecture which will allow for future upgrades, and more or less, make sure there is someone else to audit their programming.

Those are just suggestions from my own experience but it will really depend on your resources. Throw enough time and money at a problem and either solution will work right? Good luck.

[dswaine]

... Why would NI build 2 products when one can do the job so it must be something in it to differentiate the 2 products, right?.

5750[/snapback]

There's history involved too. LabVIEW for Windows only came out in ~1992; before that it was LabVIEW for Macs (since '86) and LabWindows for DOS (since '87). There's a couple of articles in NI's old 'Instrumentation Newsletter' from the winter of 92/93 on making the choice between LabVIEW and LabWindows, and they boil down to the point(s) made by m3nth: preferred programming methodology.

[UKnowWhat]

I found myself evaluating this same question a long time ago.

You're right, they kind of do the same things.  It just depends on your needs and resources as to which you might choose. 

...

Thank you for so succinctly explaining the differences. You just put into words what I have felt about the 2 products. I have intuitively thought that LabWindows is the way to go because of the flexibility in adding third party codes. And yes, you also right about throwing enough time and money into a problem will make either solution would work. The only difference is one elegantly works and the other is like a stuffed pig.

Thanks again.

[Barrie]

  It can also be extremely difficult to upgrade in the future if someone makes a project that's their first project and then leaves it be for several years.  The problem is that people usually do that with not enough time and not enough experience and their coding style and archictecture is horrible.  Just because LabVIEW is graphical doesn't mean it's self documenting in the slightest (in my experience, that's the furthest thing from the truth).  So be careful if you're giving this to someone as their first project and you or they decide to use LabVIEW.  Make sure they get trained--send them to the NI training if necessary which is really good, both basic and intermediate.  Make sure their coding style is going to be readable and usable by someone else with LabVIEW experience.  Make sure they're going to use a flexible archictecture which will allow for future upgrades, and more or less, make sure there is someone else to audit their programming.

5761[/snapback]

While all of the above can be true and does provide some good advice, it is irrelevant at best and misleading at worst. As I understand it, this thread addresses LabVIEW vs. LabWindows, and the above statements apply to every software project ever attempted, regardless of the language or methodology.

While I would not be foolish enought to suggest that LabVIEW is self-documenting, there are inherent procedures and structures that are an intrinsic part of the language. This can not be said for "C". With "C" you have more of an opportunity for a "free-for-all" because "C" is not much more than an assembler with delusions of grandeur. The quality of the code is almost entirely dependent on the skill, experience, organization and discipline of the programmer. It also forces the programmer to address issues that, frankly, I don't believe belong in a language in the 21st century.

Now, before the flame wars start, assembler and low level languages are fine or even ideal, for many applications. I have probably spent as many hours coding assembler as I have LabVIEW. That said, the difference in productivity is astronomical.

Comments in this thread imply that the choice between the two products is whether to "C" or not to "C", but I see it as a decision of How Much "C" you wish to use. There is nothing to stop you from using "C" inside LabVIEW, and you also have access to many high level functions that allow you to put together a rich application in minimal time. I should also mention that the final execution speeds are comparable.

The summation: "The only difference is one elegantly works and the other is like a stuffed pig." made me smile because it is a gross oversimplification that shows no real understanding of the differences but it does afford you the opportunity to justify your own preconceptions and biases. As I stated above, to conclude that something that relies on "C" is inherently elegant is nothing short of ludicrous. After all, the quality and productivity of the final code is the goal, isn't it?

LabVIEW, LabWindows, "C", Java et al are all just tools that could be in your toolbox. I try to keep a good selection for different jobs, but if all you have is a hammer, everything starts to look like a nail.

[UKnowWhat]

While all of the above can be true and does provide some good advice, it is irrelevant at best and misleading at worst. As I understand it, this thread addresses LabVIEW vs. LabWindows, and the above statements apply to every software project ever attempted, regardless of the language or methodology.

...

The summation: "The only difference is one elegantly works and the other is like a stuffed pig." made me smile because it is a gross oversimplification that shows no real understanding of the differences but it does afford you the opportunity to justify your own preconceptions and biases. As I stated above, to conclude that something that relies on "C" is inherently elegant is nothing short of ludicrous. After all, the quality and productivity of the final code is the goal, isn't it?

LabVIEW, LabWindows, "C", Java et al are all just tools that could be in your toolbox. I try to keep a good selection for different jobs, but if all you have is a hammer, everything starts to look like a nail.

5769[/snapback]

1) In general, if all things are equal, your first statement is true. I just ignore that part because anyone has ever seriously code something in their life for a living would come to that conclusion, one way or another. I just don't bother to argue about something outside of my issues when I ask for people's opinion on something else.

2) You read too much and assume too much in one single line. My statement , quoted by you, applies equally to all products but your assumption (your preconception and bias?) carries it into your own world. Labview could elegantly works and LabWindows could be a stuff pig or vice versa. It all depends on how it fits into our needs and the cost associates with the product ie. learning curve, ability to incorporate with other 3rd party codes etc. With ZERO understanding in our organization, our strength, weakness and our needs, you have already bloat some strong opinions based on your assumption. Of course, with a strong background in C & C++ programming language and environment, we are definitely bias toward applying our strength in such environment, especially those with math intensive codes. However, we also have a short term turn around cycle for quite a few products, which I wonder whether Labview could fit nicely or not. With my understanding of our organization, I have to make a compromise somewhere to have a single platform, so yes, we do use hammer for everything, provided 80+% of our job is involved with nail. The rest of those things can be flat a bit but that's the penalty we have to accept.

[Barrie]

2) You read too much and assume too much in one single line. My statement , quoted by you, applies equally to all products but your assumption (your preconception and bias?) carries it into your own world. Labview could elegantly works and LabWindows could be a stuff pig or vice versa.

.........

However, we also have a short term turn around cycle for quite a few products, which I wonder whether  Labview could fit nicely or not. With my understanding of our organization, I have to make a compromise somewhere to have a single platform, so yes, we do use hammer for everything, provided  80+% of our job is involved with nail. The rest of those things can be flat a bit but that's the penalty we have to accept.

5774[/snapback]

Thanks for the clarification. As for reading too much or assuming too much, I must say your original conclusion seemed pretty definitive to me.

.......

Potentially, LabVIEW could fit, but that depends as much on the culture of your organization as it does on your skill sets. LabVIEW is an excellent tool for rapid prototyping. That is not to say the final product is all chewing gum and duct tape, as the product has become more sophisticated, it is very worthy of large applications. It also enables you to produce a large amount of eye candy which leads people to assume that the app is 90% completed even though the underlying code may be a long way off. I mention this because some management types see what they want to see, no matter how many times you underscore the total work involved and it can bite you bad. :headbang:

As a development environment, the graphical approach works very well for me. I find it very intuitive, but I knew how to read a schematic long before I knew how to code, or even run a computer. Similarly, debugging is also very intuitive, but that may be due to my experience with a 'scope and a multimeter. Curiously, I have also found that if a VI draws well, it will probably run well. If my VI devolves into a rat's nest, that's a huge warning that I haven't fully thought through my approach and need to backtrack before I get myself in too deep. I intend to run a poll here regarding people's backgrounds, i.e. hardware/software, but I am waiting for the new version of Invision.

Some people transition well between graphical and text programming, others definitely do not. Some programmers dismiss LabVIEW as "cute". I have seen otherwise intelligent people tell me that "real" programmers only use C, but that's their problem.

Besides the obvious interface differences, LabVIEW uses the dataflow paradigm, which is inherently multithreaded. Hyperthreading and multicore/multiprocessors extend this capability naturally. Priorities, scheduling and threads are easily implemented and modified. In other words, it's more than just a pretty face. The sub-vi function encourages modularity, structure and reusability and yet graphically shows that function as in-line code for the big picture. The sub-VI intrinsically provides all the interface for testing the code as stand-alone without the need to add, then delete or comment out test code and printf statements. Compiling and linking is totally transparent, but this may now be the case for text based environments as well. All that said, undisciplined or inexperienced wireworkers can produce spaghetti code in the truest sense of the word, as has been discussed on this forum. Like any other tool, you need to know how to use it to reap the benefits.

As you said very well, it all comes down to compromises and fits.

I hope this helps,

Barrie

[Michael Aivaliotis]

beside the obvious that one is a graphical language and other is text based. We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. What would be the ideal platform to do the job described above? Why would NI build 2 products when one can do the job so it must be something in it to differentiate the 2 products, right? TIA.

5750[/snapback]

I'd love to answer this question intelligently but I don't think you've given me enough information. Yes, one is text based and the other is graphical. You state the following: We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. I've done that using LabVIEW. I've also done dozens of other applications in various industries, So? What hardware will you be using? NI or another vendor? Do you or any of your employees have programming experience? In what language? Do you have software engineers in-house or will you subcontract out?

The main reason for the LabWindows product is to tap into the C programmer market. Those hard-core developers that refuse to use LabVIEW but are fluent in text-based programming.

[UKnowWhat]

I'd love to answer this question intelligently but I don't think you've given me enough information. Yes, one is text based and the other is graphical. You state the following: We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. I've done that using LabVIEW. I've also done dozens of other applications in various industries, So? What hardware will you be using? NI or another vendor? Do you or any of your employees have programming experience? In what language? Do you have software engineers in-house or will you subcontract out? 

 

The main reason for the LabWindows product is to tap into the C programmer market. Those hard-core developers that refuse to use LabVIEW but are fluent in text-based programming.

5782[/snapback]

The right kind of man asks the right kind of questions :thumbup:

1) DAQ & GPIB mainly NI. Vector network analyzer, power meter and sweep synthesizers are mainly HP. Source meters & switch box mainly Keithly.

2) Post processing imported from network analyzer or DAQ to further processed in PC, typical parameters in data sheet such as IP3, noise figure etc

3) The most common task we encounter is device characterization and it covers broad spectrum of ICs. The test operators have minimum knowledge of everything, except push the button, or click the mouse to be exact.

4) We have few software engineers in house and are strongly C & C++ oriented. I have 20 plus years in C programming and assembly language, in embedded system, test and measurement lately. Since I am also the hardware guy, if the load is too much to for me to handle, subcontract is also another option.

My concern is this: ease in programming with relative low learning curve and the ability to adapt to 3rd party developer, especially in DSP areas and RF which have intensive mathlab applications. Consider our background, it's a natural tendency to lean toward LabWindows but Josep Travis's ATE implementation in Labview just piques my curiosity.

[Yair]

you can't do easy compares on the code since it's graphical, and other issues like that (such as the fact that files are tens to hundreds of k's, instead of small text files, and that no two compiles of identical code turn out identical executables).

5761[/snapback]

Just some minor nitpicking, not disagreements - I don't know about SCC, but LV has a built in comparison option, at least on a single VI level. The files are tens of Ks, because unlike the small text files, they also include the front panel and the compiled code, which allows each VI to be fully executable by itself. As far as I know, the building into an executable produces different code because the builder adds some information to the file (date\time and such). I don't think it affects the building of the executable code.

The problem is that people usually do that with not enough time and not enough experience and their coding style and archictecture is horrible.

[Michael Aivaliotis]

The right kind of man asks the right kind of questions :thumbup: 

1) DAQ & GPIB mainly NI. Vector network analyzer, power meter and sweep synthesizers are mainly HP. Source meters & switch box mainly Keithly.

2) Post processing imported from network analyzer or DAQ to further processed in PC, typical parameters in data sheet such as IP3, noise figure etc

3) The most common task we encounter is device characterization and it covers broad spectrum of ICs. The test operators have minimum knowledge of everything, except push the button, or click the mouse to be exact.

4) We have few software engineers in house and are strongly C & C++ oriented. I have 20 plus years in C programming and assembly language, in embedded system, test and measurement lately. Since I am also the hardware guy, if the load is too much to for me to handle, subcontract is also another option.

My concern is this: ease in programming with relative low learning curve and the ability to adapt to 3rd party developer, especially in DSP areas and RF which have intensive mathlab applications. Consider our background, it's a natural tendency to lean toward LabWindows but Josep Travis's ATE implementation in Labview just piques my curiosity.

5789[/snapback]

Yes, this is good. Just to be blunt about it, I would recommend LabWindows. I've developed my own test executive to handle various RF measurements in LV and it wasn't easy. I only manged it because I had 10 years of LV and RF testing experience under my belt. BTW, RF formulas don't translate well to LV primitives. The nice thing though is that all the LV primitives work on complex numbers. They're polymorphic that way. I even managed to build a full 12-term 2port calibration routine in pure G.

In any case, it sounds like C is your forte so stick with it. With LabWindows, you get the nice compatibility with the NI hardware, the many GPIB IVI drivers and the user interface tools which give you graphs and other instrumentation type goodies. Have you considered test-stand? It will help get you started on the test executive which you won't have to build from scratch.

The only bad thing about going with LabWindows is we won't get to see you on the forums.

[Michael Aivaliotis]

I do agree that an LV diagram is not automatically self documenting and that experience and style counts a lot. In my opinion, a diagram is much easier to grasp in a single look than a block of text (even one with indentation)

5791[/snapback]

Oh god, if only I could post the diagram of some code I had to review and evaluate lately. It made me want to take a hammer to my laptop (it's a very nice laptop, btw). The chaotic mess was burned into my retina. I had to watch Britney Spears videos for hours just to wipe away the images from my brain. I thought to myself, God almighty! Is it really possible that there are such bad LV programmers out there?

Picture this... Suppose someone asked you to write LV program, and the only way you could pass data around was via the "value" property and using ctrl references. Now you get the picture.

So when you say you can easily figure out LV code quicker than C code, think again. You'd be surprised.

[Yair]

I thought to myself, God almighty! Is it really possible that there are such bad LV programmers out there?

5811[/snapback]

Yes, for the exact reason I mentioned before. People think it's "programming for non-programmers" so they just go ahead and do it. I know what you mean about bad diagrams (and FPs).

Picture this... Suppose someone asked you to write LV program, and the only way you could pass data around was via the "value" property and using ctrl references. Now you get the picture.

I never could figure out how so many new users manage to find the Value property before they find local variables. I see that very often users use it extensively (usually without refs, because they don't know what they are), and have the terminal put somewhere on the side. I have no idea how people can read such code, with wires going to the left, overlapping objects and so on. Then again, I never could figure out why certain members of my family have a tendency to leave a mess whereever they are when tidying up the room takes about 30 secs.

So when you say you can easily figure out LV code quicker than C code, think again. You'd be surprised.

I'm sorry, you're right. I should have said "a properly written diagram is much easier to grasp in a single look..." and I still consider this to be true, as I'm sure you do. The color coding and the fact that you can clearly see structures really help when you look at large piece of code (more than 6 or so nodes).

This doesn't negate my previous claims about documentation. I still think that it's preferable to read a comment that tells you what the code does than to start figuring out by reading the code. This also helps when debugging, reviewing or modifying the system later, because you know what the programmer intended for the code to do.

[UKnowWhat]

... I've developed my own test executive to handle various RF measurements in LV and it wasn't easy. I only manged it because I had 10 years of LV and RF testing experience under my belt. BTW, RF formulas don't translate well to LV primitives. The nice thing though is that all the LV primitives work on complex numbers. They're polymorphic that way. I even managed to build a full 12-term 2port calibration routine in pure G.

...

5810[/snapback]

That's what I thought when I look at the graphical representation of LabView. I was asking myself how do I implement RF formulas into this mess. With LabWindows, I know automatically the process would be much "simpler" and much intuitive for us than LabViews, considering your comments of 10 years of LV comparing to us NONE. LabView in my case will be transformed to a stuffed pig and it's not due to Labiew, but due to my inability to making the right choice at the first place.

I even managed to build a full 12-term 2port calibration routine in pure G.

5810[/snapback]

I've already pictured myself breaking my computer if using LabView.

Thank you, you guys for answering my questions, especially inputs from MA - I would definitely take a look at test stand.

Lanny