Author: Elijah Kerry, CLA
Last update: May 19th, 2018 (NIWeek 2018)
Overview of the Measurement Abstraction Framework
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:
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
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:
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
Additional Information
The following articles describe core design decisions of the original framework:
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.
Hi @Elijah_K,
I'm trying to look on your MAL framework, but get an error on som s\logger lib.
Can you point me in a direction to correct his error.
we don't use teststand or SYSTEMLINK, can you provide a example how to use MAL/HAL in plain LabVIEW 😉
ATTENTION: I know that several of you have commented about missing some VIs when you open the example.
The fix is simple: You need to install the SystemLink Client VIs for LabVIEW from the NI Package Manager!
I can make this simpler in the future through the use of JKI Dragon, but for now: please be sure to install these so you have the RabbitMQ API that the system uses for communication.
Hi.
I am trying figure out how the TestStand use the framework, read back values from the measurement. But when I launch the sample TestStand sequence, It seem to be missing the read Average Voltage.vi. And I guess that is where I can see how data is "transferred" to TestStand