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. 

Ready to take your Test & Measurement project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals.

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

If you’ve browsed our recent Test and Measurement case studies, you might notice that semiconductor projects aren’t front and center. There’s a reason for that, and it’s not because DMC can’t or won’t do them. For decades, semiconductor manufacturing and its associated test system development largely moved overseas. As fabrication and assembly plants shifted to Asia, so did the capital budgets for automated test equipment. U.S.-based system integrators like DMC naturally focused on industries where investment remained strong: automotive, aerospace, energy, and medical. 

What’s Changing Now? 

The tide has started turning. With initiatives like the CHIPS Act and renewed focus on supply chain resilience, billions of dollars are flowing back into U.S. semiconductor manufacturing. New fabrication and advanced packaging facilities are being built here at home, and these projects come with serious capital budgets for automation and test systems. This resurgence means the need for robust, flexible, and scalable test solutions is greater than ever.

We’ve Done This Before, and We’re Ready to Do It Again 

Although recent years have seen fewer semiconductor projects, DMC has a history in this space. Check out these classic examples from our archives: 

• Fiber Optic Data Transmission Test System
• Silicon Wafer Processing
• Burn-In Test System for Fiber Optic Devices
• Process Control System for Film Deposition Tool

These projects demonstrate our ability to design and implement automated test and process control systems for high-tech manufacturing like semiconductor and telecom manufacturing environments. Engineers who worked on these systems are still with DMC, and they’d love to dust off their semiconductor expertise and apply it to modern challenges using today’s tools. 

Why DMC Is a Great Fit for Semiconductor Test Automation 

• Deep Automation Expertise: From PXI-based test stands to MES integration, we know how to build systems that scale. 
• Modern Tools & Frameworks: NI TestStand, LabVIEW, Python, .NET, and custom frameworks like DMCquencer and CORTEX. 
• Industry Knowledge: We understand the critical importance of yield, traceability, and uptime in semiconductor manufacturing. 

Let’s Build the Future Together 

If you’re planning a new fab, upgrading a process line, or are supporting one, and you need automated test systems for semiconductor devices, DMC is ready to help. We combine decades of experience with cutting-edge technology to deliver solutions that meet your performance, reliability, and compliance requirements. 

Learn more about DMC’s test and measurement automation expertise and contact us today to start a conversation.

The post Does DMC Do Automated Test Systems for the Semiconductor Industry? appeared first on DMC, Inc..

When it comes to reliability, every component in your power infrastructure matters. UPS systems, battery backups, switchgear, and backup generators all play a role in keeping operations online. But here’s the catch: testing individual components isn’t the same as testing the entire system. Each piece can pass its own validation, yet the integrated system may still fail under real-world conditions. Failure modes often emerge only when these components interact under load, during transitions, or in response to unexpected events.

Why Testing Matters 

Downtime in a data center is costly and sometimes catastrophic. Power systems are complex, and their performance under stress determines whether your facility can deliver on its uptime promises. Yet many projects rely on manual checks or incomplete testing strategies that leave gaps.  

Consider these questions: 

• Are your UPS systems validated for transient response during failover? 
• Has your switchgear been tested under realistic load conditions? 
• Do your backup generators respond correctly during commissioning? 
• Is your battery management system (BMS) ready for real-world charge/discharge cycles? 

If you’re not confident in the answers, you’re not alone. Many teams assume that OEM testing or basic commissioning is enough. It probably isn’t. 

Where Testing Should Happen 

Comprehensive testing should occur at multiple stages: 

• Factory Acceptance Testing (FAT) – Validate performance before equipment leaves the OEM 
• On-Site Commissioning – Confirm integrated system behavior under real-world conditions
• Production Testing for OEMs – Ensure every unit meets specifications before shipment

Key subsystems to focus on: 

• UPS and Battery Backup Systems – Runtime validation, transient response, and BMS functionality 
• Switchgear and Power Distribution – Failover logic and power quality under dynamic loads
• Backup Generators – Load simulation and response monitoring during commissioning 
• Energy Storage Systems – Charge/discharge cycles and safety interlocks

The Better Way 

DMC brings decades of experience testing DC power systems for the automotive and aerospace industries, where reliability is non-negotiable. We apply that expertise to data center DC and AC power infrastructure with automated test solutions that: 

• Execute custom or standard test scripts
• Control load banks to simulate real-world conditions
• Monitor power quality and transient response
• Log and report results for compliance and traceability

