LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

what are the disadvantages of labview?

Okay back to the original question a bit (yes I'm a fan, yes I have a career in LabVIEW), but some times it is important to be critical of your tools.

 

The closed nature of LabVIEW has to be one of its biggest disadvantages.  If you get a corrupt text file you can still read parts of the file.  If you get a corrupt VI you are likely screwed without SCC.  Here is where the closed file format can contribute to problems.  This can also mean that other platforms aren't supported, because the compiler doesn't support it.  No porting to a generic ARM, and no running LabVIEW code on an FPGA, that isn't an NI FPGA.  (mostly)  There are other related issues like...

 

Lack of text can be a problem.  Ever work on military contracts where they demand the source code in printed analog form?  How about when they ask how many lines of code it is?  FYI, answering with "zero" isn't always appreciated.  Sure you can write code to print block diagrams, and you can hand that over but it sorta defeats the intended purpose of having the source in a form that is universal because LabVIEW can't really do that well.

 

The stigma of not being a real programming language is a disadvantage.  I don't mind, I know what my livelihood is based on.  But new developers might see or hear this criticism, and choose to avoid LabVIEW on the opinions of others who aren't well informed on this subject.

Message 21 of 36
(2,371 Views)

MarkGrindell, in your post here, and your one other post, you try to make a point that programming artifacts in LabVIEW need to have "Front Panel representation". This is simply not the case, and it tells me that you are trying to use "variables" in the same sense that C and most other text based languages use variables. Your opinion of local variables reinforces this. It tells me that you are proficient in one of these languages, and want LabVIEW to behave and look like them. I think you are jumping in at page 500 and trying to skip the core concepts.

 

Also, substantiating your disdain for LabVEW by saying that there are "local variables scattered around the screen" is like saying you hate hamburgers because there's 92 pickles on them.

Richard






Message 22 of 36
(2,365 Views)

@Broken_Arrow wrote:

 


Also, substantiating your disdain for LabVEW by saying that there are "local variables scattered around the screen" is like saying you hate hamburgers because there's 92 pickles on them.


To be fair if I've never ate a hamburger before, and my first one came with 92 pickles, I might also say I hate hamburgers.

Message 23 of 36
(2,348 Views)

@Hooovahh wrote:

 

The stigma of not being a real programming language is a disadvantage.  I don't mind, I know what my livelihood is based on.  But new developers might see or hear this criticism, and choose to avoid LabVIEW on the opinions of others who aren't well informed on this subject.


I agree with this wholeheartedly.  One of the reasons I think it has this stigma kind of relates back to Mark's (and others) posts.  LabVIEW is presented as an easy to use quick tool - and it is!  The problem is that it is so easy to use that there are a huge number of "developers" working professionally that lack solid programming fundamentals... unit testing, modular design, code documentation, etc etc.  Of the developers I've worked with in industry a frightening number of them are woefully inept.

 

My only other major complaint is the lack of a stripped down runtime engine.  I often find myself writing simple programs for colleagues to do simple things that have no hardware interface.  10 minutes to write it, 5 minutes to compile... 20 minutes and a suggested reboot to install.

Message 24 of 36
(2,343 Views)

Since this old thread is being resurrected I'll chime in. I love using LabVIEW, and am increasingly using it for embedded (FPGA and Real-Time) and think it's a game changer. But there are some large disadvantages too:

 

1) No first-class support for any OS other than Windows. Windows is increasingly a general purpose operating system optimized for web browsing and document writing, and is entirely unsuitable IMO for engineering applications. Ironically LabVIEW is geared towards engineering applications but only offers full functionality using Windows. What I wouldn't give for a first-class LabVIEW that runs on (even limited flavors of) Linux but includes all functionality including DAQmx, Real-Time, FPGA, MAX, etc.

 

2) LabVIEW is very proprietary. I can't even mention it within the FOSS crowd, and that's a shame because I think that LabVIEW's dataflow implementation has some incredible advantages for embedded control applications. But many embedded developers are using open source toolchains (GCC, Eclipse, command line, etc) for good reasons, and would never consider paying for a closed-source development environment like LabVIEW.

 

3) Locked-down hardware supporting LabVIEW. I am a huge fan of the PXI, cRIO, and sbRIO platforms. But often I find myself at the wrong end of NI's business calculus (e.g. I need FlexRIO-like power and performance, but in an embedded and relatively small form-factor a la SOM). In the past we have simply built hardware that is optimized for our specific applications, but since switching to LabVIEW we are unable to use LabVIEW FPGA code on our own hardware and therefore are stuck to the products NI offers. Given NI's multi-year design cycle these products can be 3-5 years behind the state-of-the-art. (The upside is that NI's hardware is bar none. Some of their hardware designs are like fine works of art.)

 

4) NI can be a bit stubborn when it comes to LabVIEW updates. The IDE has needed a major overhaul for nearly a decade, but years later here we are with NXG that is still very limited in functionality and with a slow roll-out to boot. Along this same line there have been far too many good LabVIEW suggestions on the idea exchange that are rejected for years only to be sheepishly incorporated at a much later date (block diagram zoom, tabbed development, etc).

