Labview versioning hell

I've been traveling a lot for work the past year or so.  A few weeks ago one of the people I work with on the west coast complained about the different versions of LabVIEW (LV) and how they don't communicate well with each other.  I brushed it off at the time, but like Chekhov's Gun, this came back to haunt me...

======================

About a year and a half ago I wrote a camera program that takes a picture and does some processing of that data.  This program runs on a station with LV2009 and NI Vision (v8.5) installed.  A couple of weeks ago someone asked to make an executable of this program and install it on another computer.  So I compiled the program and then tried to create an installation.

This is where I got stuck in LabVIEW version hell.  I could not create the install because (as the NI support people told me) the version of Vision had to match the LV version.  My choice was to either a) buy a new copy of a program I already had (Vision), or b) install LV 8.5 and compile with that.  So I downloaded LV v8.5, installed that on that computer, then I used LV2009 to downconvert the software to v8.5.  

But of course it wasn't that simple.  When I tried to compile the install, I got a "data space type map" error and LV crashed.  After some digging on the NI Forums I found out that this is a known issue with that version of LabVIEW.  The solution was to downconvert to v8.2, and THEN open it in v8.5.  BUT, I couldn't do it in my version of LV2009.  I had to either upgrade to a later release of LV2009 or do it in LV2010.   So I installed LV2010, opened the code in LV2010, downconverted it to LV v8.2, and then opened the v8.2 code with LV v8.5.  Finally I created the install.

======================

This series of events illustrates a simple question that I doubt has a simple answer.  Why can't LabVIEW work like a text-based programming language where you can open it regardless of what programming environment you use?  At it's root, code written in C++ or Java is just text, and you can open it in any compiler.  You can't necessarily do that with different versions of LV code.  I often see requests for reverse compiling in the NI LabVIEW Forums ("Downconvert VI Requests"), so I know this is a common problem.  Maybe it's because LabVIEW is not a public language but rather owned by NI?  Is it the nature of a graphical language?  Is there some other reason?  I don't know, but it's really annoying.

TestStand, (part 1 - Introduction)

As part of a project I'm heavily invested in right now, I started learning NI TestStand last fall.  My next few posts will be about that experience and my impressions of TestStand.

Introduction

My previous experience with TestStand dates back to early 2008.  My company was in discussions with Averna about their Proligent software, which is written to work hand in hand with TestStand. So I talked with the sales guys, read the white papers, and tried out the demo.  My impression of Proligent (and TestStand) was that they were designed for large companies with large automation needs.  We were a startup, so I respectfully declined.

Two years and one company later, I reconsidered TestStand.  I had a big program starting up and had no desire to create a test executive from scratch, especially not one with the complicated requirements I needed.  After some research and discussions with the other members of the group, I bought it and learned how to use it.

Over the next few posts I'll talk about a) how I learned TestStand, b) my experiences with it over the past few months, and c) how suited I think it is to small companies (like mine).  I'm also thinking about getting the Certified TestStand Developer certification to go along with my CLD for LabVIEW.  If I ever do, I'll surely blog about that as well.

Test engineer tropes

A comment someone made a couple weeks ago started me thinking about common rules of thumb that engineers follow.  Here's a few that I've seen in practice.

Murphy's Law
If something can go wrong, it will.  When I was in high school I thought this was clever and sarcastic way of expressing a dim view of the universe.  It wasn't until I was an engineer that I began to appreciate the statement as an elegant way of describing statistical inevitability: if there is a finite chance that something will happen, given long enough time it WILL happen.


Nyquist Sampling
Engineers commonly double the amount of data they take in the name of Nyquist sampling.  It may not be necessary, but that's the way it works.

Once is an anomaly, twice is a coincidence, three is a pattern
This is something that I've said for many years, just as a general rule for test engineering.  When I did a search for it, the most common mentions of this are either from the novel Goldfinger or The Moscow Rules (which quotes Ian Fleming).  But I think it is most applicable when you're debugging something.