DMC excels at thinking outside the box. It’s what sets us apart. We don’t just deliver cookie-cutter solutions; we design and integrate unique systems tailored to your requirements and challenges. Whether you need a turnkey test station or a creative approach to integrate with existing equipment, we’ll find a way to make it work. 

Component-Level Testing 

Before you can trust the entire system, you need confidence in its building blocks. Component-level testing ensures that each UPS, battery module, switchgear panel, and generator meets its specifications under controlled conditions. This step verifies: 

• Electrical performance and safety compliance 
• Firmware and control logic functionality
• Proper response to simulated faults and load changes

Component testing is essential for quality assurance and regulatory compliance, but it’s only the first step. Even when every component passes, integration can introduce new failure modes. That’s why system-level testing is equally critical. 

System-Level Testing 

Component-level testing ensures each part works as intended. But data centers operate as complex systems, and failures often occur at the interfaces: 

• UPS and generators may not synchronize during transfer 
• Switchgear logic may falter under simultaneous load changes 
• Battery systems may behave unpredictably during extended outages

System-level testing replicates these scenarios before they happen in production, saving time, money, and reputation. 

Further Reading 

• Automated Testing of a Mobile Energy Storage System
• Smart Energy AMP Solution
• Battery Testing with Large Scale Distributed Platform
• DMC Joins Strategic Partnership with Battery Innovation Center

Let’s Start the Conversation 

Data center reliability starts with rigorous testing. If you’re asking: 

• Who’s doing this testing? 
• How are we testing? 
• Is there a better way? 

The answer is yes; there is a better way. Let’s talk about how DMC can help you validate every critical subsystem and the entire power system before it goes live. 

Contact us today and let’s discuss your data center power component and system-level testing challenges. 

The post Data Center Construction: How Are You Testing Your Power Systems? appeared first on DMC, Inc..

What is CMMC? 

The Cybersecurity Maturity Model Certification (CMMC) is a DoD-developed framework designed to assess and enhance the cybersecurity posture of organizations that handle sensitive government information. Unlike self-attestation models of the past, CMMC introduces standardized practices, processes, and third-party assessments to ensure consistent protection across all contractors and subcontractors.

Understanding CMMC Level 2

CMMC Level 2 is designed for organizations that handle Controlled Unclassified Information (CUI). It requires full implementation of the 110 security controls defined in NIST SP 800-171, covering areas such as: 

• Access control 
• Incident response 
• Risk management 
• System and communications protection 
• Configuration management 
• Audit and accountability 

For more information, visit the Department of Defense website. 

DMC’s Commitment to Cybersecurity

DMC has long prioritized security, quality, and operational excellence across our engineering and technology services. Our ongoing efforts toward CMMC Level 2 compliance build on that foundation, strengthening internal controls, policies, and processes to align with DoD expectations. 

By working toward CMMC Level 2 by year’s end, DMC is positioning itself to continue supporting customers in regulated industries while reinforcing our commitment to protecting the data entrusted to us. 

Ready to take your project to the next level? Contact us today to learn more about our solutions and how we can help you achieve your goals. 

The post DMC’s Path to Cybersecurity Maturity Model Certification (CMMC) Level 2 Compliance  appeared first on DMC, Inc..

At DMC, we believe that control-system modernization can often be the smarter, faster, and more cost-effective path, especially for complex, mission-critical test stands. In most cases, modernization deserves some more serious consideration. 

Why Modernize Instead of Replace? 

1. Preserve What Works, Upgrade What Matters

Most legacy test stands, like those used for aircraft engine components, feature robust mechanical and electrical assemblies that remain fully functional. The real bottleneck is usually outdated control consoles, operator interfaces, instrumentation, data storage, and software, which have all increased exponentially in capability and performance over the last several decades.

Meanwhile, mechanical systems haven’t changed much over the last few decades, so why replace something that isn’t broken? By focusing upgrades on the control architecture and instrumentation (software, electronics, & DAQ systems), you can: 

• Significantly reduce cost, downtime, and risk compared to full system replacement. 
• Meet modern requirements for cybersecurity, diagnostics, traceability, and user experience. 
• Avoid the complexity and uncertainty of integrating entirely new hardware into your workflow. 

2. Own Your Platform And Your Future

Modernizing with open, industry-standard platforms (like NI LabVIEW, Python, TestStand, VeriStand, PXI, cRIO, and cDAQ) means you own the software, hardware design, and architecture. This empowers your team to: 

• Expand and adapt the system as needs evolve. 
• Choose your support partners, whether DMC, your internal team, or another qualified supplier. 
• Avoid vendor lock-in and ensure long-term serviceability. 