Message 25 of 36
(2,321 Views)

@Hooovahh wrote:

@Broken_Arrow wrote:

 


Also, substantiating your disdain for LabVEW by saying that there are "local variables scattered around the screen" is like saying you hate hamburgers because there's 92 pickles on them.


To be fair if I've never ate a hamburger before, and my first one came with 92 pickles, I might also say I hate hamburgers.


Ignoring the whole hamburger thing (at least for now), the whole issue concerning creating spaghetti code is one of lack of knowledge of "best LabVIEW programming practices".

 

In this example, if you knew best practices, you wouldn't have all those local variables.  Spaghetti code?  Just don't write it.  No backwards-running wires; wires with minimum bends; bundle where it makes sense; create subVIs to define functions or for code re-use.  One big LabVIEW disadvantage here is that it's much easier to align text than it is to align wires, terminals and nodes.  And since "clean" LabVIEW code is highly subjective, the cleanup button... well, let's just say that if the cleanup button makes your VI look cleaner, it's safe to say that you need to re-think your whole approach to LabVIEW programming.

 

92 pickles?  Ugh, heartburn city, here I come...

 

Not following those basic guidelines is like handing someone some text code where all the code is in main() and the code has random indents.  In either case, you haven't a clue about best practices.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 26 of 36
(2,309 Views)

@MarkGrindell wrote:

You have an application where there are local variables scattered around the screen.... You cannot have a small, simple local variable unless it's on the application screen.

...

Can any thing be done to remove the huge amount of clutter? (quoted from https://forums.ni.com/t5/LabVIEW/Typed-variables/m-p/3691708 )


Hi Mark,

 

From your descriptions, it sounds like the code you see suffers from excessive, unnecessary use of Local Variables. As others have mentioned in https://forums.ni.com/t5/LabVIEW/Typed-variables/m-p/3691708, the key to decluttering is to replace Local Variables with Dataflow.

 

Below is a simple example, which calculates the displacement of a simple rectilinear motion, s = u t + 0.5 a t2.

 

One approach to calculate s is to store intermediate values in variables:

Rectilinear Calc - Variables.png

 

The code is valid and produces correct results. However, but the front panel has gained 4 unnecessary controls/indicators to store intermediate values.

 

The better approach is to take advantage of Dataflow. Don't store intermediate values in Variables. Instead, wire the output of one node directly into the input of the next node: 

Rectilinear Calc - Dataflow.png

 

No Local Variables are required at all. Thus, your front panel is not cluttered. It only has 3 inputs (a, u, t) and 1 output (s).

 

Can you see how to use this principle to declutter your code? If not, please post an example so that we can better understand what you're dealing with.

Certified LabVIEW Developer
Message 27 of 36
(2,189 Views)

This thread is begging for a Rube Goldberg contest for the most convoluted code to achieve the simplest outcome...

 

That aside, I too feel like one of the greatest drawbacks is the stigma behind "graphical programming". That and the bulky runtime for simple applications.

 

LabVIEW has never been my job, but it has been a phenomenal utility along the way. Try doing an event structure with responsive graphs and controls in MATLAB (a comparable STEM package) and get back to us. I've spent the last 2 months evaluating alternative environments for "real programming for STEM" and the built in numerical and analysis functionality is phenomenal compared to "real" languages. MATLAB too provides a comprehensive STEM environment, but severely lacks on the UI functionality side.

Message 28 of 36
(2,153 Views)

.Great example!

 


JKSH wrote:

Rectilinear Calc - Variables.png

The code is valid and produces correct results. However, but the front panel has gained 4 unnecessary controls/indicators to store intermediate values..


Don't you wish now that you had voted for this idea! 😄

 


@JKSH wrote:
Thus, your front panel is not cluttered. It only has 3 inputs (a, u, t) and 1 output (s).

 

Can you see how to use this principle to declutter your code? If not, please post an example so that we can better understand what you're dealing with.


... and if this calculation needs to be done often and in several places, one would lasso the code and turn it into a subVI with 3 inputs and 1 output (there is a menu entry to do that!) and give it a nice icon. Now all we have left on the diagram is a "custom primitive". In newer LabVIEW versions, the subVI can even be set to be "inlined", eliminating the call overhead and completely de-cluttering the diagram of the main VI.

 

Your simplification reminds me of the old example to get rid of sequences and sequence locals. 😄

 

SeqStackedA     >>>>    seqFinal

0 Kudos
Message 29 of 36
(2,130 Views)

I can't think of too many disadvantages. Maybe the UI is a bit clunky at times, but mostly it is OK. The upfront cost could be a barrier to entry for some but, from a personal experience, the amount saved in not having to contract out SW development dwarves what we've paid out to NI. LabView is used extensively throughout the company I work for; LV practitioners, management and internal customers are very happy with the results.  

 

What I really like about LabView is that  I am able to communicate with cameras, motors, PLCs, databases and remote PCs without really knowing a great deal about any of the detail. It gives me the flexibility to control all aspects of our automated inspection systems from a single software platform.  

0 Kudos
Message 30 of 36
(2,117 Views)