Labview 2013 Free Download
Haldis Rucci
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.
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.
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".
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.
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:
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.
"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!."
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.
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.
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.
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.
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.
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.
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.
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)
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.
64591212e2