3. Get Proven Results

DMC’s approach is grounded in a track record of successful modernization projects for commercial, military, & aerospace clients: 

• US Air Force Landing Gear Test Facility (LGTF): DMC replaced an aging control system on a one-of-a-kind aircraft tire dynamometer, delivering a modern, open-platform solution that extended the facility’s capabilities and lifespan. 
• Outboard Marine Engine Test Cells: DMC automated legacy test cells for a global engine manufacturer, improving data acquisition and keeping costs in check. 
• Commercial Vehicle Transmission Test Rigs: By refurbishing control systems and software while preserving mechanical infrastructure, the DMC team saved clients over $1M per rig compared to buying new. 

A Phased, Low-Risk Approach 

DMC recommends a structured, phased process for most test cell modernization projects. This approach ensures you only invest where it matters, with full transparency on costs and timelines. 

1. Assessment: Collaborate with the client, stakeholders, and end users to evaluate upgrade options and risks. 
2. Design: Develop detailed plans for the new instrumentation and control system. 
3. Deployment: Build, test, and roll out the upgrade, minimizing downtime. 
4. Futureproofing: Allow for optionally upgrading other necessary systems later, without overhauling the control system. 

Conclusion

For Aerospace and Defense organizations, modernizing test infrastructure isn’t just a budget-friendly alternative—it’s a strategic move that maximizes asset value, accelerates readiness, and supports long-term mission success. Before you sign off on a brand-new test rig, ask: What could you achieve by simply modernizing the brains of your existing system? 

Contact us today to learn more about our Test and Measurement expertise and how we can help your team achieve their goals. 

The post Why Buy New? The Case for Modernizing Test Rigs in Aerospace & Defense appeared first on DMC, Inc..

The activity starts with development: using LabVIEW, MS Paint, and our own creativity, we all create ornament designs that inspire us for the year. We then print them, laminate them, and hole-punch just like any paper ornament before the best part: hanging them on the tree!

The activity is a team effort, as after several years of festive ornaments, we must be selective about what makes the tree each year. This year, themes like AI, LabVIEW package managers, and our ongoing NASA project felt particularly topical to keep on the tree, as well as some classic LabVIEW icons and the Top Level at the top of the tree. If you want to check out some of the prior years’ events, you can find them here and here!

One of DMC’s core values is Have Fun, and we’ve found that our ornament tradition helps us do just that. It’s a great way to refresh your focus with some creativity and come together as a team to make something we can enjoy for the rest of the holiday season.

Celebrating the Season as an NI Platinum Partner

Our ornament tradition is also a reminder of how closely we work with NI technologies throughout the year. DMC is proud to be one of NI’s highest-ranked partners worldwide and the exclusive Platinum-level partner in the Americas. Since 1997, our teams have partnered with NI to deliver complete instrumentation, measurement, and automated test solutions for clients across a wide range of industries.

The same LabVIEW tools that spark our creativity during the holidays are the foundation of the work we do every day. Our engineers bring deep knowledge of NI products to projects involving LabVIEW programming, automated test equipment, real-time and FPGA development, and more. This expertise helps us design solutions that are consistent, scalable, and built for long-term success. Visit our NI partner page to learn more about our expertise.  

Got a creative LabVIEW idea you’d like to take a swing at? Contact us today to learn more about our Test & Measurement team and our LabVIEW tips and tricks beyond the icon editor!

The post Spreading Holiday Cheer with New LabVIEW Ornaments appeared first on DMC, Inc..

Figure 1: Functions Palette

Figure 2: QuickDrop

To complement QuickDrop, we have been working on DMC-Complete: a tool that has the potential to supercharge the way you use LabVIEW by predicting the blocks you need right when you need them.

Simply clicking on a block triggers the DMC-Complete interface to predict what block you are most likely to use next, speeding up the process of programming so you can focus on the logic of your code rather than the tedium of searching for a specific block.

DMC-Complete Offers:

• Blazing speed – predictions happen in milliseconds
• Fully local operation – no internet required
• Minimal resource usage – runs efficiently even on VMs
• Full library compatibility – works with custom and VIPM packages
• Strong privacy – your code stays on your device
• Easy retraining – add or remove packages with minimal effort
• Open-source access – check out the code, available under the BSD 3-Clause License

Getting Started

If you want to get started with using DMC-Complete, check out our repository where the code for this project lives: https://github.com/fadilf/DMC-Complete

The Installation and Usage sections of the README.md file should help you get up and running with the tool in no time! Keep in mind that the project is currently an early beta, so if you encounter any issues while using it, please file them on the GitHub page.

