I realize that NI has the TestStand product that is an off-the-shelf test executive. I have not used TestStand in years simply because my company does not currently use it. I’m sure what I’ve developed is no match for TestStand, but there is room for developing your own test executive. Some reasons may be you don’t want to pay for TestStand (although it will cost you time and effort to develop your own). Perhaps TestStand is overkill or maybe it will not meet your needs. Basically, developing a simple test executive was a good test related project that would require fairly extensive user interface development.
I’ve given my test executive a name, the DOT-TE or Dana On Test Test Executive. That seems a little more cute and clever than I like to be, but it gives me something to name the VIs.
I’ve spent quite a while working on this as I have been working on it in my spare time. Like most engineers, I didn’t think it would take as long as it has.
This project is still pretty far from being a stable test executive that could be used in a manufacturing environment. In fact I think it’s at about version 0.1. If you look at the specifications and code there are some features that I have not yet implemented, I could keep working on it before making this post but I just feel like it’s time to ship (so to speak).
The way I decided to tackle this problem was to first create a prototype of the user interface with stubs of the main functions I wanted it to have. I saved the prototype that was created; it’s posted in Projects and Code page in the DOT-TE.zip file as “DOT-TE_Main_UI - Prototype.vi”. The point of the prototype was to get an idea of the look and feel of the user interface and help think of all the functions a test executive would need.
The main user interface is based on the Producer Consumer design pattern that comes with Labview. Each button click or menu click puts a message into a queue (producer) and sends the message to execute some related code (consumer).
After I had the prototype the way I wanted it, I tried to write some specifications. I suppose writing specifications wasn’t all the necessary for a project the only involved one person, but I wanted to make this somewhat a true-to-life project.
Here are the original specifications I wrote after I had the prototype. Looking at this, I’ve implemented less than half of this:
log in with different privilege
print a report
db store results
db sequence file
display status and messages
display tests p/f
input test information
load test button
run test button
directory storage control
setup controls like printing
display system messages
App Database will hold:
System Database will hold:
Put error messages to the System Messages
In addition to the specifications, I wrote a program flow to try to map out how the test executive would be used and how it should behave. This expands on the specifications and was a way for me to think and write some notes. I have not edited this from what I originally wrote.
- Initialize the menu system
- Initialize System Messages
- Initialize Test Status, Detailed Results and Test Reports to be blank.
- Check for the application database
- gray out Load Parts, Run Test, Abort Test
- System Messages
- “System Initialize…”
- “System Idle.”
- select a test from file dialog
- populate the tabs
- Test Status Tab
- list tests
- Detailed Results
- list tests
- list measurements
- System Messages
“Test Application X Loading…”
“Test Application X Loaded Successfully”
- enable Load Parts button
- System Messages
Load Test button has been pressed.
Go to case “BUTTON – Load Test”
Go to the default or current test application directory and display the directories available to load.
Display the system message “Test Application X Loading…”
Check for a valid test application database
Check for a valid sequence file and limits file from the application database
Read the limits file from the database and hold it in memory somehow.
Read the sequence file from the database and hold in memory somehow.
Make visible Test Status, Detailed Results and Test Reports listbox, table, whatever with the tests listed.
- lists the tests
- add a test loaded Boolean
- add pass fail text and Boolean
- list the tests
- list all the results by reading from the limits file
- put cursor on the “site” field of Test Information
- gray out “Complete” button
- once “Complete” is pressed enable “Run Test” button
- System Messages
- Put the Test Information into a global
- When all required Test Information is entered, enable the Complete button
- Enable Run Test button and turn on the Test Loaded Boolean when the Complete button is pressed.
- update Test Status after each test with p/f
- update Detailed Results after each test with measured values and p/f
- update Test Reports tab with report when done
- generate overall result on front
- System Messages
“Running Test X”
“Report upload to database: Success/Failure”
- while running gray the Exit button
- call each test vi according to the sequence file and execute
- determine the result of each test
- determine overall result
- generate test report
- check if printing
- clear Test Status tab
- clear Detailed Results tab
- System Messages
- Load Parts
- Run Test
- Abort Test
- stop testing when current test ends
- System Messages
- read from sequence to determine next test
- disable menus while test is running.
Other Functions (Options)
Print Setup (default off)
- print on completion
- print on fail
- print all results summary only
- print failing results only
Looping (default off)
- stop on fail
- number of times to loop
- System Messages
Loop stats while looping
- display all tests for loaded test or display no test loaded
- radio button for test to run
- select all button
- browse to where you want to load test apps from
- set the names of the test to run (add, remove test)
- set test execution dependencies
- select the limits file to use with the test application
- select the test application name
Database – DOT-TE
(maybe just make this a folder where the test reports go in the first version)
Database – DOT-Test_App
Table 1 – test sequence
Table 2 – limits file
The project was implemented in Labview 8.5 (I know, I’m several versions behind, but that’s what I have access to at the moment).
If you go to the Project and Code page of the website and download the code, everything is included in the DOT-TE.zip file.
Within the DOT-TE.zip file the project is controlled by the Labview project file DOT-TE.lvproj.
The folder “DOT-TE” can go anywhere, I’ve been putting it right under C:\.
The test executive code is in the folder DOT-TE Application. The test application is in the Apps folder. The test application is like the actual test code that would be written to test a DUT. The test application is run on the DOT test executive.
The example test application I wrote called DOT-Test_App_00001 includes five test VIs that would test some commonly grouped functionality of the DUT. The five tests output constant values in place of real measurements.
There is also some code in the five tests to hook into the test executive and make the measurements accessible to it.
Opening DOT-TE_Main_UI.vi it executes automatically to start the UI. The idea of the interface is to follow the buttons on the left hand side, working your way down starting with “Load Test.” Figure 1 shows the UI with all buttons other than “Load Test” and “Exit” disabled. This is the default state.
At the Load Test file dialog select the test application file “Test_App_00001.txt” in Apps\DOT-Test_App_00001, this will load the test application. Figure 2 shows the “Test_App_00001.txt” file dialog.
Pressing “Load Parts” will make the Test ID field of the Test Information active. The test information is how you would identify an instance of the DUT you are testing. The test ID will accept any free text as will the serial number fields. The idea of the Test ID is you would have some system of how to identify a particular test run and enter this there. The serial number would be the serial number of the specific DUT you are testing.
Entering the Model # and Part # fields will popup dialog boxes allowing the user to select from the model and part numbers that are listed in the limits file. The purpose of the model and part numbers are just more information to identify your DUT. This is useful, for example, because different model numbers could indicate slightly different DUT configurations. So, two model numbers may have all the same measurements, but different limits need to be applied to those same measurements. What’s nice is there can be a small change to the DUT and the test application and test executive are able to handle it without creating an entirely new test application.
Digressing from the UI for a minute, Figure 3 shows the limits file I have mentioned a few times above.
The limits file is edited in Excel and saved as a tab delimited text file for the test executive to access.
The limits file in Figure 3 has several fields, and five fictional tests. You can see that each line of the limits file is uniquely identified with the “Limit ID” column. This limits file has two instances of the same tests, one for part number DOT01 and another for part number DOT02. I’m not really using the model number as it’s only there to make the possible DUT configurations more flexible. Each test and measurement has a unique name. All the limits are the same for my two part numbers, with the exception of the Model Number test.
The app name 00001 comes from the test application name Test_App_00001. The intention is all test application names would take the form Test_App_XXXXX. I guess it’s not that descriptive, maybe that should change.
Getting back to the test executive UI and entering the test information. When you tab to the Model # and Part # fields you will see the two dialog boxes in Figure 4 respectively.
Again, the pull down in each of these dialog boxes is populated from the limits file model number and part number columns.
Finally, pressing the “Complete” button in the test information section will fill in the information in the “Test Status” and “Detailed Results” tabs of the interface and enable the “Run Test” button. See Figure 5.
Actually running the test is somewhat anti-climatic because the results are just hard coded for this example test application. Figure 6 shows the directory that holds the test VIs executed when the test is run through the test executive. Again, there a no real measurements happening, but the idea is these VIs would be where you perform the actual measurements on the DUT. You can see in Figure 6 the naming convention I have chosen for the tests. TEST-(test name)-(app number).vi.
As a result of running the all the tests, Figure 7 shows the “Test Status” tab with all of the individual tests passing and the overall test status of pass.
Figure 8 shows the result of the passing test from the “Detailed Results” tab. The most important information here is the actual measurement data. In the event of a failure, this tab would show you if the test failed high or low relative to the limits or if no meaningful data was gathered (like a test returned NaN).
At the end of each complete test run an html test report is generated. The test report basically shows the same information that is in the detailed results tab. The history of all the test reports generated since the test executive was opened is in the “Test Reports” tab. Figure 9 shows this.
A good enhancement here would be to include the pass/fail status in the test report name. I forgot that. Also, it’s a bit cryptic, but each test report name includes the date and time stamp.
At this point, the “Unload Test” button can be pressed and a new test app can be loaded. Or, the “Load Parts” button could be pressed and a new DUT could be loaded and tested. The “EXIT” button unloads the test (if the user forgets to press unload test) and stops the test executive VI running.
There are three pull-down menus at the top of the interface: Options, Tools and Help.
Options includes sub-menus: Print Setup, Looping, Test Subset and App Directory.
Print Setup optionally prints the test report automatically upon test completion. The default is off.
Looping is not implemented.
Test Subset selects a subset of the tests to run. So, if you have a lot of tests that are very long you can choose to skip some of them. This relies on having an AppSequence file in the test application. Figure 10 shows what is in the AppSequence file.
The AppSequence file also allows dictating test dependency. For example, in Figure 10 if the user tries to run only the test TEST-Voltage_Test-00001.vi without running TEST-Model_Number-00001.vi (where 0 listed in the Dependent column is the Test ID of TEST-Model_Number-00001.vi) an error will be generated from the test executive.
The App Directory changes the default location the test executive looks when loading a test application.
All options in the Tools and Help menus are not implemented.
I won’t try to go over every detail of the code, if you are familiar with Labview I think it’s pretty simple.
Figure 11 shows the project explorer file DOT-TE.lvproj. The project is implemented in one main VI (DOT-TE_Main_UI.vi) with four directories contained all the sub-VIs (Dialog, Globals, Main Functions, Utilities).
Figure 12 shows the block diagram of DOT-TE_Main_UI.vi. It may be a little hard to see here, but this is just to see the general producer consumer style. The upper portion contains the event structure that sends a message to the consumer with every button or menu click. The messages are sent with a queue.
There is a lot that should happen to this code before it could be really useable. Right now it mostly just demonstrates the concept. There are several places that could be improved. There is no error handling to speak of. The System Messages on the front panel were not implemented. The system messages should be telling the user what’s going on, like when the test is running or the system is waiting on something. Some of the menu features are not implemented. There is very little documentation of the code.
A test executive is an important piece of software for a test organization to have in support of manufacturing. While off the shelf test executives exist, there may be cases where a custom design would be worthwhile. The DOT-TE test executive presented here is really about half way done, but it illustrates some important features for a test executive to have as well as some user interface coding concepts in Labview.