Table of Contents

• Customer Benefits
• Flex Blocks and Flex Coordinators
• Ethos Behind the Flex Framework
• Standout Flex Blocks and Code Features
• DMC Module
• DMC Device
• Typical Application Module/Device Lifecycle

Customer Benefits

Open Solution: DMC can provide clients with license-free source code, allowing clients to extend or explore the code.

Extensible: DMC’s Flex Framework is based on a proven, scalable, LabVIEW Object-Oriented architecture.  This allows for DMC engineers or clients to add pieces/functionality to an application while keeping the overarching application architecture managed and maintained, enabling faster development.

Re-Usable CodeBase: Solutions start from a vetted architecture and drivers proven out over multiple projects, instead of re-creating integration logic.  Projects also get the benefit of improved supportability as DMC continues to advance and improve the Framework, which can benefit any project that uses the architecture. 

Modular Design: The Flex Framework consists of a collection of stand-alone software packages, which have the potential to be utilized outside of the Flex Framework or extended within the Framework. 

Flex Blocks and Flex Coordinators

DMC’s Flex Framework consists of two key elements:

• Flex Blocks
  • Component pieces that perform an action in an application. Some examples are:
    • Digital Multimeters
    • Power Supplies
    • Graphing Displays
    • DAQmx cards
    • XNET/CAN cards
    • HMIs
• Flex Coordinators
  • Constructs which integrate, manage, and build the Flex Blocks into a focused solution

Flex Coordinators, such as the Test Stand class, pull from the library of Flex Blocks to create a tailored solution for each client.  Flex Coordinators are the ‘brains’ behind the application and serve as the string that ties the Flex Blocks into a functioning software package.

Flex Blocks modularize one task, device, or feature set, and are designed to be agnostic of other Flex Blocks wherever possible.

Ethos Behind the Flex Framework

The Flex Framework provides a tested and proven starting point for projects eliminating the development time it would take to build up these capabilities from scratch. Furthermore, it establishes a modular design pattern which enables developers to adapt and expand the Flex Framework to client requirements.

Common Code

Common code, such as device drivers, do not need to be re-written for each new solution or project. Instead, DMC has developed this code once to be shared and improved in a single location so many of our clients and projects can benefit from future changes or feature additions.

Hardware Abstraction Layer

It’s common to have many different brands and types of COTS devices in a test system, but many of them do nearly the same thing. For this reason, interaction with individual devices (i.e. Digital Multimeters (DMMs), Power Supplies (PS)) has been abstracted in more general classes. Children of these LabVIEW abstract classes implement specific methods to add device-specific functionality and meaning to the parent’s method. For example, an abstract parent “_Power Supply” class provides a common interface for all Power Supplies, but the children of this class (Agilent HVPS, Lambda ZUP power supply, RMX power supply, etc.) implement the hardware-specific drivers and communication protocols through which the interface acts.

Multi-project interface coherence

Each test system may have unique characteristics, but it’s usually desirable to retain commonality in the underlying code modules, LabVIEW user interfaces/user experience (LabVIEW UI/UX), and system design. This enables users to have a consistent experience when moving from one test station to another (i.e. EOL Test Station, R&D Test Station). There are also programming benefits since ramp-up on a new project that leverages the Flex Framework is quicker and lowers overall development cost.

Code Modularity

The Flex Framework has code modules that are as independent as possible, allowing them to be re-used without dragging unwanted dependencies into a project. DMC Flex Blocks are agnostics of the existence of other Flex Blocks. Only the Flex Coordinator knows about each Flex Block included in the application. This software encapsulation and modularity keeps code more maintainable over time, which provides greater value to end-users of the Flex Framework.

Standout Flex Blocks and Code Features

DMC’s Flex Framework has many Flex Blocks and features which we have explained in separate case studies:

• Alarm Handling
  • Provides traceability for system faults and notifications
  • Allow for system recovery from faults or errors
  • Standalone toolkit
• User Access Levels
  • Easy to integrate toolset which keeps track of user permission levels
  • Simple to extend and tailor to customer’s user role definitions
• Data Logging/Reporting Capabilities
  • Flexible logging utility
  • Live feedback of user-configured, graded, testing parameters in LabVIEW
  • Standalone toolkit