How It Works

At GDevCon NA in Chicago this year, DMC got a chance to give a talk on how the tool works in more detail!

Markov Chains

The key to understanding DMC Complete? Markov chains. A Markov chain can model a sequence of events in which the probability of each event depends only on a limited set of prior states. This approach can be used to model things as important as the weather or something as mundane as your opponent’s next move in rock-paper-scissors:

[…, , , ] → (50%) / (30%) / (20%)

[…, rock, paper, scissors] → rock (60%) / paper (30%) / scissors (10%)

These simple statistical relationships form the basis for predicting the next LabVIEW block in your block diagram.

Analyzing Block Diagrams

Figure 3

Let’s look at an example block diagram. We’ve got different types of blocks like controls, indicators, constants, DAQmx functions, etc., as well as a for loop structure. If we ignore structures, our block diagram looks like this:

Figure 4

We then genericize the blocks so we can treat them as Markov states for analysis. You might notice that this looks a lot like a directed acyclic graph.

Figure 5

Once we have this set of Markov states, we can start to observe patterns of blocks to make predictions later. If we count 2-block sequences, a pattern begins to emerge.

Figure 6

Figure 7

Once you have a table like figure 7, you can reorganize it into a Markov model, which looks more like this:

Figure 8

Now, when we see a numeric control, we know that the next block is either a Sine Wave (50% chance), a DAQmx Create Channel block (~33% chance), or a DAQmx Timing block (~17% chance). If we apply this process to our entire training set, including the example files included with LabVIEW and any libraries we install, we get a model that learns the pattern of how we code with the blocks we have.

This model is just a mapping/dictionary, so it only takes up a few megabytes on disk and in memory. Using it is as simple as a map lookup, so it’s an instant O(1) operation. Behind the scenes, there is a caching mechanism that takes place, so if you want to retrain with fewer/more files, the retraining process runs very quickly. The slowest part of training is the initial conversion of a VI file into a graph, which is why we have taken on the burden of creating a pre-made cache that should speed up initial training as well.

Summary

DMC-Complete demonstrates how classical AI techniques can deliver surprising results. By combining the simple principle of Markov modeling with the power of LabVIEW’s graphical programming, you can have a practical, private, and responsive coding companion. Sometimes, the simplest solutions are the most effective.

By developing this tool, we hope to contribute to the ever-growing landscape of open-source projects written in LabVIEW that work to improve productivity and serve our needs as well as our clients’ needs better. Contributions to the project are welcome at the repository link provided above.

Want to leverage the expertise of our world-class LabVIEW developers with Test and Measurement Automation experience in a broad range of industries? Contact us today to learn more about our solutions and how we can help you achieve your goals.

The post DMC-Complete: Faster LabVIEW Coding with Old-Fashioned AI appeared first on DMC, Inc..

What is a HAL?

You probably already know this, but a HAL is a software layer that defines a consistent interface for interacting with hardware. Instead of your application talking directly to device-specific drivers, it communicates through abstracted classes and interfaces. This means your test sequences or workflows don’t care whether the underlying instrument is Vendor A or Vendor B: they call the HAL. There are numerous benefits to using a HAL, but too often, HALs are discussed in theory and promptly forgotten in practice. Though implementing a HAL requires more upfront work, the payoff over time is clear if you do it right.

Benefits of Using HAL

Let’s first highlight the major motivations behind a HAL. Some of these will resonate differently depending on what you’re automating and how you use your test system, but bottom line – most people can find at least a few reasons on this list to seriously consider a HAL:

• Obsolescence Planning – Replace hardware without rewriting your entire system.
• Swappable Instruments – Swap drivers, not test logic.
• Modularity & Reduced Retesting – Limit validation scope when hardware changes.
• Reusable Test Sequences – Apply the same concept to DUTs for flexibility.
• Faster Integration of New Hardware – Implement the interface, keep logic intact.
• Improved Scalability – Scale across stations with different hardware.
• Better Maintainability – Separate hardware and business logic.
• Vendor Independence – Avoid lock-in.
• Simulation & Virtual Testing – Mock hardware for early testing.
• Consistent Logging & Error Handling – Centralized diagnostics and data reporting functionality.

Pro Tip: You can apply the same abstraction concept to DUTs. Define a HAL for your product interface so test sequences can work with different models or variants without rewriting logic.

Challenges in Building a HAL

