A typical automated test system has several layers: The first is the interface to the device under test (DUT), which adapts the test system’s connections to the DUT’s specific form factor. Then there’s the signal conditioning layer, which adjusts instrumentation signal levels to match those required by the DUT. After that, there’s the instrumentation layer itself, responsible for generating or measuring signals such as digital I/O, analog I/O, communication buses, power buses, or arbitrary waveforms. 

Finally, there’s the switching architecture layer, which routes signals from the instruments out to the DUT. This layer is the focus of this discussion. 

The switching layer plays a critical role in both reducing cost and improving flexibility. It can dramatically reduce the amount of instrumentation hardware required while allowing the test system to maintain a common test interface that automatically reconfigures itself for multiple DUT variants. Switching can also improve throughput, enabling parallel testing of multiple units or rapid reconfiguration between tests. 

In addition, a well-designed switching architecture can give development engineers deeper insight into their systems by allowing many test points to be accessed by a shared set of instruments. 

Basic Switching Blocks 

Before diving into specific switching architectures, it’s helpful to review two fundamental building blocks that form the basis of most switching systems: the switch matrix and the multiplexer (mux). 

Switch Matrix 

The first building block is the switch matrix. You can find a more detailed discussion of switch matrices in this post, but in general, a switch matrix can be thought of as a many-to-many connection block. It allows any signal present on its interface to connect to any other signal on the same interface. 

Switch matrices are typically characterized by two main features: 

• Number of signal interfaces: how many individual signals can connect into the matrix. 
• Number of signal buses: how many common signal lines those interfaces can be routed onto. 

Matrices are often described using these dimensions. For example, the “14×4 matrix” shown below provides 14 interface signals (represented by the vertical lines) and 4 signal buses (represented by the horizontal lines), allowing flexible interconnection between multiple instruments and DUT channels. 

Multiplexer

The second fundamental building block is the multiplexer, or mux. A multiplexer provides a one-to-many or one-of-many connection path. 

For this discussion, there are three specifications to pay attention to: 

• Channels: the number of output paths the input can be connected to. 
• Banks: groups of channels that can be switched independently. 
• Poles: the number of conductors switched together (for example, a single-pole or double-pole mux). 

A simple example is a three-channel, single-pole, single-bank mux, which allows a single input signal to connect to any one of three output channels. 

It’s important to note that not all multiplexers behave the same way. Some allow the input to connect to more than one output simultaneously, while others restrict it to a single output. For the purpose of this article, we’ll assume a multiplexer can connect a signal to none, one, or more than one output channel, depending on design. 

Other Basic Blocks 

To help illustrate the switching architectures discussed later, the following schematic symbols will be used. 

Real World Architectures 

A Simple Switch Matrix 

Use Case 

This is one of the simplest and most straightforward switching architectures, but also one of the most common and powerful. It forms the foundation for DMC’s Helix SwitchCore platform and served as the base architecture for a Mobile Calibration Test Stand (MCTS). 

Despite its simplicity, this design provides a great balance of flexibility, scalability, and maintainability, making it ideal for systems that need to test multiple variants of a product or perform parallel testing. 

Switching Architecture 

In this architecture, DUT signals and instrument signals share the same switch matrix. The matrix is selected to provide the appropriate number of buses and interface connections based on the test requirements. 

For example, the MCTS system implemented a 64×12 switch matrix, providing: 

• 64 interface signals to accommodate multiple DUT configurations, and 
• 12 signal buses for routing measurement and power signals across multiple devices. 

The system included multiple digital multimeters (DMMs) and programmable power supplies connected through the matrix. This setup allowed the system to test up to four DUTs simultaneously or quickly reconfigure itself to adapt to different DUT pinouts. 

Architecture Benefits 

• Simple: A single switch matrix handles the entire routing scheme, and no additional routing layers are required. 
• Expandable: The initial system used a 64×12 matrix, but the design allows for expansion simply by adding additional matrix modules. DMC’s SwitchCore architecture can be expanded to support thousands of signals, as in this implementation. 
• Configurable: Any instrument can be routed to any DUT pin, making it easy to add new instruments or modify DUT configurations without requiring a complete redesign of the test system. 

Voltage Isolation Multiplexer 

Use Case

This architecture was used on a Power Distribution Unit (PDU) End-of-Line (EOL) Test System that supported testing for an entire family of power distribution units. 

