LabView vs LabWindows/CVI

[LV_Pro]

Much of LabVIEW is currently written using LabVIEW. The fact that a part of the compiler is written in C++ doesn't change that. C++ was written using C, C using assembler for the first target.

As to LabVIEW not being suitable for large projects, much of the control hardware of the Large Hadron Collider is being controlled using LabVIEW.

You seem to imply in one of your posts, in response to Ben's joking question about software abomination, that someone is lying about LabVIEW? Whom? How are they lying?

[Ali65]

LHC is probably the best example where LabVIEW is "suitable"; a project with virtually unlimited amount of money to burn, a project where failure has no consequences. The worst case the Higgs boson is not found. And then what? Even more founding comes?

My visualization of the 

European Taxpayers:

 

[RavensFan]

---

@Ali65 wrote:

LHC is probably the best example where LabVIEW is "suitable"; a project with virtually unlimited amount of money to burn, a project where failure has no consequences. The worst case the Higgs boson is not found. And then what? Even more founding comes?

My visualization of the 

European Taxpayers:

---

Why are you still talking?

Please quit spamming the forums.  We don't need 1.5 MB pictures filling up our screens with your political opinions.

Just go away!

[altenbach]

Enough of the irrational ramblings! You have not contributed anything meaningful here. We're not interested. Really!

Earlier, I challenged you to shape up, but you failed miserably. Nobody takes you seriously here. You can do your trolling on any other forum, we are done here. Thanks! 🙂

Come to Austin in August and we'll talk face to face.

[JÞB]

---

@Ray Farmer wrote:

and another thing...why did Ben get a couple of Kudos.. is this some secret hand shake thing....

---

Yes.  Read a Profile now and then!

[querty999]

---

Take a look at that forum (linked by tbob) and then look a the LV forum. What you will find is that there is a lot more support for LV than CVI.

Ben

---

You are correct. The support requirment for LV is high compared to CVI. I tried using LV because of it's ease-of-use claim. After struggling with LV for a year or so I discovered CVI. Oh, what an improvement! Today I use LV for simple stuff. For more complicated stuff I use CVI.

I find that I don't need much support when using CVI. For me, it's much easier to comprehend than LV. The introductory document that comes with CVI was all I needed to get going. After that I never needed much ongoing support. In contrast, I have numerous books on LV. And yet I often get stuck in LV and have to call on the forum for help. Typically for things that aren't even mentioned in the books.

Speaking of books, you won't find many for CVI. They aren't necessary. There are only two CVI books in existence as far as I can tell. Both are very old and out of date (last updated in 2000/2001). On amazon.com, one book costs $300 (why so much? I dunno).  In contrast, there are pages of LV books listed on amazon. Why does LV require so much explanation and so many examples if it's so easy to use?

CVI seems like a red-headed step child in the family of NI products. I discovered it by accident. I never saw it advertised. At first I wondered why. But I now think I know the answer. The lock-in potential of LV is high. Once you invest the considerable effort to learn LV you're not likely to go elsewhere. You can't do anything with G-code skills accept LV. On the other hand, if you know C then you can quickly become productive in CVI and also work in other environments, not a good thing from an NI perspective. The biggest negative I see in using CVI is that NI might some day drop support because CVI is not in NI's business interest. I wouldn't be at all surprised to some day see the following statement from NI, "we have decided to discontinue CVI support due to lack of customer interest", even though it's not true.

[altenbach]

---

@querty999 wrote:

The support requirment for LV is high compared to CVI. 

---

An alternative explanation would be that CVI users are a small fringe group and most people use LabVIEW. 🙂

---

@querty999 wrote:
After struggling with LV for a year or so I discovered CVI. Oh, what an improvement! Today I use LV for simple stuff. For more complicated stuff I use CVI. 

---

Did you learn CVI from scratch or did you have prior experience with text based programming?

Preferences clearly differ and I respect your opinion.

I would never expect Van Gogh to have written "War and Peace" or Tolstoy to paint Starry Night.

OTOH, I am sure Leonardo Da Vinci would have loved LabVIEW. It is really hard to write CVI code in mirror-image cursive :o. 😄

[RayFarmer]

---

@altenbach wrote:

---

@querty999 wrote:

The support requirment for LV is high compared to CVI. 

---

An alternative explanation would be that CVI users are a small fringe group and most people use LabVIEW. 🙂

---

Or maybe there are less problems with using CVI

[belight]

Thanks for all the information.

I have been coding in Visual C++ environment for many years, now I am looking for something quick in development for a semi-conductor test chamber.  I prefer text programming over the graphical one, so I am thinking of using LabWindows/CVI.  However before I jump into it, I have a few questions:

1. Is there a run-time licence vs development one ?  If we sell thousands of chambers in the future, would I have to pay ~$2500 for each chamber ?

2. Once the codes in C/C++ I developed in LabWindows/CVI, I assume there are portable to Visual C++ or Visual C# in Windows, right ? and vise versa ?

3. Does the LabWindows support non-NI devices ?  For example, if I have a serial port through a PCI card in my desktop, and I bought the card from a store, I assume I can communicate to the ports using regular C codes inside LabWindows program, right ?

Thanks in advance,

Inchen

[smercurio_fc]

---

@belight wrote:

Thanks for all the information.

I have been coding in Visual C++ environment for many years, now I am looking for something quick in development for a semi-conductor test chamber.  I prefer text programming over the graphical one, so I am thinking of using LabWindows/CVI.  However before I jump into it, I have a few questions:

---

Leave the dark side! Join us in the light!

---

1. Is there a run-time licence vs development one ?  If we sell thousands of chambers in the future, would I have to pay ~$2500 for each chamber ?

---

LabWindows allows you to create an executable, just like LabVIEW. Like LabVIEW, there is a LabWindows Run-Time Engine that contains the required libraries. This will need to be installed on the target machines, but the Run-Time Engine is free. You only need to pay the license for the system that's used for development.

---

2. Once the codes in C/C++ I developed in LabWindows/CVI, I assume there are portable to Visual C++ or Visual C# in Windows, right ? and vise versa ?

---

Yes and no. LabWindows is ANSI C. However, it does have a bunch of libraries. If you were not using any of the libraries (or were just using standard C libraries) then the code would be portable. For example, you could write a simply "Hello, world" program and then bring it over to Visual C and compile it. However, C++ is not C, and C# is definitely not C. So, your question is somewhat ambiguous/meaningless in that respect.

---

3. Does the LabWindows support non-NI devices ?  For example, if I have a serial port through a PCI card in my desktop, and I bought the card from a store, I assume I can communicate to the ports using regular C codes inside LabWindows program, right ?

---

Again, yes and no. It's no different that if you were coding in Visual Studio. You need the libraries and DLLs. With respect to the serial interface, this is done through VISA, which is not specific to LabWindows. When you plug in that serial port card, it's recognized by the system and you get COM ports. MAX will see the COM ports. VISA will see the COM ports. So from that respect it doesn't care what kind of serial port card you bought, as long as you can see COM ports. With respect to other devices, such as data acquisition devices, then the vendor would need to supply the required libraries and DLLs.