LabVIEW thoughts, part 5: A Little-Known Language

A couple of weeks ago I commented on an article about "little-known" programming languages and how it didn't mention LabVIEW at all.  Well, Dice posted a follow-up article of sorts on whether someone should learn a little-known language.  Again, LabVIEW is not mentioned.

But I've come to the opinion that it doesn't really matter, for two main reasons.

First, my impression of Dice is a site geared towards pure programmers.  Yes, I like to read specific articles on the site that appeal to my interests, but the majority of their content deals with web-based programming, games, and database/big data concerns.  LabVIEW isn't designed for that.

Second, knowing LabVIEW on its own is too limiting.  LabVIEW is a language, but it is language optimized for specific applications.  Sure, you can write pure database applications with it - I have - or you could write web apps with it.  But if you know LabVIEW and you are an electrical engineer, manufacturing engineer, etc. - then you are an order of magnitude more valuable to a company than if you just know LabVIEW.

Maybe that's why as a language it doesn't get much love from regular programmers.  They recognize that it is as much a tool as a language, so they just skip right past it.  But as my undergrad physics professor told me, it's always good to learn more methods on how to solve problems.  If the only tool you have is a hammer, then every problem looks like a nail.

LabVIEW thoughts, part 4

Back in December I said that I would write a series of posts about LabVIEW.  This is the fourth post, and now I want to talk a little about the nature of LabVIEW.  Let's start with this post I found from January, Little-Known Programming Languages That Pay.

Labview isn't listed in the article, not even in the "Math and Science Languages" section of the article.  Under that heading, the author instead lists an open source language that's compatible with Matlab.

And yet LabVIEW is used all over the high-tech industry - I've certainly made a living out of that fact.  Next post I'll explain the way I think LabVIEW is perceived, and why.  

LabVIEW thoughts, part 3-a (addendum)

A few days ago I wrote a post about LabVIEW versioning problems (again).  Here's something that I forgot to include in that rant:

To be fair, NI did help me resolve the problem.  I had to talk with a half-dozen people before it was fixed, but still.  Of those numerous people I talked with, one confidentially shared with me an interesting observation.  He (or she) said that this was far from the first versioning issue he'd dealt with, and it all went back to an NI philosophy: they don't go out of their way to support older hardware/software.  They would much rather you just upgrade to the latest versions.

This is fine if you're a small company buying equipment for the first time.  But for a big corporation (like I work for now) that is trying to maintain older systems, it's is difficult.

I'm guessing that this is partly why LabVIEW sometimes has such a bad rep.

LabVIEW thoughts, part 3 (the bitter edition)

I said back in December that I would write a series of posts about LabVIEW.  In this third post in the series, I want to talk a little about LabVIEW versioning hell.

This is not a new topic with me (look here or there).  LabVIEW version issues bit me again at work, only this time it was related to old hardware.  The problem stretched out for a month - from mid-December until I finally fixed it in January - but here's the crux of it:

1. I had an older PXI chassis with a new RT computer.
2. I couldn't get triggering to work on a couple of DAQ cards.
3. The triggering didn't work because the newer version of the PXI software (on the new RT) didn't support the old PXI.
4. The newer LV for RT code didn't support the older PXI software that I needed.

To resolve this, I had to completely wipe the RT computer (several times, but that's a different story), re-install an older LV version, and then downgrade my LV code (with all the headaches that entailed).  In other words, WEEKS of effort.

---------------------------

Not convinced that LabVIEW has a versioning problem?  Take a look at these convoluted eye charts, all directly from the NI website:

• DAQmx and LabVIEW Version Compatibility
• NI-VISA and LabVIEW Version Compatibility
• NI-RIO and LabVIEW Version Compatibility
• How to Upgrade or Revert a VI to a Different Version of LabVIEW

Sometimes I think NI expects customers to just sit and take it, like obedient pets...

LabVIEW thoughts, part 2

I stated in my previous post that I wanted to write a series about LabVIEW.  Today I want to write about a project I'm just wrapping up that dovetails with a recent NI  article, Top 5 LabVIEW Rookie Mistakes.

Here are the mistakes NI lists:

1. Overusing Flat Sequence Structures 
2. Misusing Local Variables
3. Ignoring Code Modularity
4. Creating Massive Block Diagrams
5. Disregarding the Need for Documentation

As I wrote last time, for the past couple months I've been working on a LabVIEW project.  It's a high visibility test system that was originally built well over a decade ago and then went through an upgrade some years later.  For several reasons it needed to be updated again.  I have now wrapped up the major code rewrites, and once I resolve the remaining hardware issue I'll turn the system over to other engineers for debug work.  

To be fair, the system worked.  It's hard to fault the engineers whose work produced a functional test system of such complexity.  Having said that, I need to add that the original code hit EVERY SINGLE ONE of the items on that NI list.  In fact, I would add at least a couple more:

• Using GUI objects as data holders.  Do NOT place a numeric control on the front panel, make it hidden, and then use it as a quasi-global variable.  Just say no.
• Lack of knowledge about functional global variables.  Oodles of information about them exists on the NI website, there are templates for them, and they don't break the dataflow paradigm.  Just do it.