One of the required functional tests was a high-potential (hipot) test up to 700 VDC. However, several other tests on the same DUT pins required low-voltage instrumentation. To further complicate matters, the system also needed to support multiple product variants, each with different DUT pinouts and electrical specifications. 

Switching Architecture

To meet these requirements, this switching architecture built upon the simple matrix design by adding a layer of high-voltage multiplexing. 

The multiplexer layer enabled safe high-voltage testing—such as hipot tests—while maintaining the flexibility to route low-voltage signals to the same pins. It also provided isolation between high- and low-voltage paths, protecting sensitive instruments during high-voltage operation. 

From a cost perspective, the flexibility of the matrix was critical. Rather than multiplexing every signal line, only the 12 DUT pins requiring high-voltage capability were routed through the high-voltage mux. The remaining 24 signals connected directly to the matrix. This selective approach reduced hardware costs by limiting expensive high voltage switching components to only the lines where they were needed, without sacrificing system adaptability. 

In this configuration: 

• The DUT signals first passed through a high-voltage multiplexer with 12 banks of two channels each. 
• The DUT interface supported up to 36 pins, with 12 routed through the high-voltage mux for hipot testing and the remaining 24 connected directly to the switch matrix. 

This architecture preserved the reconfigurability of the base matrix design while adding high-voltage capability and cost efficiency—all within a single, unified system. 

Architecture Benefits 

• High-voltage isolation: Enables high-voltage testing functionality without sacrificing access to DUT pins for low-voltage measurements. 
• Integrated hipot testing: Combines what are often two separate test stands (functional test and hipot test) into a single system, eliminating an extra manufacturing step and improving throughput. 
• Cost-effective design: By routing only necessary lines through the high-voltage multiplexer, the design minimized the number of costly HV switching components required. 
• Configurable and scalable: Maintains full flexibility to support multiple product variants and adapt to future test requirements. 

Distributed Multiplexing for Single Point Measurements and Monitoring 

Use Case 

In development test systems, engineers often need the ability to probe various signals throughout a system during debugging or validation. This is commonly done using a handheld digital multimeter (DMM). However, as systems grow to include hundreds or thousands of signals, manual probing quickly becomes impractical, time-consuming, and error prone. 

Hand probing also introduces risks: it can break configuration integrity or even violate procedural control requirements, particularly in aerospace and safety-critical applications. To address these challenges while maintaining flexibility and automation, a distributed multiplexing architecture can be implemented. We most recently leveraged this for a project using our Auto-BOB architecture. 

Switching Architecture 

This is one of the most complex switching topologies, using a multilayered approach to balance flexibility, scalability, and cost. 

While large switch matrices can provide ultimate routing freedom, they become expensive as channel count grows. By introducing layers of multiplexing, the system maintains the core configurability of a switch matrix but significantly reduces costs through signal down-selection using lower-cost multiplexers. 

This approach pays off particularly for very high channel-count systems, where the total number of signals can reach hundreds or thousands. 

To enhance reliability and safety, this architecture often employs specialized monitored multiplexers that can verify the switch position and ensure no inadvertent shorts occur within the system. 

Each DUT signal passes through multiple multiplexers, with each multiplexer creating its own measurement bus. This effectively gives each DUT signal multiple probe or measurement points that can be dynamically routed to instrumentation. Only one signal can occupy a measurement bus at a time, but by distributing signals across several buses, engineers can measure any two points in the system through the shared switch matrix. 

In one implementation, each signal group was tied to two measurement buses. For example: 

• Measurement buses A and B serve Signal Group 1. 
• Measurement buses C and D serve Signal Group 2. 

Because each multiplexer handles multiple DUT signals, a single signal must connect to two separate multiplexers to enable pairwise measurement while maintaining isolation. These selected signals are then routed back to the switch matrix, which connects to all instrumentation (DMMs, power supplies, etc.). 

An additional advantage of this design is its distributed nature. The multiplexers can be physically separated from the main switch matrix enclosure, with local multiplexers housed near DUT interfaces and the matrix located near shared instrumentation. This setup allows multiple test systems to share the same pool of measurement instruments, further reducing equipment cost and improving overall utilization. 

Architecture Benefits 

