What specific features of LabVIEW are frustrating to you?

Question

Please bear with me: this isn't a language debate or a flame. It's a real request for opinions.

Occasionally, I have to help educate a traditional text coder in how to think in LabVIEW (LV). Often during this process, I get to hear about how LV sucks. Rarely is this insight accompanied by rational observations other than "Language X is just so much better!". While this statement is satisfying to them, it doesn't help me understand what is frustrating them.

So, for those of you with LabVIEW and text language experience, what specific things about LV drive you nuts?

------ Summaries -------

Thanks for all the answers! Some of the issues are answered in the comments below, some exist on other sites, and some are just genuine problems with LV. In the spirit of the original question, I'm not going to try to answer all of these here: check LAVA or NI's website, and you'll be pleasantly surprised at how many of these things can be overcome.

• Unintentional concurrency
• No access to tradition text manipulation tools
• Binary-only source code control
• Difficult to branch and merge
• Too many open windows
• Text has cleaner/clearer/more expressive syntax
• Clean coding requires a lot of time and manipulation
• Large, difficult to access API/palette system
• Mouse required
• File namespacing: no duplicate files with the same name in memory
• LV objects are natively by-value only
• Requires dev environment to view code
• Lack of zoom
• Slow startup
• Memory pig
• "Giant" code is difficult to work with
• UI lockup is easy to do
• Trackpads and LV don't mix well
• String manipulation is graphically bloated
• Limited UI customization
• "Hidden" primitives (yes, these exist)
• Lack of official metaprogramming capability (not for much longer, though)

• Lack of unicode support

  [1]: http://www.lavag.org LAVA

Answer 1