With all these benefits, you might wonder why HAL design is sometimes overlooked. The reality is that building a HAL comes with technical challenges. Wrapping third-party drivers and DLLs can be cumbersome, and the variability in device features often complicates interface design. Starting too early without multiple hardware options can lead to unnecessary complexity, while performance overhead in time-critical systems is a legitimate concern. Debugging and maintaining a layered architecture adds complexity, and versioning for backward compatibility requires careful planning. Testing the HAL itself and managing dependencies for drivers and licensing further increase the effort required. These challenges don’t negate the value of a HAL, but they can make implementing a HAL daunting unless you have the deep technical experience to avoid the pitfalls.

What Makes a Good HAL? Key Requirements Organized by SOLID Principles

To overcome these challenges and avoid costly mistakes in your HAL implementation, applying proven design principles is essential. The SOLID principles provide a strong foundation for building flexible, extensible software architectures. Here’s how the key requirements align with SOLID. If you follow these, you are well on your way to creating a maintainable and scalable HAL that your future self or team will thank you for.

Single Responsibility Principle

• Clear Separation of Concerns – Isolate hardware-specific logic from application/business logic. Provide well-defined interfaces so upper layers never directly interact with hardware drivers.

Open/Closed Principle

• Extensibility – Support easy addition of new hardware without breaking existing code. Use plug-in architecture or factory patterns for dynamic hardware binding.

Liskov Substitution Principle

• Consistent and Unified API – Expose a standardized set of functions for common operations (e.g., read/write, configure, status). Normalize differences across devices; avoid exposing hardware quirks.
• Configuration Management – Support dynamic configuration (e.g., device parameters, communication settings that are relevant to only specific devices without imposing those same configuration parameters on other specific implementations).

Interface Segregation Principle

• Interfaces for Flexibility – Use interfaces to handle cases where a device fits multiple classifications and cannot be modeled by a simple parent-child relationship.

Dependency Inversion Principle

• Depend on Abstractions – Ensure higher-level modules rely on interfaces, not concrete implementations, to maintain flexibility and reduce coupling.

Additional Cross-Cutting Requirements

• Error Handling & Diagnostics – Provide robust error codes or exceptions for hardware failures. Include logging hooks for debugging and traceability.
• Testability – Enable mocking or simulation of hardware for unit tests. Provide virtual HAL implementations for CI/CD environments.
• Documentation & Versioning – Clear documentation for APIs and supported hardware. Version control for HAL modules to manage compatibility.

Conclusion

A well-designed HAL is an investment in flexibility, scalability, and maintainability. It reduces risk, saves time, and ensures your test system can evolve with changing hardware and product requirements. While building a HAL requires upfront effort and thoughtful design, the long-term benefits far outweigh the initial cost.

Looking for More?

Check out our other articles on HALs, including some of our software frameworks that we use on customer projects that come with a HAL built-in:

• CORTEX Framework: Standardize Your Automated Test Systems—Without Starting From Scratch
• Flex Framework HAL: Streamline Hardware Configuration with the Hardware Abstraction Layer
• LabVIEW OOP-Based HAL: A Simple Hardware Abstraction using LabVIEW OOP

Want help designing a HAL? Contact us today to learn more about our solutions and how we can help you achieve your goals. 

The post Why Hardware Abstraction Layers (HAL) Are Essential for Scalable Test Systems appeared first on DMC, Inc..

This technical blog distills how and when to use FPGAs for custom measurements, the architectural patterns that actually work, and hard‑earned tips from DMC projects, plus links to DMC case studies and technical blogs you can reference as you architect your own system.

Why an FPGA for Measurement?

Determinism from microsecond to nanosecond scales
FPGA logic executes in hardware with clock‑accurate timing. On NI RIO targets, you can use single‑cycle timed loops (SCTLs) to run logic loops timed by clock signals that you specify. These loops have extremely low jitter, meaning that every iteration of the loop executes in the same amount of time. When you need very high confidence that control loops have a consistent time delta or that timestamps can be trusted, an FPGA may be the right tool.

Massive parallelism
Independent loops of logic on an FPGA execute in parallel. Unlike conventional CPUs, adding more loops to count edges, filter data, or implementing serial protocols won’t slow the other loops. This is ideal for multi‑sensor, mixed‑signal acquisition or protocol gateways.

Throughput without host bottlenecks
Stream continuous, high‑rate data using DMA FIFOs between FPGA and host, or bypass the host entirely with Peer‑to‑Peer (P2P) streaming between PXIe modules on the backplane. The FPGA can share data with oscilloscopes, waveform generators, vector signal analyzers, and more without burdening the host processor or memory.