• Highly scalable: Supports systems with hundreds or thousands of signal channels without requiring massive monolithic switch matrices. 
• Cost-efficient: Reduces high-density matrix requirements by layering lower-cost multiplexers for signal selection, minimizing total hardware expense. 
• Flexible and configurable: Allows any two points in the system to be connected for measurement, supporting a wide range of development and diagnostic tests. 
• Improved safety and reliability: Monitored multiplexers verify switch positions and prevent inadvertent shorts or misconfigurations. 
• Distributed design: Enables instrumentation to be shared across multiple test systems, reducing overall equipment investment and maximizing utilization. 
• Supports automation and repeatability: Eliminates the need for manual probing, improving consistency and compliance in regulated or high-complexity environments. 

DUT Multiplexing for High Throughput End of Line Test 

Use Case 

In a manufacturing environment, throughput matters. In DMC’s Automated Photodiode Tester Application, multiplexers and switch matrices were combined to enable batch testing of up to 48 devices under test (DUTs). Multiplexers cycled through each DUT to perform functional testing, while a shared switch matrix handled instrument routing. This combination allowed the system to test multiple DUT variants with different interfaces and specifications using a common hardware platform. 

Switching Architecture 

This system used a 24-channel, eight-pole multiplexing card to select one of 24 DUTs. Each DUT had eight pins, with each pin connected to a separate pole of the multiplexer. Because the multiplexer provided 24 channels with eight poles each, a single mux card could support up to 24 DUTs. 

By adding a second identical card, the system expanded to 48 DUTs total. The outputs of the multiplexer cards were routed into a switch matrix, which connected to the functional test instrumentation. 

To achieve higher throughput, duplicate instrumentation and matrix modules were added to the system, one for each multiplexer card, allowing the system to operate in parallel. This configuration enabled testing over 300 DUTs per hour, dramatically increasing production efficiency while maintaining flexibility across product variants. 

Architecture Benefits 

• High throughput: Parallelized multiplexing and shared instrumentation allowed testing of dozens of DUTs simultaneously, achieving over 300 units per hour. 
• Scalable and modular: Additional multiplexer cards or matrix modules can be added to increase capacity or support new product families. 
• Efficient use of instrumentation: Shared matrix routing maximizes the utilization of costly test hardware, minimizing total equipment investment. 

Multiplexing for Differential Serial Bus Electrical Verification 

Use Case

This is a niche but fascinating application of switching architecture. Integration engineers often verify data integrity on serial communication buses, but sometimes it’s also necessary to capture and analyze the electrical characteristics of the signal itself. 

This poses unique challenges. Serial buses often operate at data rates exceeding 1 Mbps, where any additional loading, attenuation, or reflections introduced by the test system can degrade signal quality. In these cases, the test setup must be designed to minimize its electrical impact, because it’s the signal quality itself, not just the transmitted data, that’s under evaluation. 

Architecture 

Testing multiple serial buses compounds the difficulty. To address this, DMC implemented a stubless multiplexing architecture designed to preserve signal integrity while allowing automated electrical verification and waveform capture. 

The system was constructed using several double-pole, double-throw (DPDT) relays, each acting as a two-channel, two-pole multiplexer. By chaining these relays in a tree configuration, the architecture could select any one of several serial buses to route to an oscilloscope for signal capture. 

When a bus was not selected, its signal passed directly through the system without interruption, allowing all buses to continue normal communication. When a bus was selected, its signal was routed up to the oscilloscope while simultaneously passing through the test system and back out, enabling real-time monitoring without disrupting communication. 

This design minimized the formation of stubs on the communication lines, which is critical for maintaining clean signal edges and preventing reflections that can corrupt high-speed signals. 

Architecture Benefits

• Preserves signal integrity: The stubless relay topology minimizes reflections and loading, ensuring accurate electrical characterization of high-speed differential signals. 
• Enables real-time testing: Signals can be captured while communication continues uninterrupted, allowing engineers to validate bus behavior under true operating conditions. 
• Automates complex measurements: Multiplexed relay control allows seamless switching between buses for waveform capture, reducing manual reconnections and improving test throughput. 

Conclusion 

Switching architecture might not always be the flashiest part of a test system, but it’s often what determines how flexible, scalable, and future proof that system can be. From simple switch matrices to complex multi-layer multiplexing and distributed setups, each architecture offers a different balance of cost, capability, and control. 

In development environments, flexibility can mean the difference between a day and a week of reconfiguration. In production, smart multiplexing can translate directly into higher throughput and lower test costs. And in specialized electrical verification setup, like high-speed serial bus testing, the right switching design can be the difference between reliable measurements and misleading results. 

At the end of the day, the best architecture isn’t always the most complex: it’s the one that fits your goals, scales with your products, and keeps your test system adaptable for whatever comes next. Thoughtful switching design doesn’t just connect instruments and devices; it connects your entire test strategy to long-term success. 

