LabView vs LabWindows/CVI

[JÞB]

---

@jyce wrote:

But what happen with LV, if you design a VI with LV2010, install the run time for 2010 on the production computer. Does it means that you have to recompile your VI for the 2030 run time engine ? or you never upgrade your IDE ? stick to 2010 for 30 years ?

---

Actually, LabVIEW 2010 and on will not have an issue with this and it's one of the great improvements that was just made.  Object Only code

.

[maxwellb]

---

@tbob wrote:

You don't ever have to upgrade.  30 years from now you can still use LV 2010.  I know one companiy that is still using 5.1.1 to this day and they are doing fine.  You can have several LV versions on your PC at one time.  But I'm not sure how it works if you run an older VI on a PC that has several versions on it, how does it pick the correct runtime library.  I think you have to manually open the old LV version then run the old code.  Maybe someone can answer this one.

---

This is far too optimistic. I recently had the joy of trying to interface with a PXI card that I thought was 10 years old. It turns out that it's newer than that, which has solved my problems.

It is correct to say that you can have multiple versions of LabVIEW running on a computer without interfering with each other. However, your LabVIEW version window will be restricted by your operating system. I installed back to LV 7.0 on a Windows XP machine with no apparent problems. However, I wouldn't necessarily expect that I could go back to 5.1 on XP, or use 7.0 on Windows 7.

And it is extremely likely that you will run into driver problems if you try to interface with hardware across multiple LV versions. For example, LV 2010 requires SCOPE 3.6.2 and Traditional NI-DAQ 7.4.4, but a PXI-5112 Rev A card requires SCOPE 1.6 and Traditional NI-DAQ 6.8 (vintage 2000). You cannot have multiple versions of Traditional NI-DAQ or SCOPE installed on the same machine, and as I never got the card to work, I am not sure that those drivers installed successfully on my XP machine. They were only rated for Win 2000.

I would not consider sticking with one version of LabVIEW for as few as 10 years a satisfactory option UNLESS I planned to leave all hardware and software involved in the immediate system exactly the same.

[querty999]

Here's my perspective on the LabVIEW vs CVI debate.

Job postings don't provide a good metric for comparing CVI vs LabVIEW demand. Companies using CVI can find employees by advertising for C programmers. C programmers quickly become proficient in CVI.

Companies using LabVIEW have a smaller pool of eligible applicants. They have to advertise specifically for LabVIEW programmers. This tends to skew the results of a keyword search away from CVI.

As a C programmer I find LabVIEW hard to comprehend. Easy programs fall out quickly. But as task difficulty increases linearly LabVIEW programming difficulty increases exponentially.

To estimate of the difficulty of a subject I consider the number of books available. More books suggest a more difficult subject. There are lots of LabVIEW books. CVI has none. CVI books aren't needed. I started with the introductory material that comes with CVI and haven't looked back. In contrast I find myself studying LabVIEW itself almost as much as I do actual programming.

My conclusion is that LabVIEW is great for people who got burned in a programming class somewhere in their past. I see people invest tons of time learning LabVIEW just to avoid writing a line code.There must be a phobia about text based programming. I wonder if it has a name.

I like being able to print out programs so I can can go sit in a comfortable chair and ponder my code. Or carry it to a co-worker to talk it over. That doesn't work well with LabVIEW.

Reading text-based programs is like reading a book. You start at the top of a page and read to bottom. In contrast, it's hard to track the sequence of events in LabVIEW with wires going in so many directions.

I find myself constantly hoving over VI symbols so I can read the context help. The cryptic symbols on the programming elements don't suggest what they do very well. In C you can make function names as descriptive as needed. Comments are also easy to mix in as needed. I use so many comments a non-programmer can usually follow along.

Here's the only negative I can think of about CVI, you have to know how to program in C. But it really ain't that hard. And once you know it you can use it in many environments. Almost every control systems vendor has a C interface. LabVIEW is certainly a good skill to have but why limit yourself when you don't need to. CVI works just fine.

I hope this perspective adds constructively to the ideas expressed by others.

[jyce]

I Do like your straight forward comment. I also believe that you gonna have some new ennemy after it 🙂

I spent quit some time study it. I have a tendancy to think that LV is particuly adapted when you have to design small simple tasks.

Especially if they requires filtering, image processing, or this kind of stuff. I aslo greatly appreciate an add one like the report generator that provide easy direct access to excel. I did design a C+ wrapper to control excel and that was not the most fun thing i has ever done. But i've never been a big Active X fan....

If i had to design a large program requiring real time scheduling, synchronization, multi-tasks and so on and so on. I feel like sticking to a C environment is fare safer.

