Case Studies

Flex Framework Workspace and Settings

Efficient Configuration Management with Flex Framework

Posted in LabVIEW, Test & Measurement Automation


A common challenge tackled by test systems is effective configuration management. Consider even a simple power supply. There may be configurations to ensure that the device is talking at the right Baud rate over the correct communications port. There are communication protocol configurations to ensure that the right messages are being sent for this model of power supply. There are also test configurations to ensure that the power supply ramps up and down to the required voltage and current levels. Finally, the power supply outputs could be logged to a specific folder during the test depending on what type of test is being run.

With so many configuration options, a robust solution is needed for configuration management in order to prevent burdensome setup time and operator error. The Flex Framework has a dual-configuration backbone that accounts for all these challenges. The System Settings maintains hardware and test-stand level settings, while workspaces ensure that proper configuration files are loaded for a unique application configuration.


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.

Typical Configuration Screen


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.

DUT 1.0 

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.

User interface for configuring workspaces

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.

Flex Framework configuration files

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.

Flex Framework configuration settings
*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).

DUT Abstraction Layer

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.

system state diagam mapping 

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.

Customer Benefits

DMC’s System Settings and Workspace work together to provide customers with the best test setup experience:  

  • Stores settings in separate files, maximizing re-use
  • Groups configuration files in meaningful ways with workspaces, reducing configuration time when switching in between different types of testing or products
  • Provides flexibility and modularity needed for future growth and expansion