I wrote a program (in C++) to control an rs232 device from a computer but was asked to provide a driver or Vi or whatever for labview. I downloaded labview with full confidence that I could bang something out in short order. (I am a comp sci graduate from an ivy school, have programmed in C++ for 15 years, learned and used C, Scheme, C#, Java, etc. - this should be a no-brainer)

I also downloaded a sample app and documentation for labview.

I was horrified at the outcome. Labview is HUGE, SLOW and non-intuitive. It follows none of the paradigms I am used to with either MFC or Visio or Rational Rose or VB, etc. Trying to find the right documentation was also a hard experience. There is just so much out there that one needs to have an understanding of Labview just to know where to begin.

It is a huge program that does so much. Without someone to show you how to use it is very difficult. I self-taught myself many things, but labview so far has eluded me. (granted I have not spent nearly as much time on it as i should, but it was a frustrating experience so far)

To summarize - it is huge, slow and non-intuitive. The docs are overwhelming.

(I still have high hopes one day to finish the project)

Answer 2

Labview is great for controlling hardware. I have written several Labview apps for collecting data (analog voltage from various sensors) and control hardware (mostly piezoelectric motors). Labview makes it fairly easy to perform several tasks in parallel.

Now to answer your question. What do I find frustrating about Labview.

1. Time spent organizing block diagram

   • moving wires around
   • organizing nodes

   Perhaps, since I am self taught I spend too much time trying to clean up wires and trying to follow them in an attempt to deciphers what data they are carrying and where it is going.

2. Point and clicking through the toolbox thing looking for the node/function that I want to place in the block diagram or front panel.

I should just be able to type the name of the function/method I need with the parameters and get going instead of...

"hmmm... I need the calculate RMS vi now where would that be? now I need an AND operation. OK back up to top level, to logical functions, which one of these is AND oh right it's that one. Drop on diagram wire it up and test! Well that only took 15 minutes!."

But there probably is a more efficient way to work with Labview, I just don't know it!

Answer 3

The thing I was most frustrated with was that it took my hands off the keyboard. I'm a touch typist, and can code fairly quickly in a text language. LabVIEW forces you to use the mouse to select VIs and program nodes from its menus, and to wire the nodes together. While this is really fast and convenient if you're an electrical engineer, used to designing circuits in a graphical environment, it's a pain if you're used to typing in your code.

---

Disclosure: It's been about two years now since I last used LabVIEW, so these next two may be fixed by now.

The next annoyance was source control. One of the things you do most often with your source control repository is diff your current version with a previous version to find the changes. You can't do that with a graphical language like LabVIEW. Popular revision control systems like CVS and SVN use text-based diff tools behind the scenes. I hope National Instruments has come up with their own revision control solution for all of you guys who are still using LabVIEW.

The last annoyance I had was a lack of real object-oriented language features. LabVIEW 6i, the last version I used, was object-based at best. No one could really make an accurate claim that it was object-oriented. I couldn't create a real class hierarchy using inheritance, and polymorphism was reserved for only a few built-in types. I realize that 6i was two versions ago, so I really hope that this is fixed.

Answer 4

Azim,

you will be happy with version 8.6 that has two features that attack your frustration:

• Auto Clean up diagram
  A tool to clean up cluttered code.
  However it is noted that this tool should not be used on clean code (LAVA and NI forums).
• Quick Drop
  A tool to select nodes and VIs by using keyboard shortcuts, a video on Youtube shows the quick drop in action. After 1:07 you see the Auto Clean Up tool.

Tim, What is that you mean by

Labview is HUGE, SLOW and non-intuitive

If you have examples and improvements please let it be known.
If you have troubles building a driver have a look at the shipped drivers (for a multimeter for instance). Try to find a similar instrument with a driver and adjust it as needed, I know for sure NI is willing to help you or others will. Come with your questions to LAVA or NI forums.
The different Paradigm that LabVIEW uses (data-flow) might be the solution to parallel programming (at least that is what NI tells us), Visio is not a programming languange, sorry to break the news. Using a beginners book (LabVIEW for everyone) is a very good start.

Ton

Answer 5

Not being able to zoom in and out of the block diagram. Yes, designs should be kept to a single screen or scrolled in only one direction but I've gotten code from 3rd party vendors who must be using 50 inch monitors to develop on -- the code goes on forever in every direction!

(23 Jan 2009): Use View->Navigation Window to see a bird's eye view of the entire diagram (front and diagram panels). This could be useful when LabVIEW decides to put a new control created from the block diagram in a random location on the front.

Answer 6

LabVIEW makes implementing concurrency/parallel programming easier, true. It does not, however, make debugging, testing, or thinking about concurrency/parallelism any easier. You can still write buggy, concurrent code in LabVIEW, and (as with any language, platform, or toolset) there's no silver bullet or magic wand that makes concurrency "just work".

If anything, you have to be more careful about concurrency, because if you don't think about (and declare) it explicitly, LabVIEW may make things concurrent that you weren't expecting to be.

Other beefs: It's not text. Representing dataflow in a way that makes sense means a graphical language, which means you can't use the tools that we've had for decades to manipulate text, everything from sed to emacs. It also means that source code control apps have to treat your code as opaque binaries, instead of as...source code. This, in turn, makes branching and merging an exercise in pain.

Answer 7

A clarification on LabVIEW's "graphical diffs":

LabVIEW cannot have multiple copies of a VI with the same name in memory simultaneously.

Until version 8.5, this meant that if I wanted to diff My VI.vi revision 2 against revision 1, I had to (manually) create a copy of it with a different name, open that, and then tell LabVIEW to compare it with my original.

My understanding is that they automated this process somewhat in 8.5, to give you a 3-way merge tool, of sorts.

Answer 8

I appreciate LabView in many ways, especially the ability to easily drive hardware (well, when it's National Instruments' hardware, of course), and the concurrent programming features. But is sucks against text-base programming languages in code navigation:

• when you browse the code, you end up with tons of opened windows, as you successively open subVis again and again
• because words are more expressive than icons, you see fewer instructions in one screen, compared to text languages, especially in expressive syntaxes, like python

Answer 9

One item above all others:

Lack of tools to do Test Driven Development

If I maybe glib for a moment, this is pretty big deal now a days since I don't goto the bathroom without writing a test.

EDIT:: I take it all back, check out http://forums.jkisoft.com/index.php?showtopic=973 . So far it works great!

Answer 10

Lack of Diff and Merge (except for "professional" license)

We use SVN and TortoiseSVN at work. I'm frustrated that I can't do a diff to see what has changed in a file. Doing "diffs" is part of the daily workflow when using SVN, so it's frustrating to see that a file has changed, but have no idea whether it was something trivial or substantial. Doing diffs also enables a systematic review of changes.

I hear "professional" has some sort of diff tool. I'll have trouble convincing management that we need professional for a "diff" feature though. And I haven't been able to read conclusively that it actually integrates smoothly with TortoiseSVN.

Use of source control is considered one of the industry best-practices, so it would be great for NI to fully support it, not just in the "professional" license, lest NI be seen to be inhibiting adoption of best-practices.

Answer 11

1.LabVIEW objects are not passed by reference.
2.No other viewer exist(especially free one) for viewing the block diagrams.
3. Need to open up a large number of windows to view a project. Would like it to be MDI so that number of windows gets reduced.

Answer 12

• Dozens of open windows is a definite pain.
• vi's that were edited by someone with a bigger monitor have to be resized.
• UI locks up temporarily when processing other stuff (maybe i havent figured out the multithreading potential of labview yet)
• editing on a laptop with a trackpad is horrible, (dont forget the small monitor issue).
• complex string manipulation takes acres of space (there is a function node for equations, why not a regex node for string manipulation?)
• i sometimes find primitive vi's in other peoples code that i cannot find anywhere in the menus.
• UI can only be customized to a point.

i would like to add that i think labview is remarkably powerful and well designed. very rarely do i run into something that makes me wish i had a different language.

Answer 13

A feature hole: there's no metaprogramming facilities to speak of, IIRC. It's great for building things, as long as whatever you're building is at the same level of abstraction that the LV designers thought you'd want.

Over the past 20 years, I've moved (generally) to higher and higher levels of abstraction. For about a year, LV was neat, because it was slightly higher than what I was using. Then I blew past it, and LV looks more antiquated every year.

Answer 14

Lack of Unicode support in the GUI

It makes development for our Japanese company difficult.

Update: there is some support in 8.6 apparently. See A List of Tips and Tools for using Unicode in LabVIEW.

Answer 15

Labview can be used to author large, complex software projects. Labview is unquestionably much more fun to use than a syntax based language. I have programmed mathematically dense dynamic simulations using labview. Newer versions of Labview include alot of exciting features, especially for utilizing multiple processors. I like Labview very much. But I don't recommend it to anyone.

Unfortunately, it's an absolute nightmare for anything other than simple acquisition and display. It may one day be sufficiently developed to be considered as a viable alternative to text based languages. However, the developers at NI have consistently opted to ignore the three fundamental problems that plague labview.

1) It is unstable and riddled with bugs. There are thousands of bugs that have been posted to the labview support forums that are yet to be fixed. Some of these are quite serious, such as memory leaks, or mathematical errors in basic functions.

