LabVIEW Development Best Practices Documents
Author: Elijah Kerry, CLA
Last update: May 19th, 2018 (NIWeek 2018)
The attached code serves as a reference architecture for the core architecture of large-scale test and measurement systems, especially long-running tests that are commonly associated with the characterization and validation of a physical system.
The Measurement Abstraction Framework demonstrates solutions that address the following common requirements:
- Hardware Abstraction Layer(s): The de-coupling of hardware and instrumentation through a class interface that allows tests to be easily reconfigured to utilize different devices or vendors without modifying test code
- Measurement Abstraction Layer(s): The ability to change and override the default behavior and display of a measurement based on a class interface without modifying test code
- Channel and DUT Abstraction: The ability to map IO for a specific device to sensors or a DUT in a way that can be stored and referenced without specific knowledge of the device in use
- Factory patterns for plugins: Dynamic loading of new capabilities and functionality without modifying or even restarting the main framework
- Simplified test definition: How to enable the creation of tests by users who are not experts on the framework or advanced programming concepts like OOP
- Logging heterogenous data: How to stream data from multiple devices at multiple rates in a way that can easily be correlated and analyzed offline
- Storing/aggregating data in a central location: How to upload the data from tests to NI SystemLink for visualization and offline analysis
- Asynchronous actors: Usage of Actor Framework for a highly asynchronous system that allows multiple sub-systems to communicate while acting independently
- Configuration storage: how to store device and measurement configuration to disk for later reference, as well as how to pass this information to TestStand
- Simplification of TestStand: simplify test definition in TestStand through configuration-based workflows that employ custom step types
- Reusable across validation or production: the framework is designed to execute the same measurements and devices purely from LabVIEW or they can be sequenced and the channel names can be referenced from TestStand tests
- Remote execution of tests on RT targets: How to sequence the execution of tests running on a Linux Real-Time target from a Window Host running TestStand. Note: this functionality was available in previous versions but is not in the 5.3 release yet. It will be re-added after NIWeek
Example Overview
Version 5.0 has been used to build an EV Powertrain Validation test demonstration, which will appear on the Expo floor of NIWeek, as well as various locations around then world. The attached code includes the device plugins that were used for this particular application. Once installed, it can be run, but will almost certainly generate an error unless you happen to have the same hardware at your disposal. The primary reason these were included is to serve as helpful examples for how driver plugins should be written.
To run the example without hardware, we recommend simulating one or more DAQ devices for use with the Standard Measurement.
Setup and Installation
- Written and designed for LabVIEW 2017 SP1. Will be tested against LabVIEW 2018 after NIWeek
- The attached VIPC contains all of the necessary libraries required to run the framework, as well as one sample measurement plugin and device plugin examples for: DAQ, CAN, RMX Power Supply, Anderson Load, and a Thermotron thermal chamber.
- One installed, navigate in VIPM to the TestStand Interface for MAF package and click "Show Examples"
- Open the project in that directory and launch and run "TestStand Interface Test Harness.vi." Clicking the buttons in order will allow you to configure the controller, the measurement, apply system properties to the file and ultimately launch a and long a measurement
- Once this is working, launch the sample TestStand sequence file to call then framework from TestStand using custom step types
Extending or Customizing Measurements
The example measurement is installed by default to C:\ProgramData\Measurements
The included example only features one measurement, "Standard Measurement," which his a very basic implementation. However, it is possible to instantiate N instances of this type of measurement, which should cover most basic use-cases.
Reasons to override this measurement include:
- A custom measurement display is required when it is running
- A different interface is required for specific devices (all acquisition in this example uses "read N samples from N channels" for acquisition and "write N samples for N channels" for generation
- A specific measurement or enrichment operation is desired to be added to the data as it is acquired and included within the log
- A safety-critical measurement needs to be performed on the data (perhaps on an RT system) that is responsible for closed-loop control (ie: safe shut down)
- Measurement requires that a specific type of device be specified, which can be defined by overriding the method to request hardware
Extending or Customizing Hardware
The example measurement is installed by default to C:\ProgramData\Hardware
Unlike previous versions, all devices inherit directly from the base Hardware.lvclass object. The measurement device implements the acquisition and generation interfaces. Device plugins wrap specific drivers and are called used a basic "Configure --> Acquire --> Generate --> Measure --> Repeat until Close" sequence. A device can specify specific interfaces that they implement if requested by the framework, but the default is for a device to support "all" interfaces.
All devices have both common and unique configuration options. The common capabilities are stored in the base "HW Configuration.lvclass," but extended by their own implementation for unique properties
Future Updates / Known Issues
- Remote execution of measurements on RT target (available in previous 3.0 version)
- The ability to launch one central logger instead of a logger per measurement
- The ability to launch the results from the measurement window
- Distribution of plugins with SystemLink as NIPM packages
- Devices have to be selected in error or then framework returns an error
- The path to store logs has to be valid, or framework return an error
- Various performance improvements when acquiring
Additional Information
The following articles describe core design decisions of the original framework:
- Recommendations for Deploying LabVIEW Plugins in the Run-Time Engine
- Measurement Framework 3.0: thoughts on debugging a large Actor Framework system
- Introduction to Object Oriented Programming for HAL Design in LabVIEW
This framework is not officially supported by NI, but will continue to be improved and developed based on input and feedback. The original version of this framework was published in 2012.
