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.

What comes after accelerators

A couple of weeks ago I wrote about my penchant for storing away articles I come across.  I've also talked many times about my continued interest (here or there, for example) in high energy physics.  It's been two decades since I left grad school, but I still have to credit my background in particle physics for my test engineering career.

A few days ago I came across a piece I had stored away from back in July about what might come after accelerators.  The author, Dr. Victor Stenger, pointed out that while ever more powerful accelerators may not be on anyone's radar right now, there are numerous other tests to expand our knowledge of the universe.

So I then looked up Dr. Stenger and found out he died back in August.  Depressing, but it looked like he lived a good life.  So I downloaded his last book God and the Multiverse and started reading it.  I'm only a chapter or so into it, but it's fascinating.

Reasons to test

I tend to be a packrat for interesting articles.  I'll come across something interesting, open the page, and then move on.  Consequently, I'll pile up 20, 30 or more open links on Chrome for iPad until I finally break down and binge read.

Today is a lazy Sunday morning, so I binged.  One of those stored links dated to way back in July about reasons to test.  It's a nice little summary of four canonical test types.  However, it missed at least two test reasons that are specific to volume manufacturing: binning and SPC.

Suppose your company makes thousands of widgets that have variations in a key parameter.  You therefore have two choices: spend time and money reducing that variation to acceptable limits, or find customers that desire those variations.  If you opt for the second one you spend time and money to implement the testing for that parameter, and you use the test results to put the parts into different categories for different customers.  That's binning.

I'm not going to try to describe statistical process control (SPC).  I've taken a couple of small courses in in it, and I've applied it to manufacturing testing at a couple of different companies.  But I'm no expert.  Go here for a good summary, and follow the external references for more detail.  All I will say is:

1. SPC is a requirement for high volume manufacturing.  
2. You need lots of data for SPC.
3. You have to test to get that data.

So why did the article's author leave out these items?  I can think of three reasons.  First, maybe he thought they fell under the verification or validation categories.  I could maybe buy the verification for SPC argument, but that's as far as I would go.  Second, his testing experience is in low-volume industries (i.e. - certain military markets) where SPC or binning isn't useful.  Third, he just wrote the article quickly to meet a deadline without thinking it through.

That last reason is a little harsh.  But this lazy Sunday morning is also kind of cold and overcast, so I'm a little morose.

(the internets love cats)

Matlab improvements

I went to a Matlab seminar a couple of weeks ago,  Actually, I thought that I would mostly hear about RF and microwave testing using Keysight (the company formerly known as Agilent) test equipment.  I knew they would throw in a little Matlab, especially since Keysight and MathWorks have becomes  BFFs (here or there).

I realized early in the day that it was shaping up to be a majority Matlab experience.  So I decided to roll with it and listen - besides which, I also scored a coffee mug.

My experience with mathematical software like Matlab is complicated.  Back in grad school I test drove  an early version of Maple, and I used MathCad to make some nifty models for my thesis.  But in the working world Matlab and Labview tend to conflict more than complement - google Matlab versus Labview to see what I mean.

I had used Matlab at several different companies the past decade and viewed it as a great tool if you're a researcher trying to put something together.  But when you have to get something to test shippable product, go with the more professional Labview.

That opinion was shaken up a bit with what I saw in the seminar.  The last version I used was Matlab 2007.  The latest version (2014) has quite a few new tools.  I'm not going to make this a Matlab commercial, but here's what caught my eye:

• Better debug support
• Source code control
• More tools fork converting what you just did into m-script or functions.
• OOP support
• Data highlighting tools

Of course, none of this means that I'll drop Labview and migrate to Matlab.  But the experience was an eye-opener...

Yet another company

A dozen years ago the biggest risk of a startup smacked me upside the head: the company ran out of money and closed it's doors.  Since that first experience in the high-tech* startup world, I've worked at a half-dozen or so other such companies.  Over half of them are no longer in existence.

I have accepted that, but I was never happy with it.  This past summer things went downhill with my latest company.  Within a month I had offers from three companies: a temporary contract gig at a mid-sized company, a large fortune 500 type, and another startup.  Sometimes it is good to mix it up, so I decided to ride with the behemoth.  I've been here two months now - we'll see how it goes.


--------------------------------
* My definition of a "high-tech" startup includes actual hardware.  I'm sure a lot of smart people work at companies developing new apps for smartphones, algorithms for web-hosted databases, or some other clever software tool.  But unless it involves some newly-discovered applications of physics/chemistry/biology, it doesn't meet my criteria. That's just my bias.

PXI work

So I found this link on EDN about PXI systems last year when I was doing some research for a new project.  I was going through old notes this weekend & cleaning up some files when I found it.  I'm not quite sure anymore why I saved it.  Maybe it's because the author mentioned hybrid slots?  I bookmarked the link last year when I was shopping for a PXI chassis for a new test system, but that's as far as memory takes me.

Anyway, I started thinking about PXI-related issues again this past week, and stumbling across this link reminded me of the experience I had selecting the hardware last fall.  After I had determined how the the test system would work, I made a list of all the hardware I needed: DMM, power supply, multiplexer switches, and relays.  It was too much for a cDAQ to handle (as much as I liked the concept), so I started shopping PXI companies.

