LabVIEW Hardware Abstraction
The Hardware Abstraction Layer (HAL) works by grouping together devices that perform similar functions or require the same configurations from the user, and grouping them under a single API. With this HAL, adding a new device model only requires writing the lowest level drivers specific to that device. All the higher-level interaction with the rest of the application is taken care of by the hardware abstraction layer.
As a result, the cost of upgrading and maintaining test systems over time can be greatly reduced. New test devices can be easily added, and deprecated ones can be easily removed.
Another important feature this standardization provides us is any user or engineer can have the capability to select or configure the hardware to be used for a given test. This hardware can be hot-swapped with other supported units of the same family, and no programming team is needed for the change!
What Does it Look Like?
Pictured below is an example of the settings configuration tab. This interface allows any user with appropriate credentials to make all necessary hardware and software setting changes. This menu can be tailored to contain settings particular to each customer.
How is it Done?
DMC establishes the hardware abstraction layer in LabVIEW using object oriented techniques. Each unit within a family of devices (a National Instruments Power Supply [PS] within the PS family) can inherit from a common ancestor. The common ancestor defines an application-programming interface (API) and an interface which is typically shared by all children classes. For the purpose of exploring the concept, we will examine the hardware abstraction layer of a power supply.
The abstract power supply class, _Power Supply.lvclass, defines the set of interactions a user or piece of code can have with a generic Power Supply (e.g. Command Voltage, Command Output State, etc.). These API calls point to blank pieces of code, with the intention that a child class will override these stubbed out API implementations.
DMC makes use of LabVIEW’s dynamic dispatch functionality to call the correct child class’s implementation of an API at runtime. This allows for the programmer to drop in a ‘Command Voltage – API’ and not worry about which device type is implementing the call at runtime.
In addition to a standard set of API calls, devices which inherit from the _Power Supply.lvclass can take advantage of a standardized control interface (shared and implemented at the parent _Power Supply.lvclass level).
The _Power Supply.lvclass’s Interface
Each button on the interface makes an API call, allowing the children classes to push data to the interface for users to view. This shared interface allows for users to interact with a variety of Power Supply types without needing to know which exact type of Power Supply is connected, providing for a familiar user experience while maximizing code reuse across an application.
This architecture has proven useful for customers who have multiple units of devices within a family of instruments by allowing programmers to program to an abstract class’s API instead of to a specific class’s implementation, enabling programmers to develop faster and more efficiently.
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 programming expertise.