Custom I/O and protocol timing
Implement custom digital front‑ends, encoders, counters, PWM, or proprietary serial timings that off‑the‑shelf DAQ devices don’t support. With CLIP and the IP Integration Node, you can also drop in HDL cores (VHDL/Verilog) or Xilinx IP where needed.

When to Choose an FPGA vs. PC or Real-Time (RT)?

Use this quick rule of thumb (derived from DMC best practices and NI documents):

• Choose FPGA when you require sub‑microsecond latency; hardware‑synchronous data paths; custom protocol waveforms; lossless streaming at hundreds of kS/s to GS/s; or multi‑loop parallel logic that must always meet timing.
• Choose RT (cRIO/PXI RT) when you need deterministic millisecond‑level control, supervisory logic, or file/logging tasks that coordinate with FPGA work. RT + FPGA is a common pairing.
• Choose PC when you need rich UIs, analytics, databases, or post‑processing, and timing isn’t safety‑critical. (Still pair with FPGA for preprocessing and rate reduction.)

DMC uses all three layers across industries (aerospace, electrification, advanced manufacturing), typically placing tight control and fast parallel logic on the FPGA, supervision and coordination on RT, and UX/data management on Windows. See our Real‑Time & FPGA overview and examples on DMC’s services page.

LabVIEW FPGA Essentials (what matters in practice)

Move data predictably:

Targets & clocks
Your LabVIEW project contains an FPGA target (cRIO chassis, FlexRIO, etc.) with base clocks (40 MHz onboard) and optional derived clocks. The top‑level clock governs logic outside SCTLs; SCTLs run in their selected clock domain. Use multiple clock domains to execute calculations at lower rates and fast I/O logic at higher rates.

DMA FIFOs
DMA FIFOs allow you to transfer data to and from the FPGA and host. The FIFO size can be scaled to avoid overflows. You can also create target‑scoped FIFOs to communicate between loops, but be sure to understand the different FIFO implementations.

Fixed‑point everywhere
Floating‑point math is expensive in FPGA fabric. Instead, you can do fixed‑point (FXP) math to be more hardware‑efficient. Controlled rounding and overflow modes and configurable word lengths & layouts allow you to plan for your specific algorithm. Prefer saturate where correctness is more important than speed, and wrap to optimize for resource usage. NI’s tables and guides are gold when sizing numeric types.

Bring your own HDL when needed
With CLIP (component‑level IP) or the IP Integration Node, you can insert vendor IP, legacy VHDL, or Xilinx IP cores into your own code to accelerate development.

Patterns DMC Reuses for High-Performance Measures

1. Deterministic data capture and stream
   Use the FPGA to capture signal edges with nanosecond resolution, decimate and filter the data on FPGA, stream features to RT/PC via DMA, and use the host system for logging, visualization, and analytics. We’ve applied this multi‑layered FPGA/RT/PC architecture on aerospace and defense systems with >500 channels.
2. Custom waveform synthesis at GS/s
   With FlexRIO adapter modules, we’ve generated parameterized waveforms (delay/hold/ramp) at 1.25 GS/s using an adapter like the Active Technologies AT‑1212. Generating the waveforms on FPGA allows nanosecond‑level timing, great for optical/LIDAR, RF, and pulsed power.
3. Frequency‑domain triggers & inline RF analysis
   Use P2P to stream digitizer data straight into an FPGA for windowing/FFT/mask comparison, then control backplane trigger lines to capture only events of interest. This eliminates host copies and makes “impossible” real‑time analyses practical.
4. High‑speed protocol emulation & HIL
   The FPGA implements line‑speed channel models and packet timing, while PXI instruments handle I/O—use DMA for logging and P2P for cross‑module data paths. We’ve used this architecture in demanding hardware‑in‑the‑loop modem testing.

A Pragmatic LabVIEW FPGA Architecture

Keep the FPGA’s job small
Do the minimum required at hardware speed: time‑critical I/O, data reduction, protection, and lossless streaming. Push everything else to RT/PC. (This guideline is ubiquitous in DMC training decks.)

Use SCTLs wisely
SCTLs reduce resources and latency but increase timing pressure. Pipeline long combinatorial paths, separate fast and slow clocks, and avoid SCTL‑incompatible nodes (e.g., certain I/O or waiting functions).

Engineer your clocks
Start with the 40 MHz onboard clock and derive others only as needed. On FlexRIO, additional base clocks (100 MHz/200 MHz) and DRAM clocks are available; match clocking to I/O and algorithm needs.