I priced out what I needed from four different vendors.  At a startup company you try to keep the costs low, so I spent over week justifying the cost for the system.  If the test system would cost $10k or more, I had to show the legwork to minimize that cost.  Of course the expense of someone like me - getting paid what I was paid - digging around to save a grand or less didn't make much sense.  But so it goes.

I ended up buying the PXI gear from NI, and the test system worked.  And the one thing I got out of that week I spent shopping PXI prices?  There wasn't much difference between the vendors.  Originally I tried to shy away from NI since I assumed their stuff would be pricey.  But in the end it was barely more expensive than what I could get from the other three companies.  Learn something new every day, I suppose.

My experience with Labview OOP

About a year ago I started working at a new company.  One of my first tasks was to automated  functional testing for a robotics controller.  When I started we were shipping individual units out for sampling, and I had to test them by hand.  That took about 3-4 hours (including setup time and recording all the data), and we didn't cover all the testing we should be doing.  So my goals for the project were to:

1. Reduce the time down to ~15 minutes
2. Automate it so a technician could easily run it
3. Run additional tests that couldn't be done by hand
4. Save all the data to a database

Once I mapped out the program requirements and logical flow, I decided to make this my first foray into object-oriented Labview.

I had taken a class in LVOOP years ago, and I had read how-to's and  case studies with OOP in Labview, but I had never used it for a work-related project.  There were several reasons I used.

• I was re-engineering a program written by a previous engineer so I had to stick with pre-existing logic.
• I was writing small VIs for a larger TestStand implementation
• My programming partners didn't know LVOOP at all.  

Plus I may have been a little intimidated by the whole idea of an unknown architecture.  So I stuck with the standards: state machines, producer-consumers, and event-driven programs.

But now I had no excuses.   It was a brand new project, I was the only one working on it, and the project's complexity cried out for a sophisticated solution.  This was the perfect time.

And you know what?  It wasn't hard at all.  Maybe it was the OO programming I had done before in VB and C++, but the implementation went smoothly.  The only Labview-related glitch I had was early in the project when I tried to update a VI class member, but I worked it out.  And those classes I wrote for that project ended up being very reusable for two other projects I developed later on.  Excellent.

Job satisfaction

As my children have grown older, I've tried to describe to them two important things about the working world: doing a job the right way, and the hard-to-define satisfaction you can get from a job well done.  I had the perfect example described to me this past weekend.

My wife teaches at a local high school, and the hockey team made it to the state championship game.  To show our support, we attended the game.  At the game I bumped into Gus, whom I used to work with at a startup company I left back in 2011.  His company runs the IT support for that company, and I worked with him to implement the database I developed as well as my test systems and analysis software.  We talked some about how the company was doing, and Gus mentioned that the database, the test systems that write to that database, and the programs that pull and analyze that data are all still actively used by the company.

Now THAT is a really nice feeling.  I must've done something right.

Labview versioning hell, pt 2

Back in July I wanted to look at some fairly old code I had stumbled across - in the past I've had to do this a time or three.  This code was too old to up-convert with the version of LV I had, and I didn't have access to any older versions of LV.  While I worked on posting the code online to ask someone to convert it for me, I posted a suggestion to the LabVIEW Idea Exchange.

Basically, I was asking for a way to at least view very old code, and maybe include reasons for why it couldn't be up-converted.  The response I got was, basically, "If you are an SSP member you can download older LV versions.  If you don't pay to keep up your SSP, you're SOL."

Needless to say, I found that less than satisfying.  First of all, why would I want to spend the time and effort to download and keep track of older versions of Labview?  Second, it sounds like just another way to have owners of the LV software to continually pay money to NI...

Test your code

So at my new company I'm back to software testing.  What goes around comes around I suppose - I first learned the ins and outs of software testing at HP about 15 years ago.  Even though most of my jobs have been hardware testing since then, I still enjoy reading about it (i.e. - here, there, and way back then).  As my dad has said many times, it never hurts to learn something new.

Speaking of which, I recently found two articles about the costs of NOT testing your software that I enjoyed, in a perverse sort of way.  The first article is a bit esoteric unless you've done serious code testing before.  Basically, it explains how Kaspersky released an update to software that wasn't regression-tested.  In other words they made changes to the software, and, while they may have tested their changes, they didn't test whether those changes would mess up the base code.  That's the whole point of a regression test suite.

The second article is of somewhat more personal importance.  For a long time I owned only Toyota cars.  But once I started reading about braking problems back in 2009, I decided to buy Ford instead (here and here).  This past October a court finally ruled against Toyota, and central to the case was the Engine Control Module's firmware.

Will companies forever keep neglecting software testing in favor of releasing product ASAP?  I mean, just reading a paper like this from NASA and anyone with half a brain should realize that software testing is of paramount importance.  Jeez.

Yet another startup

