Learning To Love TestStand

Most of my blogs so far have been very LabVIEW focused – not surprisingly as it is the tool I make the most use of in my day to day work, and of all the languages I do is the one I am the most fluent in and feel most comfortable using.

I consider it to be the best tool currently out there for doing test, control and measurement and certainly in the National Instruments (NI) world it is the ‘prima donna’, getting more exposure than probably all of NI’s other tools put together.

There is however another tool in the NI stable that is arguably the real star of the show and beats LabVIEW (and anything else I can think of) hands down when it comes to the particular task of test sequencing and that is TestStand.



TestStand Sequence Editor


It is a tool that as far as I’m aware is almost unique in the world – out of the box it allows highly complex sequences to be built up using LabVIEW, .NET and many other languages, a wide variety of synchronisation options such as while loops, if statements, delays etc. The ability to utilise multiple test sockets and manage them concurrently or individually. Full user management capabilities, the ability to load in limits from file or database, and a mind boggling array of reporting options.

This only scratches the surface of what TestStand can do and there is simply nothing else on the market that even gets close to it with just these features.

It goes further though, as if out of the box TestStand doesn’t do exactly what you want it to do, there are almost infinite ways in which you can customise and interface to it without losing that core sequencing ability – it is a marvel of software engineering, but one that does it’s business in the shadow of it’s far louder, brasher, more exciting brother.

What is so strange about me saying all of this is that at one point in my life I absolutely loathed TestStand, and couldn’t see why you’d want to use it over LabVIEW or .NET for instance.

My journey from hater to lover was a difficult one. I was working on a project testing a mega complex satellite payload equipment. Throughout the project I was on an almost vertical learning curve in many aspects – it was the first satellite payload I’d worked on, the first time I’d used much of the instrumentation being used, and all this working in a new company.

We were to use TestStand and LabVIEW to develop the test software, with test planning, and results handling being done by a very clever .NET application which interfaced to TestStand but not LabVIEW. I didn’t have much experience with TestStand at the time, but plenty with LabVIEW having already been a CLD for a couple of years and having recently passed my CLA, and having a certain aversion to TestStand I wanted to minimise my use of it to simply call large single blocks of LabVIEW that did a test and returned a big cluster of results that TestStand then reported to the test database.

As a pure bit of LabVIEW software I was very pleased with it. I’d made significant use of the newly released Object Orientated features of LabVIEW and created what I felt was a very well structured, lean and robust bit of code.

For the most part I was right, but I was soon to discover that doing it this way had a number of drawbacks all of which could have been avoided by using TestStand.

The first was that as much as LabVIEW block diagrams are easy to read for those of us who use the language on a daily basis, trying to demonstrate to RF engineers who have never used LabVIEW that you have implemented their procedure to the letter in a VI with looping etc was not easy, TestStand’s intuitive interface was a far better environment for doing this.

The second was that I had configured all my limits in LabVIEW – either hardcoded in VI’s (virtual suicide), or read from ini files. It seemed like a good idea at the time, but then the requirements changed, and it meant that rather than just modifying a completely separate file, I had to actually open the code, modify a limits VI, and then rebuild the software – utterly nuts looking back! The way I should have done it, and the way I have been doing it ever since is to configure limits within TestStand and then use the in-built property loader to export and import values at runtime and pass these into the LabVIEW code modules.

The third was that dealing with highly precise measurements, our RF engineer friends would go through the software with a fine toothcomb wanting to examine in minute detail every step of the test and would make requests like “could you run that step again with a different value”….My answer was no, as you can’t change values on the fly in LabVIEW – they are what they are. This particular problem was exacerbated by the fact that a couple of more experienced colleagues (and very smart ones at that) had done all of their test sequencing within TestStand, so they could do all of this.

A final reason was that with TestStand being the entry point and reporting tool, my clever colleagues with their detailed test sequences had oodles of detail in their test reports which meant every instrument setting, and returned result was there to be analysed. My sequences with my single step call to a LabVIEW VI had, well virtually none. It meant that whilst when one of their tests went wrong they had a raft of data to pour through to identify the problem, my software had virtually none, which meant that when the inevitable debate that usually eschews from this sort of thing of ‘is the problem with the DUT, instrumentation, bad calibrations, or your dodgy software’ kicked off I had no answer or evidence to prove that it wasn’t my software that was the problem.

I could probably add other reasons to my list of how using TestStand for sequencing rather than LabVIEW would have saved me a lot of pain and embarrassment, and I’ve probably made myself look like a bit of a dumbass to anyone reading this – maybe I was, but I’m fairly good at taking on-board criticisms (often from myself more than others!) and learning lessons from mistakes I’ve made.

I suppose there are two points here – the first is obviously related to the title of the blog, and that is that TestStand is an amazing sequencing tool in any kind of test environment, and has many advantages over using LabVIEW in this context. If you’re a die-hard LabVIEW developer, especially one who does a lot of sequencing, or is likely to then TestStand could save you an awful lot of pain – and even if you dislike it at first like so many LabVIEW developers do, I am certain that like me you will learn to love it.

The second point, and this is a more philosophical angle, is that the biggest lesson I learned from this episode is that regardless of how much faith or love you have for a particular tool, keeping an open mind to the fact that there may be better tools out there to use in certain contexts is a healthy state of mind to have, and having that attitude, and then learning to use those other tools will often reap far greater benefits than trying to make the ubiquitous square peg fit into a round hole.

6 thoughts on “Learning To Love TestStand

  1. Great article and very true. I’m going to blatantly plaigarise somebody else when I say “The solution should fit the problem domain”……..this applies not only to architectures but of course the tools that we use also. How many times do you hear the words “and then the data is written to an Excel database” ??? We often taken the tools we use (such as Excel) and make, no, force them into doing much much more than that.

  2. Umm – I really don’t know what you say – thank you for all your comments – for a blog I was really not very happy with and had all but binned I’m quite surprised.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s