The post Examining Switching Architectures of Automated Test Equipment appeared first on DMC, Inc..

The magnet was part of the SPIRAL2 facility, which came online in 2019 to support nuclear physics and nuclear medicine research. My role was to design and implement the control application for the superconducting magnet system. This project combined real-time control, cryogenics, and some truly elegant physics, and it remains one of my favorite engineering experiences. 

What Is a Superconducting Magnet?

A superconducting magnet is, at its core, an electromagnet built with superconducting wire. A material that, when cooled below a critical temperature, has zero electrical resistance. 

In a conventional electromagnet, large currents are required to generate the strong magnetic fields needed to steer or focus a particle beam. However, large currents also produce heat due to resistive losses in the copper windings. To handle that heat, you need thick wire, but thicker wire makes it harder to pack enough turns into the coil to get the desired field strength. It’s a classic engineering catch-22. 

Superconductors solve this problem beautifully. Once cooled below their critical temperature (often below 10 Kelvin, and sometimes as low as 4.2 K in the case of the liquid helium we were using) the material carries large currents with essentially no losses. The result is a magnet capable of producing enormous field strengths in a compact design. 

Quench Detection: Preventing a Chain Reaction

Superconductors do come with their own challenges. If any part of the magnet warms above its critical temperature, the material suddenly becomes resistive again. This transition, called a quench, causes rapid heating, which can boil the surrounding liquid helium, increase pressure, and if uncontrolled, lead to catastrophic failure. 

To prevent that, the system includes a real-time quench detection algorithm that monitors temperature and voltage throughout the coils. If a potential quench is detected, the system safely vents the helium and ramps down the current to prevent damage. 

Part of my job on the project was integrating this monitoring logic and ensuring that the magnet could transition safely in and out of its operating state without triggering false alarms or damaging the cryostat. 

The Cool Part: Controlling Current in an Ideal Inductor

From a controls perspective, this was where the project got really exciting. 

In most electrical systems, you can’t ignore resistance —it’s what turns voltage into heat. But in a superconducting magnet, resistance drops to zero, so the magnet behaves almost like an ideal inductor. 

That means we can use the familiar equation: 

V = L (di/dt) 

to directly control the rate of change of current simply by adjusting voltage. Rearranging gives: 

di/dt = V / L 

This relationship means a small, precisely controlled voltage allows us to ramp current smoothly to hundreds of amps with incredible precision. This is just like pressing the accelerator pedal in a car to control speed. The current in the magnet directly determines the field strength, so voltage control gives us a precise handle on the beam-steering field. 

The Control Algorithm: Ramp and Hold 

The control algorithm had two key responsibilities: 

1. Ramp the magnet current at a precise, limited rate to prevent quench conditions. 
   If the current increased too quickly, it could cause localized heating and trigger a quench. Preventing that avoided costly downtime and helium loss, since recovering from a quench event can take hours or even days while the system re-cools to cryogenic temperatures. 

2. Hold the magnet current at a stable value to maintain the desired field strength. 
   While the magnet coils themselves are superconducting, the power leads and cables connecting to the magnet are not — so small voltage adjustments are still needed to compensate for resistive losses. It’s like keeping your foot gently on the accelerator to maintain cruising speed. 

Deployment at GANIL

After several months of development and testing, we deployed the control application at the GANIL SPIRAL2 test facility in Caen, France. Once the control and quench detection systems were validated, the team moved forward with commissioning the remaining magnets. 

Seeing the system perform as designed, holding enormous currents stable within fractions of an amp and responding safely to temperature changes, was a deeply rewarding moment. 

Today, that superconducting magnet is part of an operational research facility contributing to advances in nuclear medicine and fundamental physics. It’s a great example of how precise controls engineering can help enable groundbreaking science. 

Engineering at DMC involves all kinds of projects, many of them in R&D like this one. I’ve found that some of the most innovative solutions come from combining our controls programming expertise with the amazing scientists at places like AML and ANL.

The post Controlling a Superconducting Magnet for a Particle Accelerator appeared first on DMC, Inc..

Emerging network security requirements now demand continuous patching and updates. Add to that regular calibration schedules, hardware upgrades, and software enhancements, and it’s easy to see how maintenance can consume significant time and resources. Yet, one of the most underestimated time sinks is often system re-validation—verifying that test, support, or HIL systems continue to perform correctly after every change or update.