Get data off the FPGA early
Choose target‑scoped FIFOs for on‑fabric communication and DMA FIFOs for host transfer. If you’re in a PXI(e) system and need device‑to‑device throughput or deterministic fan‑outs, configure P2P streams with NI‑P2P.

Choose numeric types deliberately
Pre‑size FXP to prevent overflow and use truncate where quantization error is tolerable.

Development & Debug Workflow that Saves Weeks

Simulate before you compile
FPGA builds can take minutes to hours. Use Simulated I/O and the FPGA Desktop Execution Node to build testbenches with simulated time, probe internal signals, and validate algorithms long before you commit to a hardware compile.

Layered testing
It’s a best practice to take a unit → component → system verification approach. Simulate units without I/O; component‑test clocked processes; then system‑test with real I/O or emulated streams.

Compile strategy
Use the FPGA Compile Cloud Service or a compile farm to parallelize big builds and keep engineers moving. NI’s developer center outlines your options.

Hardware Selection Notes

• cRIO: Rugged, modular C‑Series I/O; great for embedded measurements and deterministic control. Default 40 MHz FPGA clock; derive carrier clocks as needed.
• FlexRIO: PXI(e) FPGA with adapter modules for GS/s converters, custom front‑ends, and P2P; multiple base clocks; DRAM; ideal for inline DSP and RF/fast transients.
• R Series / Multifunction RIO: General‑purpose FPGA with direct DIO/AIO; useful when you need custom timing on classic DAQ channels.
• Other Platforms: If nothing above hits the mark, DMC can leverage our Embedded Services Team to develop a truly custom solution: FPGA Programming

If you’re unsure, DMC often starts with a short discovery mapping I/O timing, throughput, and latency to the simplest platform that meets the spec, escalating to FlexRIO only when rates, bandwidth, or P2P drive the need.

Real-World Examples & Further Reading

Top 5 FPGA-Related DMC Case Studies

Top 5 FPGA-Related DMC Blogs

1. NI LabVIEW Part 1: Building Distributed and Synchronized FPGA Applications
   Explains synchronization techniques for multiple FPGA chassis using NI 9469 modules.
2. NI LabVIEW Part 2: Synchronized Data Acquisition across Distributed FPGA Chassis
   Discusses DMA FIFO strategies for transferring data between FPGA and RT targets in multi-chassis systems.
3. RT-301: Capabilities of Distributed LabVIEW Real-Time
   The major benefits of running a Real-Time system are determinism and robust operation.
4. FPGA Programming Overview
   A service-focused blog detailing FPGA programming capabilities, including Xilinx, Intel, and LabVIEW FPGA platforms.
5. Troubleshooting NTP with NI Hardware
   While not purely FPGA, it’s relevant for time synchronization in FPGA-based DAQ systems.

A Starter Checklist for your FPGA Project

1. Quantify timing: Required max latency, jitter, and timestamp resolution. If < 10 µs, you’re likely in FPGA territory.
2. Estimate throughput: Peak and sustained rates; raw vs. reduced features; choose DMA vs. P2P accordingly.
3. Partition the system: What must run in SCTLs? What can run in a slower clock? What can RT/PC do?
4. Pick numeric formats: Fixed‑point widths, rounding/overflow policies; verify with simulation.
5. Plan testbenches: Use Simulation (Simulated I/O) and the Desktop Execution Node before hardware compiles.
6. Design streams & buffers: Size FIFOs to cover bursts of data and verify that underruns or overflows can’t occur in worst‑case scenarios.

How DMC Can Help

DMC has delivered deterministic, high‑throughput measurement systems across avionics, RF, electrification, and advanced manufacturing—often blending FPGA inline processing with RT coordination and PC‑level analytics and UX. Our team includes NI Certified LabVIEW Architects and deep FlexRIO/cRIO experience. Explore our Real‑Time/FPGA services and reach out—we’ll help right‑size your architecture and accelerate your first build.

Contact DMC today to learn more about our FPGA work or to discuss your specific requirements.

The post Using FPGAs for Custom High-Performance Measurements (Intro to LabVIEW FPGA) appeared first on DMC, Inc..

One of these issues is that many organizations struggle to strike the right balance between internal ownership and external execution when it comes to developing and sourcing their test systems. Some try to do everything in-house and run into bandwidth and/or capability issues. Others outsource too much, losing product-specific expertise, struggling with decision making and alignment of internal stakeholders, and lacking any cohesive testing strategy. Perhaps worst of all are the customers we have worked with long enough to see them periodically cycling between these two ends of the spectrum, as they overcorrect issues observed during their latest attempts at sourcing test systems.  