2) The documentation is atrocious. More often than not, when you look for help with a labview function in the local help file you'll find a lonely sentence that merely restates the name of the item you are trying to find some detail on. e.g. A user looks up the help file on the texture filter mode setting and the only thing written in the help file is "Texture Filter Mode- selects the mode used for texture filtering." Gee, thanks. That clears things right up, doesn't it? The problem goes much deeper than that; quite often, when you ask a technical representative from national instruments to provide critical details about labview functionality or the specific behavior of mathematical functions, they simply don't know how the functions in their own library work. This may sound like an exaggeration, but trust me, it's not.

3) While it's not impossible to keep graphical code clean and well documented, Labview is designed to make these tasks both difficult and inefficient. In order to keep your code from becoming a tangled, confusing mess, you must routinely (every few operations) employ structures like clusters, sub-vis and giant type defined controls (which can stretch over multiple screens in a large project). These structures eat memory and destroy performance by forcing labview to make multiple copies of data in memory and perform gratuitous operations- all for the sake of keeping the graphical diagram from looking like rainbow colored spaghetti with no comments or text anywhere in sight. Programming in labview is like playing pictionary with the devil. Imagine your giant software project written as a wall sized flowchart with no words on it at all. Now imagine that all the lines cross each other a thousand times so that tracing the data flow is completely impossible. You have just envisioned the most natural and most efficient way to program in labview.

Labview is cool. Labview is getting better with each new release. If National Instruments keeps improving it, it will be great one day as a general programming language. Right now, it's an extremely bad choice as a software development platform for large or logically complex projects.

Answer 16

Personally, I think LabView is an excellent program for what it is designed to do. Aside from inheriting terrible code, which is a problem in any language, with good practice it is very efficient and quick for putting together all sorts of process control, automation, test, and measurement systems. Like text coding, good practice with LabView exists as well - if you have a scrambled, messy VI then it's really the fault of the coder and not the language. Text-coded languages can get very scrambled as well - the onus is on the programmer to not create unnecessarily messy or obfuscated code.

If you start writing your code with future expansion in mind then it's not difficult at all to create VIs which can grow with the needs of program without becoming cumbersome. Just the same as bad text code can quickly become a mess if you hack it out with a short-term view, only to have it outgrow itself and become unmaintainable. It does mean, however, that you have to take the time to learn LabView, just the same as you have to take the time to learn any language or IDE.

Chances are that if LabView is frustrating your efforts you probably should be using something else to create your program, or at least something else for those components of the program.

For example, if you need to do a lot of string handling - more than is convenient to hack through with LabView's string functions - but you really want or need to use LabView for the meat of your application, then there are many options open to you. You can easily code DLLs in something like C or whatever your favourite language is and then access those functions through LabView's DLL interface. This goes for any sort of high-level or abstract function which is awkward to implement with the basic LabView tools.

This has two big advantages - first you can focus your text coding to simply writing functions or procedures. The task of building the application around your functions becomes non-existent. By blending it with LabView, you gain the second advantage of LabView's quick and powerful UI builder and instrumentation connectivity.

In terms of source control, the biggest thing you can do is to flex LabView's inherent capacity for modularity. While you don't have text tools to help you, for example when trying to sort out unknown inherited code, it does have other very powerful features which, in an abstract way, can do many of the same things. It's probably the easiest language in existence to refactor, which means that, in general, refactoring inherited code can be done WHILE you are learning what it does.

If you go to a data source and break the wire, you instantly see everything that it was connected to, for example. The error list will give you a complete list of everything that broke due to a dependency on that data source and you can straight away work away at creating bundles and clusters to clean up the LabView spaghetti. It even highlights the broken data connections on the back panel so you can trace where everything goes. You can quickly encapsulate things in subVIs if it's clear they are littering the main process with clutter, etc. By the time you've figured out what your code does, it's neat and clean and suddenly re-maintainable.

The big exception to this is if the program used a lot of unnecessary globals. Surprise - globals complicate things in LabView too. In that case, there's nothing to do but curse the schmuck who left you the mess. Still, it's not the end of the world.

I suppose, in short, what I'm trying to say is that LabView is a very different language. If it seems frustrating, it's not because the tools don't exist to do the things you are used to in text coding, but simply that they are often implemented in radically different ways. Grepping code isn't an end unto itself, for example, but only a means to an end - the purpose is to discover links and references throughout the program. While you can't grep LabView code, you can discover links and references - it's just done in an totally different way. Learning curve stuff.