TestStand - The Lesser Known Sibling of LabVIEW

TestStand provides an extensible framework to integrate and execute equipment/hardware divers and algorithms from a variety of common programming languages. That definition is fairly complex and is loaded with vague terms, but understanding TestStand as such may help you choose when to use it and will add it to your knowledge of usable software toolkits.

National Instruments, being primarily a test and measurement company, designed TestStand to be a PC based platform. They have a few different types of licenses on top of the Development/Base Run-Time package that they sell in order to make TestStand more affordable to deploy. The licenses range in ability, from simple operator functions to technician functions to run the debugger. TestStand is comparable to LabVIEW in its use cases: generally usable in Test & Measurement situations with the capability to possibly extend outside the industry. TestStand currently adds the most value when used on test benches, although NI is working on adding (and has already added) more production-ready features.

TestStand's framework is flexible and extensible. The development environment is meant to also be the execution interface and is therefore very configurable. You can easily give user permissions to limit usability or add scripts to automate what happens after certain environment-level events occur. Although it's not recommended, NI gives you the limited ability to edit TestStand's engine/core code/functionality; this lends itself to full customization of TestStand's characteristics and offers a feeling of source control over the TestStand environment. You have access to all of the variables that are used behind the scenes to create dynamic programs. The factory default is for TestStand to be a sequential Sequencer, but it can also run things in parallel if needed. It is not ideal to make a State Machine as TestStand does not add much value with that architecture.

Just as the TestStand environment has flexibility, the execution functionality has configurability. Once you have defined a sequence of steps to run in TestStand, you can execute the sequence. There are predefined actions which occur when certain events occur in a sequence execution. For example, a step failing, an error occurring, or an operator aborting all trigger events in TestStand. These are commonly referred to as "callbacks" (in both embedded programming and TestStand). There are numerous callbacks that the user can define and therefore customize their system's execution characteristics. These generalize design patterns and minimize repetitive programming.

All the heavy lifting of your application is really integrated into TestStand through adapters. I have mentioned that a sequence executes "steps". Steps are generally any code block that TestStand calls. The calling of the external code is done through TestStand's adapters. They read the external file and interpret what needs to be done to call it from TestStand. So if you have a device driver written in C, a DAQ driver in LabVIEW, and a .NET library of useful code you can put it all together in TestStand. This encourages encapsulation design as TestStand sees the steps it calls as black boxes with inputs and outputs.

TestStand is a great way to quickly execute code with an out-of-the-box interface and tools. There is a definite ramp-up on all the particulars of the software package, but if you are in the manufacturing or design industry it is a tool that may make your life easier.

Learn more about DMC's LabVIEW programming solutions.