System Settings

The most basic type of application setting is a system setting. These settings are usually static, or at least do not change frequently. While they may need to be changed from one test stand to the next, they usually will not change very often for a given set of hardware. These settings include:

• Test Stand ID
• Power Supply Type
• Communications Port
• Baud Rate

After setting these settings once, the user expects the application to load the last settings the next time they use the system. They also require the ability to change these settings without needing to make modifications to the source code.

DMC accommodates these types of settings through our System Settings Screen, shown in the figure below. The navigation buttons on the left expose different system settings that a user (with the proper permissions) can modify. The image sample features a typical configuration screen for a variety of power supplies, where the user can specify what type of power supply and what port the device is talking on.

Workspace

For simple applications, system settings may be enough to allow the end user to properly and easily configure a system. This is not the case for more complex systems that require multiple application configurations. An application configuration is simply a set of configuration data based on the Device Under Test (DUT) and Type of Test (i.e. – design validation vs production validation). It may also have additional factors. 

Consider DUT 1.0. It has its own test sequence file, communication protocol, hardware parameters, and logging directory. All of these are specific to DUT 1.0 and are saved as individual files to improve modularity and keep file size manageable. This is represented in the next figure.

DMC’s Workspace solution is the backbone of configuration management of the Flex Framework. It is a generic structure that allows a user to create a one-to-many relationship between a Workspace name and these specific configuration files/folders. These groupings of related configuration files/folders define a given application configuration. 

An example of what the user interface for configuring workspaces might look like is shown below.  The end user simply created or edits an existing workspace and links it to configuration files for the various aspects of their application. Workspaces and the associated file paths are stored as application data so the operator can load a saved workspace at any point in time, resulting in shorter setup times.

The full power of the workspace can be seen when multiple application configurations are needed. In the example we were just using, the end user needed to test DUT 1.0. Now consider another product they want to test, DUT 2.0. This new product could have a new test sequence, communication protocol, DUT parameters, and logging directory. 

Take this one step further and consider a new version of DUT 2.0, call it DUT 2.1. Maybe this new version has the same communication protocol and hardware parameters but needs to be tested in a different way and store the results in a different location on the network. 

The diagram below shows the unique aspects of each DUT, as well as the shared configuration between DUT 2.0 and DUT 2.1. By storing these configurations in their own files, the Flex Framework can re-use the Communication Protocol and DUT Parameter configuration files between DUT 2.0 and DUT 2.1.
 

That’s the advantage of having multiple configuration files. Yet this would still leave the user with the problem of needing to load in all these different files throughout the day. Every time the DUT changes, the application configuration (and all the associated configuration data) needs to be loaded along with it. Without DMC’s Workspace solution, the end user would change these configured files/folders manually many times a day. 

However, if the user sets up Workspaces for each of these application configurations, all they need to do is select which workspace they want and all the configuration files that are linked to it load in. The active workspace is stored in the System Settings file, which allows the System to boot up using the last-specified Workspace. It’s a seamless configuration experience for the end user that maximizes flexibility while minimizing setup time.

*Click to see larger version

Device Under Test Configuration

A common challenge to test stands is that they often need to support multiple DUT products/models. Each DUT may have its own hardware configuration or specifications. Take for instance, a product that always needs to be tested at 12V versus another product that needs to be tested at 24V. There are any number of parameters related to a specific product that the test system may need to know about to be able to properly run a specified operation or measurement.

That’s why DMC has developed a DUT abstraction layer. It is a design pattern that allows the program to react to different DUTs within tests according to parameters associated with the DUT. These parameters are contained with DUT files that are configured by the end user (as shown in the UI Below).

Each DUT file can have any information that is specific to a product. Instead of lumping this configuration data into System Settings, which would need to get changed every time the DUT is changed, a separate file that encapsulates all the DUT Configuration data is used. This way, whenever a user wants to change the DUT, they just need to select from a list of previously configured DUTs and it loads all the stored settings.

One simple example of how this works is with hardware IO. For instance, most DUT’s will have some physical IO that needs to map to generic IO exposed by the test stand. So, a test stand might have DUT1-A, DUT1-B, DUT1-C, etc. on a DUT connector, but this gets connected to specific signal lines on a product. The DUT configuration file allows the user to associate the generic IO of the test stand to the product-specific IO of their DUT. The System State diagram on the test stand can then display the mapping depending on which product is loaded.

These features are part of a powerful suite of tools called the DMC Flex Framework. Find out more about all of these tools here.

Learn more about DMC's LabVIEW expertise.