Labview vs. Visual Basic

[Alfa_Patrick]

Currently we're trying to develop a new testing system to replace the older version that interfaces labview with older instruments. The new system will be mainly GPIB interface and the instruments are the top of the line Keithley instruments. There are conflicting opinions among the developers here as to use VB or LabView to control these instruments. Personally I favor LabView because it's designed to do this and it also offers very nice front panel user interface that VB lacks. I did a little bit of research and found the you could use component works from NI to simulate LabView user interface. However, the interfaces are limited and they don't look as nice as Labview's. The VB experts on the team, however, think that VB would r
un faster and more efficiently than LabView especially that the database for the system was written in VB. Another point given was that VB has a better, structured code layout than LabVIEW. I admit that following LabView back panel codes can be very challenging at times, but I don't think that VB is any easier if you don't know VB all that well. So which would do the job better considering that we need:

1) User friendly interfaces (also nice looking)
2) Fast data transfer to the database
3) Efficient control of the GPIB instruments
4) Reuseability and readability of codes for future developers
5) Prices (NI stuff tends to be more expensive that other generic brands)

All the developers here are pretty flexible as to what to use, but we do need good arguments as which are really better.

[Rob Cole]

Having programmed in both, I would choose LabVIEW for anything with instrument control. LabVIEW 6 builds smaller, faster code than LabVIEW 5 (which was faster than its predecessor, etc). It has gotten to the point where execution speed is little different between VB and LabVIEW.

If you build using OOP in LabVIEW, the program is quite readable. My programs consist of a few sub VI's that are clearly labeled. My biggest program so far is just 7 VI icons that are labelled Initialize Variables, Check Run Time Menu, Check for Button Press, etc. I'm sure you get the idea. Each of the sub VI's breaks down in similar fashion. Very readable code and the lowest levels do very specific tasks, making debugging much easier.

I have found little that VB could do that LabVIEW could
not and vice versa. It comes down to what you're familiar with and can turn out the program in most efficiently. If everyone knows VB and would have to learn LabVIEW, it would be better to program in VB (unless you want the learning experience and the broadening of your employable skills).

Rob

[Mikael_Garcia]

I fully agree with what Rob said and I would also choose LabVIEW over Visual Basic for instrument control. However, let me address your question about reuseability for future developers.

If you are developing a large application in LabVIEW and later you decide to add new features to your program that will require modification of some of your lower level VIs, you might have to spend more time doing this than what would have been the case with a text based language such as VB.

At the moment I am actually doing this type of work and I can give you an example of what I mean. Assume you have a function that has two inputs and one output f(a,b). You develop a VI for this function and your main program is using this VI in (as in my case) 28 different places. I use a 28-case st
ructure in my program. Later, you realize you need to add a third input parameter to your function so that the call now should be f(a,b,c) instead of f(a,b). This means that you have to manually wire this third input to your VI in the 28 places in your main program. This can be very time consuming. With a text based language you could have used the standard "Find-Replace" text function and the task would have been solved in a matter of seconds.

In my opinion LabVIEW is a very powerful tool but, at the moment, maintaining applications can sometimes require a bigger effort than one would expect. However, I think LabVIEW comes second to none despite this drawback. /Mikael

[Dennis_Knutson]

I never found VB code that structured with some code part of a form and other code in separate modules .etc, and I doubt there would be much difference in execution speed. Database read/writes in LabVIEW use the ADO/ODBC interface which I think is the same as what VB uses. The same is true of GPIB communication. They'll both use the same VISA dll in all likelihood. One of the biggest differences in my opinion is that I think development in LabVIEW is significantly faster. Another consideration is the portability and backward compatability of LabVIEW. For the most part, LabVIEW upgrades have been mostly painless. I can't say the say about my VB experiences.

[kennett]

Currently I'm evolved with trying to convince Management that Automating our Eng-Lab and parts of the production floor utilizing more LabView VI's for test tooling is in our best interest. VB is used widely here, but I think this is a business killer due to the fact that VB is somewhat going away (archaic) and LabView is a proved platform for over 25 years and has become an industry standard and is updated every year in addition to having great developing support. I have experienced that (in some cases) you can teach basic LabView programming where at least for me VB you could not do this so easily. I'm looking for a convincing argument here from folks who have some experience in this area. I have a meeting next Monday to present my case. 

[altenbach]

---

@kennett wrote:

Currently I'm evolved with trying to convince Management that Automating our Eng-Lab and parts of the production floor utilizing more LabView VI's for test tooling is in our best interest. VB is used widely here, but I think this is a business killer due to the fact that VB is somewhat going away (archaic) and LabView is a proved platform for over 25 years and has become an industry standard and is updated every year in addition to having great developing support. I have experienced that (in some cases) you can teach basic LabView programming where at least for me VB you could not do this so easily. I'm looking for a convincing argument here from folks who have some experience in this area. I have a meeting next Monday to present my case. 

---

For those who don't have 20/20 vision, here's a repeat in a slightly larger font:

"Currently I'm evolved with trying to convince Management that Automating our Eng-Lab and parts of the production floor utilizing more LabView VI's for test tooling is in our best interest. VB is used widely here, but I think this is a business killer due to the fact that VB is somewhat going away (archaic) and LabView is a proved platform for over 25 years and has become an industry standard and is updated every year in addition to having great developing support.

I have experienced that (in some cases) you can teach basic LabView programming where at least for me VB you could not do this so easily.

I'm looking for a convincing argument here from folks who have some experience in this area. I have a meeting next Monday to present my case."

[nyc_(is_out_of_here)]

With regards to Visual Basic, whether VB6 or VB.NET, it is most definitely not going away anytime soon.

There is a learning curve whether going from LabVIEW to VB or VB to LabVIEW.

If the engineers are not familiar with LabVIEW and will require training, one had better be sure that your management is willing to allow for that training to occur.

I program in both. Neither one is "easier" than the other.

[SunshineDesign]

I agree with NYC. I use both VB6 and Labview. I find both useful in their own way. I have 12 different hammers, but only one is right for a specific job. Same with VB and Labview. So I use what make sense from the support standpoint as that usually involves the most cost investment. I can do an automation task wheteher with instrument or not just as fast in either VB6 or Labview. I organize the project code similarily and write as Object Oriented as I can (object based as they call it in the VB6 world). My code is well organized, modularized and easy to work with and debug. I am in the same position with Labview. I only find signal processing easier in Labview than in VB6. I find folks who say one is better than the other usually have biases and opinions more meaningful to the argument than actual evidence.