At DMC, we’ve seen the most successful clients follow a hybrid model—one that empowers internal test engineers to lead strategically while leveraging external experts for test system execution and technical innovation. 

The Pitfalls of Going It Alone

Relying solely on internal teams to ‘do it all by themselves’ can lead to: 

• Resource bottlenecks: Internal engineers often juggle multiple priorities and lack time for deep system development. 
• Limited exposure: In-house teams may not be familiar with the latest tools, platforms, or test strategies across industries. 
• Missed opportunities: Without external input, test systems may be overbuilt or misaligned with budget and timeline constraints. 
• Over- and under-staffing: Depending on how often your business needs new or updated test systems, you are either paying for engineers to sit on the bench or constantly resource constrained. 
• Getting lost in the weeds: Engineers may place too much focus on technologies and software architectures rather than testing process effectiveness, efficiency, and overall product quality. 

Misdirected Internal Engineers: A Hidden Risk

On the flip side, some organizations bring in external partners to deliver their test systems and fail to prepare and engage their internal test engineers effectively. Without preparing your internal test engineers, they may act as ‘internal competition’ to the external team. Some clients believe they don’t need any internal test engineer involvement once they make the decision to use an outside partner. 

These mistakes often result in: 

• Missing, incomplete, or total lack of requirements and test specifications 
• Poor stakeholder communication and misalignment on goals 
• Trouble making engineering and project trade-offs quickly 
• Lack of ownership for test system validation and deployment 
• Internal test engineers feeling “left out” of the process and marginalized 

Best Practice: Strategic Internal Ownership + Expert External Execution

The most effective model we’ve seen used by customers is a hybrid model that fits somewhere in between the two extremes, with internal and external resources playing roles based on their strengths and in constant communication. 

Internal Test Engineering Team Owns: 

• Budget and scheduling allocation and processes 
• Overall stakeholder alignment, from the beginning to the end of the project 
• Understanding the critical product functions and test specifications 
• Providing subject matter expertise for any industry or customer-specific technologies required, or acting as an intermediary with internal team members 
• Producing clear requirements and definitions to the external team, ensuring expectations are realistic, testable, and traceable 
• Providing project management during the execution phase 
• Leadership of test system validation and acceptance testing, to ensure the delivered system meets performance, quality, and usability goals 
• Long-term ownership of the delivered test system, calibration, maintenance, overall testing process, and data analysis and monitoring 

External Test System Integration Partners Bring: 

• Consultative insight into meeting test goals within budget and time constraints while maintaining a consistent overall testing strategy 
• Knowledge of the latest best practices across many industries and lessons learned from the execution of dozens of test and measurement projects per year 
• Up-to-date technical know-how and subject matter expertise in platforms like NI LabVIEW, TestStand, SystemLink, and cloud-enabled test environments 
• Scalable system architectures with support for global deployment, multi-channel systems, and integration with any laboratory or factory-floor systems 
• Efficient execution of test system design, build, and deployment 
• Proper software development practices, including testing, integration, code reviews, revision control, documentation, and release 
• Full hardware system management, including design, customer reviews, drawing revision control, design release processes, fabrication, system startup and testing, documentation, and subcontractor and supplier oversight 
• High-level troubleshooting and maintenance assistance after system startup 

Case Study Examples

DMC’s recent work on ECU (electronic control module) and BMS (battery management system) EOL (end-of-line) test systems illustrate this model well. The customer’s internal test engineering teams defined the performance goals and test specifications and frequently consulted with DMC on a few critical requirements to ensure they could fit within their tight budget and schedule demands. From there, DMC executed the system design, software development, test stand build, and validation. The result was delivery and handoff of a robust, scalable solution that met quality and production needs without overburdening internal resources. 

• Bed of Nails Battery Management System PCB Test Station 
• Functional End of Line Test System for Automotive ECUs 

Conclusion

The key to success isn’t choosing between internal and external routes to test system delivery—it’s knowing how to combine them effectively. Organizations can build smarter, faster, and more cost-effective test systems by: (A) empowering their internal test engineers to manage and lead strategically and (B) partnering with experienced external teams like DMC for execution.

We Can Help

If you’re looking for consulting or support as you navigate the complexities of effectively outsourcing your test system development, give us a call!

Contact us today to learn more about our Test and Measurement expertise and how we can help your team achieve its goals. 

The post Bridging Expertise: How to Maximize Value from External Test & Measurement Partners While Empowering Your Internal Engineering Team appeared first on DMC, Inc..