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.

LabVIEW thoughts, part 1

My last couple posts of the year will be about LabVIEW.  In fact, my first couple posts of the new year will be as well.  I guess I have three reasons to do this.

LabVIEW is all over
This blog is not meant to be LabVIEW-specific.  I've said this all before but it bears repeating:

• I am not nor have I ever been an NI employee.  
• I have never worked for a test engineering house that has a tight NI-LV connection (well, I once considered it).  
• I'm just a test engineer.

However, LV has a huge presence in the test engineering field, and I am a good example of that:

1. Even though I've done a fair amount of programming in VB and C++, historically I still do most of my work in LV.  
2. I've been a certified LabVIEW developer going on 5 years now.  
3. Of the 200 or so posts I've written over the past seven years, about 25% were about LV in some way.

Recent projects
Over the past two months I've been heavily invested in a LV project at my new company.  Last spring I wrapped up my first big LabVIEW-OOP project.  Before I was laid off, I had just finished a LV tool for writing and reading build data for the manufacturing floor.  All this LV-specific work has got me to thinking about things.

New environment
With my latest company I experience something that I've seldom had in the world of startups:  colleagues.  I sit in a cubicle area with four other test engineers in easy talking distance.  A dozen more sit within a 30 second stroll.  That level of interaction has gotten me to think about LabVIEW in different ways.

Anyway, I'll write at least one more post on this topic before the year is out, maybe two.  But it's Christmas, so things can get busy.

Interviewing tips for newbies

I've changed jobs about a dozen times (so far) in my career, and I've been on the other side of the coin many times as well.  So I think I've gained some insights into the interview process.  The last time I posted something on this topic was June of last year (and a follow-up as well).   So this topic came to mind when something else happened a couple weeks ago.

My udergrad alam-mater contacted me about a new alumni mentoring initiative they had started.  This is certainly nothing new - many colleges do it - nor was I special in being contacted.  I added my name to the list and filled out the online data form, and then I started thinking about what the heck I would actually tell someone if they contacted me.

One of the most intimidating aspects of getting a new job after college (at least for me) was the first job interview.  So here's a few things I jotted down.

1. Check out the company.  This should be obvious nowadays.  Check out the company website.  Then dig deeper: what division would you work for, what do they make, who are their competitors, etc.
2. Check out the interviewers.   Look at their LinkedIn profiles.  Look at any papers they've published.  Who do they report to?
3. Review the technology.  If you're not that familiar with the industry, spend a couple days and get familiar.  Download a PDF primer, read about it on wikipedia, whatever.
4. Consider what you'll be testing.   (This one is very specific to test engineering, but that's what I do.)     Find out what you'd be testing and spend some time thinking about how you would test it.  I guarantee you will be asked questions relating to that topic. 

If I do ever get contacted, maybe I'll write about the actual experience.