Reducing this re-validation burden and keeping teams focused on their core development and operational tasks is critical. That’s where DMC’s Helix SwitchCore platform comes in.

Helix SwitchCore is a configurable, expandable hardware platform designed to automate and streamline system validation. It provides a flexible foundation for test and support environments, helping organizations maintain compliance, reliability, and performance with less downtime and manual effort.

This article takes a closer look at the Helix SwitchCore platform—its key features, adaptability, and how it can simplify validation and certification workflows across a wide range of applications.

System Overview

The Helix SwitchCore platform is designed to adapt to a wide range of test environments through its configurable hardware architecture and modular design.

Configurable Test Interfaces

Every test system has unique interface requirements, and SwitchCore is built to meet them. Whether your application uses MIL-DTL-38999 or other circular connectors, VPC or mass interface connectors, or rectangular formats such as D-subs, the system can be configured to match your existing infrastructure. This flexibility enables seamless integration with both legacy and modern test systems.

Expandable Switching Architecture

At the core of the Helix SwitchCore platform is an expandable switch matrix that enables software-configurable I/O routing. This architecture allows users to dynamically reconfigure test connections without manual rewiring, improving flexibility and reducing setup time. 

The system supports two distinct measurement bus configurations—2A or 10A—each with built-in overcurrent protection. This capability lets the same hardware platform be adapted to different current levels and safety constraints, minimizing the need for custom hardware variants. 

Scalability is another key feature: the platform can support anywhere from 32 test points to over 1,000, depending on system requirements. Its modular power bus and test point configuration options allow engineers to balance cost, performance, and functionality, ensuring the platform fits a wide range of test and validation applications. 

Integrated and Expandable Instrumentation

Helix SwitchCore can be equipped with a range of instrumentation, including programmable power supplies and loads, oscilloscopes, function generators, analog and digital I/O, and serial bus controllers such as RS-422, MIL-STD-1553, and CAN. Its modular design enables the platform to scale and evolve with your test requirements, reducing the need for separate, dedicated test setups.

Smart Host Control and Integration

An integrated host controller monitors instrument status, executes user-defined sequencing functions, and exposes a comprehensive API for easy integration into existing test executives or software architectures. To the end user, the entire platform behaves as a single, unified instrument—simplifying control, configuration, and automation. 

Portable and Cost-Effective

The compact, mobile form factor of the Helix SwitchCore platform makes it easy to move between test stations or store when not in use. This portability helps reduce overall instrumentation costs by maximizing utilization across multiple projects or departments.

Conclusion

As test and support systems grow more complex—and as cybersecurity, compliance, and uptime demands increase—the need for flexible, maintainable, and easily validated hardware platforms becomes essential. The DMC Helix SwitchCore platform was developed to meet that need. 

By combining configurable I/O, expandable instrumentation, and intelligent control, Helix SwitchCore helps teams streamline re-validation, simplify integration, and reduce overall test system lifecycle costs. Its modular design allows lab managers to balance functionality and price, scaling the platform to match immediate project needs while preserving a path for future expansion and technology updates. This adaptability helps organizations make more innovative use of both their capital budgets and engineering resources, minimizing downtime and avoiding costly redesigns as requirements evolve. 

Whether you’re managing an R&D lab, maintaining ground support equipment, or operating production test systems, Helix SwitchCore provides a scalable foundation that adapts as your operational and technical demands change—allowing your team to stay focused where it matters most: on development, innovation, and mission success, not maintenance overhead. 

See How Helix SwitchCore is Being Used

• Modular Hardware-in-the-loop Systems with Shared Test Equipment
• Mobile Calibration Test Stand

The post Configurable Hardware Platform for Validation of Ground Support Equipment and HIL Test Systems appeared first on DMC, Inc..

How do you plan for these changes in your code? How do you structure your code to minimize changes when test equipment changes? One way to help is to implement a hardware abstraction layer.

In this blog, we will look at implementing a simple hardware abstraction layer for Digital Multi Meters using LabVIEW Object Oriented Programming. We’ll assume that you are familiar with how to create classes in LabVIEW and have a basic understanding of object-oriented programming. If you need a refresher, here’s how to use LVOOP.

What is a Hardware Abstraction Layer?

The hardware abstraction layer helps to separate the section of code that manages and coordinates different pieces of test equipment from the section of code that interacts with each piece of test equipment. For a more detailed explanation, check out our case study about the benefits of a hardware abstraction layer. Hardware abstraction layers are also part of our Flex Framework suite of tools. 