Rinse it six times to clean it
There are well over a thousand references to this on Google.  Rinse something out with water six times to clean it.  It's a simple rule of thumb.

Double the safety factor
My first job after grad school was at an aerospace engineering firm.  There were a lot of mechanical engineers there, and I quickly learned of the prevalence of safety factors from them.  It was an unspoken rule that, whatever safety factor you calculated, before you finished the design that factor had to be doubled.  Better safe than sorry.

New car, part 2

In my last post I wrote about Consumer Reports, partly as it related to buying my new car.  While I wrote that I was struck by two related testing issues.

My latest car, a Ford Escape Hybrid, has Sync in it.  Although I've identified several bugs with it, and the voice recognition needs to be improved (especially when there's lots of road noise), I have to give them credit: it's a very slick piece of software with plenty of nifty features.

Back in 2004 I realized that, at least in America, cars were not going away anytime soon, although they would certainly need to change.  Gas prices would have to go up as emerging markets like China and India increased their energy requirements.  So I bought a Prius in February 2005 and have loved it ever since.  But it now has close to 200k miles on it - I'll probably need a new car soon.  So I've been considering an all-electric car like the Volt.  In my preliminary research I found a great article that pointed out the huge amount of electronics and software in this vehicle.


I guess the point of this post is that software in vehicles is going nowhere but up.  The integration of phone/MP3/bluetooth that Sync offers, management of electrical power generation and consumption in hybrid and electric cars, onboard navigation, or even future features such as automatic driving: this will all require huge amounts of electronics and coding, and therefore LOTS of testing.

New car, part 1

As I said in my previous post, a lot of things were taking up my time last fall.  I'd like to relate three of them right now.  Bear with me - there is a test-related payoff.

I bought a new car in October.  After a lot of thought and research, I decided on an Escape Hybrid.  I've written before about my Prius, it has never given me trouble, so I decided to try the SUV version of a hybrid from Ford.  I did a lot of research before I committed to buying it, and so far - four months and 7000 miles later - I'm happy with the results.

My water heater sprung a leak last fall, and I finally bought a new one in November.  Again, I did a lot of reading up on water heaters, and for better or worse I know more about them than I ever thought I would.

In October my washing machine went kaput.  It just stopped working.  I debated the merits of a) paying someone several hundred to fix it or b) spending days of my time fixing it myself.  It was more cost-effective to buy a new one.  For a third time, I did a lot of reading up on the subject and decided on getting a front loader.  It saves water, it saves electricity, and it's a nifty piece of engineering.

I love Consumer Reports.  For a small yearly fee I can read articles, view customer ratings, and test reports.  The test reports are detailed, comprehensive, and informative.  I've had a subscription to their magazine, and then the website, for a decade.  Needless to say, I gave their test database a workout last fall on the three items listed above.  It truly helped out.  I tip my test engineer hat to them.

In mourning

A few days ago the Department of Energy announced that Fermilab will be shut down in December.  The New York Times ran a story on it here, as well as an editorial.

As I've mentioned before, as a physics grad student I spent a couple years at Fermilab working on software at the D0 detector as well as testing new calorimeters for the now-defunct SSC.  It was a fun, frustrating, exciting experience.  It's a sad day for American science as well as physics in general when such a premier lab has to be shuttered.

I wish everyone still at Fermilab luck wherever their future takes them.

New Years resolutions

Unfortunately I haven't posted to this blog in over two months.  A combination of issues - health, home improvements, work travel, kid issues - have contributed to my lapse.  I have several items I planned on covering, but I perpetually delayed.

For the past several years I've kept a written document that lists all my new years resolutions.  At the end of the year I write a review of how well I did for each resolution.  I find it a productive exercise.  On of my 16 resolutions for 2011 is write a minimum of two posts every month to this blog.  We'll see how I do.

While I'm thinking about it, here's a list of things I want to write about over the next couple months (in no particular order).

• TestStand
• New cars
• Keeping track of things
• ATML
• Blog toys

So that will keep me busy through March.  Happy New Year.