Bypassing Design Bottlenecks With LabWindows™/CVI

The Challenge: Developing a suite of PC-based functional test applications in limited time and without a complete product design or final test strategy. The Solution: Using existing LabWindows™/CVI test code as a starting point and architecting it to dynamically read test information from a text file.

Project Requirements

Our customer needed to launch a new range of flame detectors, assembled from two PCBs, and needed a turnkey solution. Test requirements included separate test applications for each PCB as well as a third test application for the final assembled unit. We needed to develop the test application in parallel with our customer’s product finalization due to budget and timeline constraints.

Without a finalized product or even test strategy, we had to develop our code so that elements of the tests could be defined at run time. This separation of test definitions from the main testing code helped us make progress in architecting the application without needing to wait for additional requirements. We estimate that this simplified approach saved us at least three months of lead time.

Application Description

The application architecture consisted of three threads running in parallel. One thread provided the tabbed user interface to interactively view tests during execution. This thread worked in tandem with a test scheduler thread that dynamically loaded the test information from an .INI text file. Finally, the test scheduler would send tasks to a data acquisition thread that would execute the analog and digital I/O tests.

We used .INI files to contain simple test descriptions that facilitated setting I/O channels with timing delays.

We supported additional keywords so users could describe more complicated tests such as rise time and edge analysis. We initially started work on just one of the PCB test applications due to our abstracted, generic coding approach. However, we reused the bulk of the code in the other PCB test as well as the assembled unit functional test applications.

In our experience developing many similar test applications, we have learned it is important to provide the user with meaningful data as the tests run through a monitor panel. This panel allows restricted access to the low-level acquisition and control functionality for test and commissioning. The worker thread that organizes the data acquisition and output control publishes its data to the UI thread, which then allows the user to see live graphs of the data. This helps users confirm the results of different keywords in the .INI file, and they can examine the data being collected while a test is running.







  • Test sequence abstraction: Defining the test flow and limits in an .INI-style file enabled an earlier development start time as well as the ability for customers to alter key test components without needing to modify code.
  • Multithreaded design: We developed a clean and responsive UI that executed in parallel with the main test execution logic.
  • Monitor panel: This panel simplifies testing and reduces the cost of ownership by empowering the customer to quickly and efficiently identify product failures. Previous customers have estimated that this has saved them at least a week’s worth of work each year for similar scale solutions.




The rapid development environment supported by LabWindows/CVI (particularly the UI design) combined with the coherent and straightforward support for multithreaded applications empowered us to develop an advanced application architecture that met the customer’s expectations. LabWindows/CVI syntactical base allows version control and compare to be carried out quickly and clearly for the development of a robust solution that can be supported for potentially many decades to come.


By abstracting test definitions to a text file, we provided our customer with flexibility, significant cost savings, and accelerated time to market.


Kevin Snelling: Director
at PTP