Why use a Hardware Abstraction Layer?

Consider the following example. You need to develop a test that takes voltage and resistance measurement of a device under test and determine if those measurements are valid. Your applications must support two different types of Digital Multi Meters (DMMs). Each DMM has a different communication interface, and each has a separate command for specifying which measurement to take.

The example below is one way you could implement this method. Each DMM is represented in its own class, DMM1 and DMM2, that apply different methods for each measurement type. Depending on which DMM type is selected, you call the appropriate method on the appropriate class. Consider what would happen to this code if you needed to support more DMM types. What would happen if you needed to take more voltage measurements? What if you needed to test the ‘Pass’ method without any hardware? This code will get messy in a hurry.

Implementing a hardware abstraction layer can simplify this codebase. To do this, we need to think about what is going on here. The test we are performing is only taking voltage and resistance measurements. Ideally, we would want a code that looks like the following:

Implementing the Hardware Abstraction Layer

The logic that performs our test utilizes a single DMM class and is independent of the type of DMM we are using. By using inheritance, we can implement a hardware abstraction layer to achieve this. Below is a picture of what the inheritance structure will look need to look like.

The base DMM class provides a set of methods that all calling code will depend on. These methods must be dynamic dispatch and must force child classes to override them. For each concrete DMM we have, we need to create a class that inherits from this base DMM class and overrides the dynamic dispatch methods.

Setting up our DMM Base Class

Create a new class called _DMMBase. The underscore at the beginning of the class name is a convention we use to indicate that this should be treated as an abstract class, meaning this class should have no non-dynamic dispatch methods and no method in this class should contain an actual implementation. Currently, there is no way to enforce these restrictions in LabVIEW, so it is up to the programmer to follow convention.

There are two dynamic dispatch methods a DMM must have – Measure Voltage and Measure Ohms. We want to require all child classes to override these two methods. To set up the “require override of dynamic dispatch method,” right-click on the class and open its properties. Select the inheritance tab and check “Transfer all Must Override requirements to descendant classes.”

Create the two dynamic dispatch VIs in the _DMMBase class. There will be no concrete implementation contained in these VIs, but you will need to make sure that all the outputs are correctly wired to the connector pane. The connector pane is required to be the same for all child classes that override this VI.

Once you create these methods, reopen the class settings. Under the “Items Settings” tab, we need to set each method to “Require descendant classes to override this dynamic dispatch VI.”

Those are all of the requirements for the base class.

Setting up Child Classes

We need to create a new class for each type of DMM we need to support. As an example, let’s create DMM 1. This class will inherit from _DMMBase and be a concrete implementation of a DMM. A concrete implementation is a class that holds implementations for the methods defined in the class it inherits from. To set up the inheritance, open DMM 1 class properties. Select the inheritance tab and click “Change Inheritance.” Select _DMMBase, then click okay.

Once you set up your new inheritance, you can right-click on the new class and select new VI for Override.

This brings up a window with a list of Vis that must be overridden by your child class. In this case, you can see the Measure Voltage and Measure Ohms methods we want to override.

After you implement the Measure Voltage and Measure Ohms VIs for each DMM, we can begin refactoring our code.

Using the Hardware Abstraction Layer

We can refactor our code so that our test logic calls _DMMBase class methods. We can then choose which concrete DMM to pass into those methods.

We still must select which DMM we are using for our test. However, at this point, the test logic is completely independent of the specific hardware. To further illustrate this point, we can refactor this code to wrap our test logic in a sub VI and pass our chosen DMM object in as an input.

If, in the future, we needed to add a new DMM (or a simulated one), there would be no need to change the ‘Run Test’ VI. All we would need to do is create a new class that inherits from _DMMbase and overrides the necessary methods.

Conclusion

A hardware abstraction layer minimizes the code changes required when the underlying hardware changes by separating the logic required to perform a test on a DUT from the logic required to interface with individual pieces of hardware. This method can improve the long-term maintainability of code. Programmers should consider this whenever interfacing with hardware.

Going Forward

We expect LabVIEW 2020 to introduce interfaces. An interface would replace the _DMMbase class and would functionally be the same. However, there are several corollaries an interface could provide, but more on this in the upcoming months.

Learn more about DMC’s LabVIEW Programming Expertise. Contact us with any inquiries.

The post A Simple Hardware Abstraction using LabVIEW OOP appeared first on DMC, Inc..