Of course this is only an opinion from a LV beginner but and advanced C/C++ designer.

[RayFarmer]

Hi,

Not sure where you were looking for CVI books but a quick search at Amazon came up with a couple

Also I disagree with your comment regarding the number of books available linked to difficulty of the subject, it more likely down to the wider user list.

[LV_Pro]

To a few of your points:

There are few, if any, CVI books because as you point out, it is basically programming in C, for which there are thousands of books.

Read text based programming from top to bottom, are they doing procedure/function calls? Is it single threaded? The last time I had to follow a C/C++ program I had to printout a ream of paper to have all the "pieces" in one place. And a properly written LabVIEW program shouldn't have "wires going in so many directions".

And yes, you can have descriptive names for functions, but I have seens some horrible, cryptic ones as well in C. And you can name your sub-VI anything up to the limit of the OS naming convention. No you can't fit that in the little icon, to be readable it would have to be a big icon for legibility, but you can "hover" over it to get a better idea, particularly if the programmer has filled out the documentation.

I could counter your "phobia of text based programming" with an observed "phobia of graphic programming". For 18 years I have had text programmers joke that LabVIEW was "a video game", "not a programming language", etc. It is different. As to me, I hate to type! And am a very visually oriented person. I wrote hundreds of thousands of lines of code in text languages, and can even now call up a mental image of some of it when pressed to, but I can "picture" my LabVIEW code so much easier. Just different, not necessarily better, just like some people are tone deaf, others have perfect pitch, the wiring of our brains is similar, but not the same.

"You have to know how to program in C. It really ain't that hard" It is to do good structured programs, just as it "ain't that hard" to program the basics in LabVIEW, but to develop a complex program it also takes some learning. Yes, the learning curve looks shallow at first, but gets pretty steep quickly, but that is true of most programming.

I have been programming professionally for almost 40 years, Fortran IV through Fortran 2000, C/C++, Pascal, Atlas, APL (there is one that is hard at first, easier later, unreadable by anyone other than an APL programmer!), Basic, HP-Basic, Visual Basic, and ... LabVIEW. Yes the shift to LabVIEW initially made my head hurt, I think it was using a different portion of my brain (more of the visual cortex), but now I sometimes even have dreams in LabVIEW (or rather LabVIEW in my dreams) when trying to solve a particularly knotty problem. The bottom line is that any language has a learning curve, the real problem is understanding how to decompose the problem to solve it programmatically.

As to the long term support issues ... Even as a VERY strong proponent of LabVIEW (it is how I make my living) it is a thorny issue. I'm not sure how to support hardware for 30 years either, but since I'll be very old (hopefully) in 30 years ...

[maxwellb]

"Reading text-based programs is like reading a book. You start at the top of a page and read to bottom. In contrast, it's hard to track the sequence of events in LabVIEW with wires going in so many directions."

What makes a LabVIEW program more difficult to read than a text-based program is that many things can happen at the same time. What querty is referring to here by "wires going in so many directions" is called PARALLEL PROCESSING. Usually considering a feature, not a bug. If you write a LabVIEW program that doesn't do anything in parallel, it is just as easy to read as a text-based program.

Also, if you think reading a highly parallel LabVIEW program is difficult, try monitoring a text-based program in operation. To me, the strongest aspect of LabVIEW is the ease of debugging. In the text-based world, a feature like LabVIEW's "highlight execution" button is inconcievable.

[tbob]

I have written programs in various forms of BASIC, Fortran, Pascal, Unix shell, C, C++, LabView, CVI, and HPVEE.  I do not have a phobia for text based languages or for writing text.  I fell in love with Labview because the graphical nature made it so easy to see what is happening.  Even with wires going everywhere, which a good programmer would not do, it is still much easier to follow than to pour through subroutine after subroutine which could be separated by hundreds of lines of code.  It is not top to bottom reading when subroutines are involved.  I recenlty had to review a CVI program.  There were subroutines buried 10 levels deep.  There were about 20 tabs with code written in each tab.  I had to use the find utility to find each subroutine, involving having to go through each line in the find results to get to the actual code.

You can keep CVI or C.  I'm very happy with Labview.

[RayFarmer]

As these forums regularly show, it doesn't matter what programming language you use you can still write crap code.

[altenbach]

Here's another analogy showing the differences between graphical and text based instructions.

When give the choice of using the left or right pane exclusively to go from point A to point B, I would strongly prefer the graphical representation on the right. If you miss one step on the left, you're lost in the swamp without easy recovery. On the right, it is much easier to find an alternative route in case of traffic or road closures.