LabVIEW better than VB?

[Joe_Guo]

No one has claimed that VB does not require runtime engine, but comparing with the exploding NI runtime engine. It is a fact that VB program is a lot of easier to distribute. Also, how many of your programs are running on both Mac and windows? Labview is great and I love it but that doesn't mean it is better than other application in every aspect.

[rolfk]

---

@Joe Guo wrote:
No one has claimed that VB does not require runtime engine, but comparing with the exploding NI runtime engine. It is a fact that VB program is a lot of easier to distribute.

---

Well, if you build an exectuable in the application builder for Windows you can always select to create a distribution kit as well and then you have a single setup.exe file with four or so support files which take care of everything to get the application installed on any supported system and properly registered.

---

Also, how many of your programs are running on both Mac and windows? Labview is great and I love it but that doesn't mean it is better than other application in every aspect.

---

In fact I have quite a few applications I have written for both Windows and Linux in LabVIEW. The Mac is not currently in the plattforms I actively use, although there is a guy or two here who do that too.

Rolf Kalbermatter

[shoneill]

I'm not sure the main attractiveness of multi.OS compatibility is neccessarily having a single application running on zillions of OSes. It simply enhances tha already great code-reuse capability of LabVIEW. If you need to write an App for Mac in a couple of years, you can call up all (or at least most) of the code you've been working with under Windows/Linux/??. This saves time and money, and is less prone to programming bugs assuming the original software has already been properly tested.


At least that's how I would see it.

Shane.

[Martin.D]

For me multi.OS capability and distribution with LabVIEW runtime is not an issue. We supply OEM machines with the software pre-installed. And an installation disk for recovery purposes. Our customer uses VB6, but what about VB.net on older OS systems - the whole of the .net frame work must be distributed as far as I'm aware. This is now automatically installed with XP, I guess the fact that Microsoft can ship anything with there OS gives them an unfair advantage.

Although I would not know how to implement synchronised parallel software loops in VB, I think it's possible - I suspect that it's a bit of a headache. For my current application I must continuously: monitor DIO lines, service 2 x motion systems, service user interfaces, and perform image analysis. I guess a good VB guy could deal with this but it's probably an area where Labview provides advantages, especially 7.1.

One thing in favor of VB - the customer asked how much it would cost purchase LabVIEW for themselves!

I guess I'm not going to find what I originally set out for - a sentence or two that goes some way to convincing management that LabVIEW is the best tool for the job. I suppose it mainly depends on the developers skills at the end of the day, most main stream programming languages are capable of producing a similar end result with varying complexity that is largely transparent to management. Personally one reason I choose LabVIEW is because I find it much easier to understand the code, so when I push software to my limit of complexity I can achieve more. I guess a more intelligent guy with a more complex tool can achieve the same, but they are probably running with a handicap.

Martin

[Ray.R]

---

@Martin.D wrote:

One thing in favor of VB - the customer asked how much it would cost purchase LabVIEW for themselves!

---

While the initial cost for the tool has a major impact in the decision-making process, one must not forget the development costs which can far exceed the cost of the tool..  I hope NI doesn't read this and increase their prices... 😉

One critical aspect is the time to deploy the solution.  Is it worth while to invest in LV (even the basic version) and hire someone with experience?  As compared to inexpensive tools with little or no support and then hire a novice to implement the solution?  I've seen both worlds..  And for some strange reasons, whoever decided to go with the more economical solution will blame others when (not if) things go wrong.    I'm not on a mission to sell LV, but if you look at this forum, plus the support from NI and the ease & flexibility to use the tool, then LabVIEW is a pretty good deal for the $$$..

This may not answer the question of which is better: LV or VB, but what gets the job done faster. (and easier to support in the future, and possibly save $$ in the long run).

JLV

[minnellac]

While we're on the subject. Does anyone have any experience with the performance of LV vs. VB? I've been working under the assumption that heavy duty processing (e.g., image processing or spectral analysis) would be slower when executed with VB, but I don't have any direct experience in that area. Maybe someone can clarify. I guess it may just depend on the quality of the analysis libraries, but that is worth discussing.

We have a fairly large application that was originally written in VB and used Matlab (through COM) to perform all the heavy lifting. It is currently being re-written totally in VB to eliminate the licensing fees, but there was a discussion about moving it over to LV. btw, I am familiar with using compiled Matlab DLL's, but we didn't want to go that way with this project.

Chris