DMC developed a custom test software that allows customers to configure electrical and functional tests for the majority of their products. The total solution includes three major components:

1. “DMCquencer” test executive framework
2. SQL database, web portal for administration and reporting, and web API
3. Scripted code generation for communication protocol

DMCquencer Test Executive Framework

The customer required a flexible automated test system that could eventually expand to replace all manual production tests that are executed on a wide variety of electronic products. For test scenarios like this, DMC has developed a test framework called the “DMCquencer”. The “DMCquencer” is a reusable test executive architecture designed to sequentially execute code modules in user-configurable sequences. The customer can configure the code modules and execution order into customized test sequences for each of their individual products.

The “DMCquencer” framework uses LabVIEW object-oriented concepts to create an easily-extensible architecture. The core “DMCquencer” function provides many step types that are commonly useful (e.g. Wait, Display Message, Measure DAQ, If statement, For loop, etc.). For this project, we extended the core functionality by adding step types such as: measurement using the 3rd party instruments, communication with the DUT, and display processed data to the user for evaluation.

The application walks the operator through the following test workflow:

1. Login to the test stand.

   

2. Scan or enter the unit’s serial number. The software queries the database to identify and download the appropriate sequence file based on the model number.

   

3. Review the model number and sequence file to confirm the correct information has been entered. Click “Start Test” when the operator is ready to begin the test sequence.

   

4. The “DMCquencer” framework takes control and executes the automated sequence. If there are any steps that require human interaction (i.e. a visual inspection, or a button push that cannot or should not be automated), the customer groups these semi-manual steps at the beginning of the test so that the operator can complete them quickly and then move on to other tasks while the automated tests are executed.

   

5. If the “DMCquencer” encounters a test that fails, an alert sound plays, and the operator is informed which step failed. The operator may either retry or abort the test. If a test fails on a first attempt and subsequently passes on a retry, the operator is prompted for a comment to explain what changed (device was unplugged, memory card not inserted, etc.). 

   

6. If the DMCquencer completes the entire sequence, a “success” tone alerts the operator that the test is complete, and the overall result is displayed. All results are stored in the database.
7. The operator can then choose to retest the same unit or enter a new serial number to run another test.

SQL Database and Web Portal

A centralized SQL database serves two major purposes:

1. Store test configuration data so that all test stands use the same configuration.
2. Log test result data.

The SQL database was hosted on a local server and DMC wrote a web application that allowed the customer to interact with the data from any computer on their network. The web application was the front-end for the database, giving engineers the following capabilities:

• Manage test sequences – all test stands pull sequences from the database, allowing global updates without accessing each individual test station.
  • Add new products and models, and specify the sequence for the new product.
  • Update the test sequence for a given model number.
• Manage users and user permissions to control who can access the test stations.
• View data from tests
  • View a summary of test results for all units.
  • Examine detailed test results for an individual unit, including operator comments.
  • Graph historical data for a single measurement to help track trends across units.
  • Filter results by date, model/serial number, pass/fail, and test type.

Scripted Code Generation for Communication Protocol

One of the customer’s flagship products can communicate over a USB connection. This sophisticated product has hundreds of commands for device configuration, status, and control. Many commands have a custom data structure to send or receive the required information. The customer has extensive documentation of the commands and data structures.

Instead of manually programming hundreds of commands and data structures, DMC wrote a software script that parses the customer’s documentation and uses VI scripting to create the LabVIEW code to convert command data into the data packets that are sent or received. A major benefit of scripting the creation of this communication code will come when the customer needs to update their test system to accommodate an update to the device firmware. The script can be run on updated documentation and the code will automatically be updated.

Conclusion

The DMCquencer framework saved lots of development time while allowing DMC to deliver a powerful and flexible test system that meets the test requirements for a wide variety of the customer’s products. DMC’s knowledge of ASP.NET web applications helped us create an intuitive front-end for a database that stores the customer test configurations and results. The overall system can be extended and maintained to meet the customer’s future testing needs.