I'm sure there's a 12-step program for this somewhere, but I think I may be addicted to start-up companies.  Last month I joined my seventh (or maybe eighth) high-tech startup firm.  As I've written numerous other times (here, there, and back then, to name a few), I have landed at numerous early-stage companies over the past dozen years or so.  That's one upside of living in the Boston area - there is never a shortage of smart engineers wanting to start a new high tech company.  And they all need test engineers.

At any rate, I may have to put this blog on hiatus for a while, again.  The startup experience can be intense at times.

But now that I think about it, start-up companies could be fodder for a couple more posts....

Test Executives - part 3

I started writing about test executive software last month, and then a couple weeks ago I wrote about off the shelf software.  Now I want to write about my experiences with "rolling your own" test executive.

I've worked with homegrown test executives at two different companies.  At the first company the test executive evolved out of a couple of different programs for testing different features of the same product.  In the second company, I worked with a test executive that had been written several years before I started. I'll address each one in a separate paragraph.

The executive I wrote myself was somewhat rudimentary.  For the products we were manufacturing, there were six distinct tests you could perform.  Each of those tests had from about 3 to 20 different numerical parameters that could be adjusted.  This just screamed out for scripting, so that's what I did.  The end result had the configurability I needed, and it was often used by test technicians, but it was missing several other features of an off the shelf system test executive:

• It was only usable within the Labview framework I had written.  For example, it couldn't interface with any modules written in C++  without a lot of extra coding.
• There was no programmatic logic in the scripting.  The scripts consisted entirely of what tests to perform under what conditions - no if-then or optional looping allowed.
• Some reporting tools existed, but mostly in simple formats (saving CSV files or bitmaps of graphs).
• It was written with testing a specific product, and had to be overhauled to test some other type of product.

The other test executive was written in .NET and made use of Measurement Studio for certain graphical presentations.  The scripting tools had quite a bit of programmatic control, and the reporting tools were more extensive.  But there were different problems.

• Because it had been designed as a reconfigurable tool, it was horribly complicated to use.  We didn't let technicians near it without a lot of training.
• It was only usable within the .NET framework and didn't play well with other modules.
• It was written with testing a specific product, and had to be overhauled to test some other type of product.

That's a brief synopsis of the two in-house test executives.  So, what is the point I'm trying to make?  I'm not really saying that you should run out and buy a copy of Test Stand.  It's certainly a nice piece of software, but it's expensive and may be overkill for what you need.  I guess the lesson I've learned is that if you get to the point were you want to develop something for yourself to reuse over and over, learn from how the OTS software does it.  Specifically:

1. Don't make it overly complicated
2. Make it generic enough to use for different tasks
3. Use programmable logic in the scripting
4. Have plenty of reporting tools

Test Executives - part 2

A couple of weeks ago I started writing about test executive software.  I've decided that this topic is another three-parter, so in this 2nd post I'll write about off the shelf (OTS) software.  The third post will cover in-house test executives.

I mentioned last time that I have my own definition of a test executive software, but I never wrote that definition.  Well, for me the software is defined by what I expect it to do.  The three things I expect at a minimum are:

1. Configurable testing.  I need the capability to switch up the order in which specific parameters are measured and under what conditions they are measured.  This is typically done with scripting or configurable sequence files.
2. A solid, usable GUI.  A test executive is often used by a test technician instead of an engineer, so you need software that doesn't require a lot of care and feeding.
3. Easy to see what's happening.  This is somewhat related to #2 above but more specific.  I like graphs, reports, and charts.

The OTS platforms I have experience with are TestStand and ATEasy.  I wrote about my experiences with TestStand a year ago (a three parter, starting here and continuing with this and that).  To be honest, I'm a lot more nebulous on ATEasy and my knowledge of it consists of three data points:

• I sat through a long seminar on it once.
• I worked with a guy who had used it before and liked it.
• I evaluated it for about a week at a previous company.

Given that limited knowledge, I think it would serve as a cheap, limited alternative to TestStand.


On a final note, NI published a checklist for evaluating test executives.  While the list is a little self-serving and obviously slanted towards NI software, it's worth consideration as a starting point.

Happy SIX years

Six long years ago today I wrote my first post on this blog.  Since then I've written close to 200 posts on various topics.  Based on some of the feedback I've gotten, at least a few of them have been helpful.  So here's to six more.

Test Executives - part 1

For many years now I been a little obsessed with the subject of test executives.  I'll explain why in a minute, but first let me try to define what I think of as a test executive.

Wikipedia has a specific description of test executives, but my definition is more specific to my experiences.

So why do I want to write about this topic?  Ten years ago I was working for a small division of a Fortune 500 company.  We had just bought a complicated test/manufacturing tool developed by a consulting firm.  This firm had written a script driver that they used for most of their hardware projects.

That was an epiphany moment.  I had written a script driver for a specific test instrument when I worked at HP back in the late 90s, but I'd never really thought about writing one that I could reuse across projects.  Nor had I considered buying one off the shelf.  In the ten years since that moment I've worked at four other companies that developed four separate solutions.  So over the next couple posts I will write about different test executives - commercial as well as "roll-your-own" - and compare and contrast my experiences with each.