• DMC Grid Viewer
  • Dynamic test interface configuration
  • Subpanels any LabVIEW VI and allows for drag-and-drop interface configuration
  • Standalone toolkit
• Tailored User Workflows
  • Application-specific interfaces and implementations to tailor the Flex Framework to exact customer needs
• Manual/Automatic Control Modes
  • LabVIEW Testing automation abstractions
  • Automated running of pre-configured testing routines
  • Manual testing support, for in-depth engineering diagnostics
• Configuration Management with Workspaces and DUT construct
  • Configuration Management
  • Single click switching of Device Under Test (DUT)-specific configurations
• Test Execution with the DMCquencer
  • LabVIEW Test Execution Engine
  • Test automation
• Built-In Diagnostics
  • I/O Checkout Routines
  • System self-diagnostic check
  • Diagnostic Logging
• Hardware Abstraction Layer
  • Test stand hardware hot-swap support
  • LabVIEW design pattern

DMC Module

DMC Flex Framework’s LabVIEW Object-Oriented architecture is based on a lightweight class named the DMC Module.  Most of the classes in the Flex Blocks group are grandchildren of the DMC Module class.  Modules are independent pieces of code responsible for a particular function.

DMC Modules introduce the concept of a ‘Module Command.’  These commands are used to capture a given Module’s API usage, keep track of the data modified by those API calls, and provide a level of traceability to an application.

Additionally, the Module class allows for the definition of daemons and/or interfaces which the Module may use to meter out tasks, maintain heartbeat communication with a device, or provide a user interface for an operator.

DMC Modules are typically software constructs which don’t have physical manifestations (i.e. database loggers, file writers, and data processing tools)

DMC Device

The DMC Device class inherits from the DMC Module class and is its most commonly used child.  DMC Devices add one additional piece of functionality: variable publishers.  Most classes in the Flex Blocks group are children of the DMC Device class.  Like Modules, Devices are meant to be independent pieces of code (i.e. they do not interact with or know about the existence of other DMC Devices).

Variable publishers are used in the Device Command architecture (which draws from the DMC Module Command architecture).  If a device API is called with the Device Command constructs, then the class is able to post ‘modified’ variables to a registered variable publisher.

Keeping track of modified variables allows for a single place in an application to monitor variables (an example of this could be a Current Value Table).  DMC uses this collection of device variable values to monitor the health of a test system, abort automated testing if a variable violates a safe operating range, and centralize reporting of system variables through the application’s lifecycle.

DMC Devices are usually classes which interact with physical hardware (i.e. digital multimeters, power supplies, relay modules, DAQmx hardware). 

Typical Application Module/Device Lifecycle

Many of the projects which utilize the DMC Flex Framework follow a common pattern:

1. Application is launched
2. User configures settings
3. The user chooses to run an automatic test or manually interact with the system (Manual Mode or Automatic Mode)
4. The testing Mode (Manual or Automatic) is active until the test finishes or the user clicks ‘Abort’
5. The system goes to an idle state
6. Repeat Steps 2-5 as needed
7. Application is closed

To accommodate this application lifecycle, a corresponding Module/Device lifecycle is managed by the Flex Coordinators by breaking the Modules/Devices into two groups:

• Eternal Modules/Devices
  • Active through the entire application lifecycle
  • Examples include interlock monitoring devices, database connection modules, etc.
• Session Modules/Devices
  • Active during the testing mode only. Constructed/initialized when the test begins and terminated/disposed of when the test mode completes
  • These are typically constructed on application start and parameters pulled from a System Parameters file, but then are disposed of and re-constructed when a test begins
    • This is done to capture any settings (and subsequent System Parameter file) modifications prior to starting a test

An example lifecycle of both Eternal and Session Modules/Devices are shown below.

National Instruments / LabVIEW Experience

DMC has been a National Instruments (NI) Alliance member for over 10 years with one of the largest teams of Certified LabVIEW developers in the country, including several National Instruments’ Certified LabVIEW Architects (highest level of certification available), and multiple NI Certified LabVIEW Developers.

DMC is proud to be recognized as a National Instruments Alliance Partner. Learn more about DMC’s National Instruments partnership and contact us today to find the Flex Framework solution that’s right for you.

The post DMC Flex Framework: A Flexible LabVIEW Toolset appeared first on DMC, Inc..