On the Agenda: Extending LabVIEW with NATS

I had the opportunity to present Extending LabVIEW with NATS, where I discussed how their pub/sub messaging model can extend LabVIEW test systems beyond a single-language, single-executable architecture. The core idea is that monolithic test applications can be bulky and hard to manage, while tools like NATS allow for more modular software design. Check out the code in the LabVIEW Toolkit.

Sessions That Stood Out

There were many presenters and panels that stood out this year. Here are a few that stuck with me. You can also see these sessions as they’re uploaded to GDevCon’s YouTube channel.

• Open-source Wrapping: The Gift That Keeps on Giving (Chris Davis, Amentum): A look at wrapping open-source C libraries for LabVIEW for Redis and Kafka. These are great complementary tools to NATS.
• Shift-Left: Building Secure LabVIEW Systems from Day One (Sarah Zalusky, JKI): A practical look at security in LabVIEW architectures.
• MALpocalypse (Michael Klessens, Intel): A candid account of when measurement abstraction layers stop working at scale with validation constraints.
• Shaping the Future: AI and the Evolution of LabVIEW (Elijah Kerry, NI): An early look at Nigel, NI’s AI coding assistant for LabVIEW. Plus, lots of CI/CD tooling with LabVIEW containers.
• Our Build and Deployment Process: Using CI/CD and SystemLink (Sarah Morales, SRAM): A walkthrough of SRAM’s g-cli-based GitLab pipelines. SRAM’s approach validated the work DMC has done to automate our own pipelines with similar tooling.

Catching Up with Partners

Beyond the sessions, GDevCon is a great chance to connect with DMC’s partners. We participated in hardware and software demos from Pickering, Beckhoff, and NI. Most importantly, our partners give us insight into their project roadmaps. This allows us to be trusted advisors to our clients, knowing what to avoid for obsolescence and where to leverage new tools.

Final Takeaway

GDevCon N.A. is always a great place to learn what the test and measurement community is building, breaking, and fixing in production. The conference also gives us the opportunity to catch up with our hardware partners, and this year’s event did not disappoint!

We cannot wait to see what next year will bring.

The post What We Learned at GDevCon N.A. 2026: AI, CI/CD, and the Future of LabVIEW appeared first on DMC, Inc..

The practical answer is not to rewrite everything. Instead, a split-runtime architecture allows teams to keep LabVIEW where it shines and move high-change computation into Python services connected over TCP.

This Python integration approach supports a wide range of industrial use cases, including:

• Vision inference and image analysis.
• Statistical quality calculations.
• Optimization and scheduling support.
• Report generation and data enrichment.
• AI-assisted engineering tools.

The end result is an architecture in which LabVIEW remains the orchestration and operator-layer interface for complex hardware systems, while Python hosts features that benefit from rapid iteration and rich libraries. One particularly salient reason to integrate Python in this way is that it integrates cleanly with the latest AI coding agents and tooling, supporting accelerated development.

Why TCP Is the Right Approach

There are multiple ways to connect runtimes, many of which DMC has explored across numerous domains. For example, we’ve worked with MQTT, RabbitMQ, NATS, Redis, as well as other messaging tools and protocols. In this tutorial, we use a simple request-reply pattern. Here, TCP is the best fit since it is:

• Language neutral: Both LabVIEW and Python support sockets natively.
• Low overhead: Efficient for frequent request/response cycles without added protocol information.
• Process isolated: UI/control failures and compute-service failures are easier to contain. No need to manage the lifecycle of a binary outside of two processes communicating with each other.
• Flexible in deployment: Run components on the same machine or distribute later without changing the contract.

LabVIEW Python TCP Reference Architecture

A reusable version of this request-reply pattern looks like this:

1. LabVIEW gathers the request parameters and sends a typed request.
2. The Python service receives the request and executes the requested logic.
3. Python returns typed results plus optional status and timing metadata.
4. LabVIEW processes the reply body as needed.

This same structural loop applies whether the compute workload is vision, forecasting, anomaly scoring, or rule evaluation.

Socket Wrappers for LabVIEW and Python Communication

This is a minimal implementation of a socket wrapper that serves as a skeleton you can use to add type safety, error checking, and other safeguards to make your code more robust. The wire format is a fixed header to ensure that reads are deterministic:

• LabVIEW to Python: 1 byte message type + 4 byte big-endian payload size + payload bytes.
• Python to LabVIEW: 4-byte big-endian payload size + payload bytes, since the message type defines the response.

import json
from enum import Enum


class Lv2PyMessageType(Enum):
    ANALYZE_ANIMAL = 0
    FETCH_WEATHER = 1
    EXIT = 2


class LVSocket:
    def __init__(self, sock):
        self.sock = sock

    def await_message(self) -> tuple[Lv2PyMessageType, bytes]:
        msg_type = Lv2PyMessageType(int.from_bytes(self._recv_exact(1), "big"))
        size = int.from_bytes(self._recv_exact(4), "big")
        return msg_type, self._recv_exact(size)

    def send_message(self, payload: bytes):
        self.sock.sendall(len(payload).to_bytes(4, "big"))
        self.sock.sendall(payload)

    def _recv_exact(self, n: int) -> bytes:
        out = b""
        while len(out) < n:
            chunk = self.sock.recv(n - len(out))
            if not chunk:
                raise ConnectionError("Socket closed")
            out += chunk
        return out

import json
from enum import Enum


class Lv2PyMessageType(Enum):
    ANALYZE_ANIMAL = 0
    FETCH_WEATHER = 1
    EXIT = 2


class LVSocket:
    def __init__(self, sock):
        self.sock = sock

    def await_message(self) -> tuple[Lv2PyMessageType, bytes]:
        msg_type = Lv2PyMessageType(int.from_bytes(self._recv_exact(1), "big"))
        size = int.from_bytes(self._recv_exact(4), "big")
        return msg_type, self._recv_exact(size)

    def send_message(self, payload: bytes):
        self.sock.sendall(len(payload).to_bytes(4, "big"))
        self.sock.sendall(payload)

    def _recv_exact(self, n: int) -> bytes:
        out = b""
        while len(out) < n:
            chunk = self.sock.recv(n - len(out))
            if not chunk:
                raise ConnectionError("Socket closed")
            out += chunk
        return out

Service Loops

The service itself is just a while True loop: wait for a typed message, branch on it, compute, and send the reply. This pattern keeps the service logic straightforward and maintainable.

import socket

PORT = 12345

def analyze_animal(payload):
    # parse the payload for this message and generate your response here
    ...

def fetch_weather(payload):
    # parse the payload for this message and generate your response here
    ...

def serve(sock):
    lv = LVSocket(sock)
    while True:
        msg_type, payload = lv.await_message()
        if msg_type == Lv2PyMessageType.ANALYZE_ANIMAL:
            result = analyze_animal(payload)
            lv.send_message(json.dumps(result).encode("utf-8"))
        elif msg_type == Lv2PyMessageType.FETCH_WEATHER:
            result = fetch_weather(payload)
            lv.send_message(json.dumps(result).encode("utf-8"))
        elif msg_type == Lv2PyMessageType.EXIT:
            break

if __name__ == "__main__":
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        s.bind(("localhost", PORT))
        s.listen()
        print("Waiting for LabVIEW to connect...")
        conn, addr = s.accept()
        print(f"Connected by {addr}")
        with conn:
            serve(conn)

import socket

PORT = 12345

def analyze_animal(payload):
    # parse the payload for this message and generate your response here
    ...

def fetch_weather(payload):
    # parse the payload for this message and generate your response here
    ...

def serve(sock):
    lv = LVSocket(sock)
    while True:
        msg_type, payload = lv.await_message()
        if msg_type == Lv2PyMessageType.ANALYZE_ANIMAL:
            result = analyze_animal(payload)
            lv.send_message(json.dumps(result).encode("utf-8"))
        elif msg_type == Lv2PyMessageType.FETCH_WEATHER:
            result = fetch_weather(payload)
            lv.send_message(json.dumps(result).encode("utf-8"))
        elif msg_type == Lv2PyMessageType.EXIT:
            break

if __name__ == "__main__":
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        s.bind(("localhost", PORT))
        s.listen()
        print("Waiting for LabVIEW to connect...")
        conn, addr = s.accept()
        print(f"Connected by {addr}")
        with conn:
            serve(conn)

We can handle these messages from LabVIEW using the built-in TCP functions and pass a wide range of data in the message body.

Lifecycle Management

The next step is to start and stop our Python script along with our LabVIEW code while gracefully handling errors and exits. We can use the System Exec.vi function to accomplish this, as shown in the snippet below.

We can also safely manage the lifecycle of the Python script by, in addition to the EXIT message type, adding handling for socket disconnections by gracefully exiting the Python script if the socket is closed from the LabVIEW side. With this approach, operators can restart Python service, for any reason, by simply stopping and restarting the LabVIEW application, without needing to manage the Python process separately.

Packaging for Deployment

Finally, to deploy this architecture, package the Python script so it can be distributed alongside the LabVIEW build for client systems. This can be done with tools like PyInstaller, which creates a standalone executable from your Python script. You can then conditionally call this executable from LabVIEW using the System Exec.vi as shown below. This approach simplifies testing in development and deployment to production without needing to manage Python environments on the target machines.

Reliability Requirements for Production

Industrial systems need graceful behavior under real-world conditions, including dropped connections, overloaded services, and operator restarts.

Baseline reliability checklist includes:

• Request timeout and retry policy.
• Reconnect strategy with back-off.
• Health check or heartbeat message.
• Structured logs on both sides.
• Fail-safe startup and shutdown behavior.
• Logging of exceptions and edge cases for postmortem analysis.

These patterns are essential for production readiness, and they also build trust with operations teams by ensuring the system won’t fail silently or require manual intervention.

Why Integrating Python Matters for AI Adoption in LabVIEW Teams

This architecture also enables AI adoption. It allows teams to build key software components outside LabVIEW, where AI-assisted development can be faster due to:

• Rapid prototyping of analysis components.
• Quick generation of helper tools and scripts.
• Faster experimentation with algorithms and thresholds.
• Simplified profiling and optimization workflows.

LabVIEW still governs system behavior; Python becomes the iteration engine. This division allows teams to leverage AI productively while preserving control-system rigor.

Key Takeaways

• LabVIEW + Python over TCP is a reusable and extensible architecture pattern across many industrial use cases.
• Keep LabVIEW for orchestration and UI; externalize high-change compute to Python.
• The pattern creates a practical path for AI-assisted software development in industrial systems.

If you want to modernize an existing LabVIEW application, TCP-connected Python services are one of the highest-leverage places to start.

The post LabVIEW + Python Over TCP: A Reusable Architecture Pattern for Industrial Software appeared first on DMC, Inc..

There are, of course, other types of hardware that someone might want to acquire data from. Our clients often need us to integrate all kinds of equipment based on their technical and budget needs from a specialized hipot meter to a general-purpose DMM. One such client needed us to integrate a Raspberry Pi, which was collecting data from a set of sensors, with a LabVIEW app that was already collecting data from NI hardware.

Raspberry Pis are pretty popular among hobbyists and hardware engineers alike for prototyping and actual production use since they’re inexpensive, fairly robust, and have a broad ecosystem of products that work nicely with them. Their GPIO (General Purpose Input/Output) pins make it easy to interface with hardware over different low-level protocols like SPI or I2C. The boards also come with WiFi, Bluetooth, Ethernet, and USB if you need to connect to something over a higher-level interface. This brings us to the question of how to use a Raspberry Pi in a way that is fast and reliable from a LabVIEW application running on a separate PC—effectively using it as a DAQ device.

The Easy Way: FastAPI

Let’s begin with a simple approach—we can set up a minimal REST API service on the Raspberry Pi using FastAPI that, when queried, creates and returns your measurement.

Setting Up the API

FastAPI is a modern Python web framework that makes it simple to create REST APIs. On your Raspberry Pi, you can install it along with a production server like uvicorn:

pip install fastapi uvicorn

Then create a simple API endpoint that reads from your sensor:

from fastapi import FastAPI
import time

app = FastAPI()

@app.get("/sensor/read")
def read_sensor():
    # Your sensor reading code here
    # For example, reading from an I2C device
    value = read_i2c_sensor()
    timestamp = time.time()

    return {
        "value": value,
        "timestamp": timestamp
    }

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

from fastapi import FastAPI
import time

app = FastAPI()

@app.get("/sensor/read")
def read_sensor():
    # Your sensor reading code here
    # For example, reading from an I2C device
    value = read_i2c_sensor()
    timestamp = time.time()

    return {
        "value": value,
        "timestamp": timestamp
    }

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

From LabVIEW, you can use the HTTP Client VIs to make GET requests to <http://your-pi-ip:8000/sensor/read> and parse the JSON response to extract your sensor data.

The Issues

While this approach is straightforward and gets you up and running quickly, it has some significant limitations for serious data acquisition:

Not Truly Time-Series: Each request creates a new measurement on demand. If you’re trying to capture a continuous stream of data, you’ll miss all the samples between requests. This is fine for slow-changing values like temperature readings every few seconds, but inadequate for high-speed data acquisition.

Request Overhead: Every HTTP request involves substantial overhead, TCP handshaking, HTTP headers, JSON serialization/deserialization, and network latency. If you need to sample at high rates (say, 1000 samples per second), making 1000 individual HTTP requests per second is inefficient and will likely introduce timing jitter and missed samples.

For applications where you need occasional readings or the data changes slowly, this approach works great. But for continuous, high-speed data acquisition, we need something better.

The High-Speed Way: Redis Streams

Redis is an in-memory data structure store that’s fast and supports various data types, including streams – perfect for time-series data collection. The architecture here is more sophisticated but provides much better performance:

In production, you may implement the sensor loop in C or another lower-level language for tighter timing, but Python is a good way to understand and prototype the architecture.

1. A Python process on the Raspberry Pi continuously reads sensors and writes to a Redis stream.
2. Redis stores the data in memory as a time-ordered stream.
3. LabVIEW periodically reads from the stream, getting batches of new data.
4. Webdis provides an HTTP interface to Redis, making it accessible from LabVIEW.

Setting Up Redis

First, install Redis on your Raspberry Pi:

sudo apt-get install redis-server

Install the Python Redis client as well:

pip install redis

Configure Redis to start on boot and ensure it’s listening on the network if your LabVIEW application is on a different machine:

sudo systemctl enable redis-server
sudo systemctl start redis-server

The Data Collection Process

Create a Python script that continuously reads your sensors and writes to a Redis stream:

import time
import json
import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

def collect_data():
    interval = 0.001  # 1ms = 1000 Hz sampling
    cycle_time = time.time()
    while True:

        # Read your sensor
        sensor_value = read_i2c_sensor()

        # Add to Redis stream
        r.xadd('sensor_stream', {
            'value': sensor_value,
            'timestamp': cycle_time
        })

        # Delay enough to start next loop at the interval rate
        time_to_next_cycle = cycle_time + interval - time.time()
        sleep_time = max(0, time_to_next_cycle)
        time.sleep(sleep_time)
        cycle_time += interval

if __name__ == "__main__":
    collect_data()

import time
import json
import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

def collect_data():
    interval = 0.001  # 1ms = 1000 Hz sampling
    cycle_time = time.time()
    while True:

        # Read your sensor
        sensor_value = read_i2c_sensor()

        # Add to Redis stream
        r.xadd('sensor_stream', {
            'value': sensor_value,
            'timestamp': cycle_time
        })

        # Delay enough to start next loop at the interval rate
        time_to_next_cycle = cycle_time + interval - time.time()
        sleep_time = max(0, time_to_next_cycle)
        time.sleep(sleep_time)
        cycle_time += interval

if __name__ == "__main__":
    collect_data()

This process runs independently, continuously writing data to the stream regardless of whether anyone is reading it. Redis handles the buffering and ensures data isn’t lost.

Accessing Redis from LabVIEW with Webdis

Webdis is a simple web server that provides an HTTP interface to Redis. Install it on your Raspberry Pi:

git clone https://github.com/nicolasff/webdis.git
cd webdis
make
./webdis &

Now you can access Redis commands via HTTP. From LabVIEW, you can read from the stream using the HTTP Client VIs to make requests like:

http://your-pi-ip:7379/XREAD/COUNT/<count>/STREAMS/sensor_stream/$

The $ special ID means “only entries added after this request begins” – it’s useful for your initial read when you want to ignore old buffered samples and start with future data. For subsequent reads to get all new data since your last read, you’ll need to use the actual stream ID you received from the previous read instead of $.

The <count> value represents the maximum number of entries to return. Based on your sample rate and how often you want to read buffered data from the device, you will want to modify this value to keep up with data production on the Raspberry Pi.

LabVIEW Implementation

In your LabVIEW VI:

1. Store the last stream ID you read (starting with “$”).
2. Periodically poll the stream using XREAD with your last ID.
3. Parse the JSON response to extract the sensor values.
4. Update your last stream ID for the next request.
5. Process the batch of samples.

This approach dramatically reduces overhead; instead of 1000 requests per second for 1000 samples, you might make 10 requests per second and get 100 samples each time.

Advantages

• Continuous Collection: The Python process collects data continuously without gaps.
• Buffering: Redis buffers recent data in memory, so if LabVIEW is briefly busy, samples remain available.
• Batch Processing: LabVIEW can read multiple samples per request, reducing overhead.

Adding Time Synchronization

When combining data from multiple sources (like your NI DAQ and Raspberry Pi), timestamp synchronization becomes critical. The Raspberry Pi’s clock and your Windows PC’s clock will drift apart over time, making it difficult to properly align and correlate data.

There are several approaches to tackle this problem:

Measuring Clock Offset: Create a calibration routine in which LabVIEW requests the current time from the Pi and measures the round-trip time to calculate the clock offset. Apply this offset to align timestamps. Keep in mind that different hardware clocks will experience drift and you will need to regularly re-calibrate to account for this.

Network Time Protocol (NTP): Configure both systems to sync with the same NTP server. This gets you in the ballpark but won’t give you perfect alignment due to network delays and update intervals.

Conclusion

Integrating a Raspberry Pi as a data acquisition device in your LabVIEW application enables cost-effective, flexible hardware integration. Your chosen approach depends on your requirements.

For our client’s application, we used the Redis approach with time synchronization to integrate their Raspberry Pi sensors with their LabVIEW system, achieving reliable 1 kHz data collection aligned with their NI DAQ data.

The post How to Use Raspberry Pi as a DAQ Device in LabVIEW appeared first on DMC, Inc..

DEWETRON’s data acquisition chassis uses software called OXYGEN for channel configuration control, high-speed data logging, acquisition triggering, and more. OXYGEN can be controlled via the software front panel itself or, behind the scenes, by any software framework using SCPI commands.

For this test application, DMC chose to integrate control of OXYGEN through our custom application framework based in LabVIEW using DEWETRON’s well-documented SCPI commands and their in-house developed LabVIEW wrappers.

OXYGEN Capability

Before highlighting DMC’s use of SCPI commands to control data acquisition, it is worth noting the design decisions behind selecting DEWETRON’s hardware and the corresponding OXYGEN software.

OXYGEN allows users to configure and manage their own test setups by:

• Naming specific hardware channels
• Applying sample rate, units, and scaling to measurement channels
• Creating trigger events that will start and stop recording data automatically
• Configuring logging settings, with log types available in TXT, CSV, TDMS, and more
• Creating digital value displays that update in real time to allow operators to review test data as it is acquired

and, perhaps most notably for our application:

• Creating AC power groups from available configured channels for detailed multi-phase AC power analysis
  • This power group feature automatically calculates and presents highly accurate and detailed data like active/reactive/apparent power, power factor, fundamental vs total power, and more from simple voltage and current measurements on each AC phase.

Having all of these features configurable in OXYGEN and accessible via SCPI commands on the back-end means we can let users configure and control their data acquisition through DMC’s custom LabVIEW application, which also integrates custom test sequencing.

Interfacing with OXYGEN using SCPI Commands

In order to integrate OXYGEN control into our custom LabVIEW application, we first had to dive deep into DEWETRON’s SCPI programming guide to determine the correct commands. Though this is standard practice when creating new hardware drivers, DEWETRON provides a great LabVIEW driver set that exposes basic SCPI control of OXYGEN via TCP/IP. This driver set includes built-in SCPI functionality to:

• Read channel properties
  • Each channel has separate configurable properties that vary based on the type of hardware
• Configure, start, and stop external data streaming
• Query measurement values for one or more channels
• Query system errors

In addition to the basic drivers listed above, DMC developed additional custom SCPI code modules to:

• Create and configure automated OXYGEN trigger events for controlling digital output channels
  • Using the :TRIGger: command set
• Write OXYGEN channel properties like units, sample rate, etc., from the user’s test configuration setup
  • Using the :PROPerty: command set
• Create time-stamped, descriptive data markers when measurement values exceed any user-configured guardrails during testing
  • Using the :MARKer: command set

Integrating OXYGEN Commands into LabVIEW

A question that the reader may have at this point is: Why bother with using LabVIEW at all? Why not just use OXYGEN to do all data acquisition and skip the SCPI commands?

The answer is that integrating with our custom application framework in LabVIEW enables us to use a tried-and-true device control and measurement sequencing architecture and to integrate with a variety of measurement devices from several manufacturers. It also allowed for a custom user interface experience.

DMC is well-versed in test application development in LabVIEW and has developed several in-house LabVIEW toolkits that allow us to present data to our users in information-dense, highly configurable custom applications.

For this project, DMC has used its custom-developed sequencing toolkit based in LabVIEW that allows our users to configure device control and measurement test sequences with custom test limits. Users can use pre-made sequence steps and string them together to create custom automated test routines tailored to their various systems, and manage those sequence files and their revisions, all within DMC’s LabVIEW application. These test routines may reconfigure a device’s settings, turn a device on/off, start/stop data acquisition, continuously monitor safety circuits, and allow the user to pause, restart, and stop execution at any point.

Additionally, integrating remote control of devices like OXYGEN within our LabVIEW application allows us to modify and standardize on things like:

• Error and warning messages to the user from different devices
• Centralized sequence and diagnostic logging from different devices for system-level troubleshooting
• Standardized device control widgets that are exposed to the user
• Simulated devices for testing in non-laboratory development environments

Conclusion

By leveraging the powerful capabilities of the DEWETRON OXYGEN software and measurement hardware via SCPI commands, DMC seamlessly integrated detailed power analysis and high-speed data acquisition from the TRIONet3 chassis into our custom test sequencing application.

The post LabVIEW Programming for DEWETRON OXYGEN Data Acquisition Integration appeared first on DMC, Inc..

The application leverages the Keysight instrument driver library to handle communication and control, while providing a user-friendly graphical interface (GUI) for remote operation. We also integrated the system with NI TestStand, creating a reusable set of custom steps that simplify sequence development.

System Overview

The goal was to design a flexible, modular system that allows an engineer or technician to:

• Configure measurement parameters for each instrument, using either the LabVIEW GUI or the onboard GUI of each device.
• Execute measurements automatically or under manual supervision.
• Collect and log results for analysis.
• Save and recall instrument states for repeatability.
• Integrate the entire workflow into automated TestStand sequences.

The core of the system is a LabVIEW application that acts as both the user interface and the instrument control framework. Each instrument is managed by its own dedicated driver class, responsible for communication, configuration, and data acquisition. All devices are connected to a controller PC that runs the LabVIEW application via LAN interface.

Using Keysight Instrument Drivers

Keysight provides certified LabVIEW drivers for many of its instruments. The libraries used in this application are as follows:

• RFSA: Keysight XSAn library
• RFNA: Keysight NA library
• RFPM: Agilent E441X Series library

These drivers implement a consistent API structure and follow the VISA standard, making them ideal for this type of automation project.

Our application created an Initialize, Calibrate, Configure, Acquire Data, Save/Recall Device State, and Close step for each device, using a parallel structure to the Keysight API for ease of integration. While these steps mirror the basic functionality of the VIs in the libraries, they allow the application to be more customizable by controlling only the settings we need to help streamline TestStand sequence development. The functions of each step are below:

• Initialize: This step creates an instrument handle that will be used by all other Keysight drivers in the device’s lifecycle
• Calibrate: This step allows the user to perform calibration and zeroing steps on the device (only for RFPM)
• Configure: This step allows the user to select specific settings for the measurements and sends them to the device
• Acquire Data: This step will perform a measurement using the settings specified in the previous step and export the data to the application
• Save/Recall Device State: This step allows the user to save or recall all device settings as a configuration file locally on the device’s drive (Only for RFSA/RFNA)
• Close: This step closes the VISA resource for the device to prevent any memory issues when the app closes

Application Design and Architecture

The LabVIEW application uses an object-oriented approach, with each device having a widget class, an abstract class, a Keysight instrument class, and a simulated class. The widget class uses APIs from the abstract class to call the basic steps listed above. Each widget also contains the GUI for device control from the LabVIEW front-end.

The Keysight instrument class contains device-specific drivers, and the simulated class generates random data when hardware is not available. If we replaced our devices with a non-Keysight model, we could easily add another class for that device’s drivers.

GUI Module

The GUI for RFSA has 2 screens, with users able to control basic display settings or recall a state from the device’s settings on the first screen. More settings options are available on the second screen, which is accessible by selecting the “Configure” button. After the user selects their desired settings, they can conduct a measurement using the “Start” button, then set markers using the frequency control or the slider below. The positions of the markers automatically update, and their frequency and amplitude values are displayed below.

The RFNA has a similar GUI but requires fewer settings. It has one screen, allowing the user to control the frequency range and select the test type between Insertion Loss (S12) or VSWR (S11). Like the RFSA, users can recall a device state, start a measurement, and control the marker from this screen.

The RFPM has a different GUI because it only conducts single-channel measurements, as opposed to frequency sweeps. This GUI allows the user to perform a calibration sequence by selecting the type (Calibrate, Zero, or Calibrate & Zero). The user can then select the frequency at which to conduct the measurement and set the resolution for the measurements. When the user selects the “Measure” button, the device conducts a power measurement and displays it both on the device’s onboard GUI and the LabVIEW GUI.

Data Acquisition and Storage

Measurements for each device can be conducted simultaneously, and the data from all three instruments can be automatically logged to local or network drives. For this application, the data is stored in a TDMS file format, but could easily be saved as a CSV or other format as well.

DMC implemented a data tagging system that associates each measurement with metadata such as date, time, operator, device under test (DUT) ID, and test sequence name. This metadata improves traceability and simplifies post-test analysis.

Integration with NI TestStand

DM added an additional layer of efficiency to the RF measurements by integrating them into NI TestStand sequences used across multiple test stations. To achieve this, we created custom TestStand steps that directly call the LabVIEW VIs controlling each instrument. Each step has a wrapper VI that is used to create a TestStand custom step. This allows the user to create sequences in TestStand the same way they would in LabVIEW, but without needing to understand the programming backend. When used in a sequence, the data plots appear in the report generated by TestStand, and the data can be used in pass/fail grading steps during the sequence itself.

TestStand is the foundation of one of DMC’s core battery test platforms for the reasons above and can enhance the accessibility of automation when used in conjunction with well-encapsulated LabVIEW code.

Conclusion

This project demonstrates how combining LabVIEW, Keysight instrument drivers, and NI TestStand creates a powerful and flexible RF measurement automation platform. By automating configuration, acquisition, and reporting for the three devices, we achieved significant gains in efficiency, repeatability, and scalability. The system meets current test requirements and lays the foundation for future automation initiatives. Because of the modular LabVIEW code, we can easily scale the system to add functions, GUI elements, and devices with minimal rework.

The post Automating RF Measurements Using LabVIEW for Keysight CXA, ENA, and EPM Instruments 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, check out 2023 and 2025!

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.  

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. View Our Demo.

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.

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.

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

The Real-Time Advantage—When Determinism is King

LabVIEW RT shines when timing is non-negotiable. Think high-speed control loops, synchronized data acquisition, or safety-critical automation. With platforms like PXI, cRIO, and sbRIO, you get deterministic execution, hardware-level reliability, and the ability to run headless in harsh environments. It’s the kind of setup that makes engineers sleep better at night. 

But it comes at a cost—literally.  

RT systems often require specialized hardware, longer development cycles, and deeper expertise. Controlling costs requires familiarity with all of the hardware and software options out there, a rapidly increasing assortment. That’s why we recommend RT when the application demands it, not just because it sounds robust, and we carefully choose toolsets before we begin based on all the requirements, not just our preferences. 

The PC-Based Powerhouse—Flexibility, Speed, and UI 

Windows-based LabVIEW systems are the unsung heroes of test and measurement. They’re often faster to develop, easier to debug, and offer rich UI capabilities and easy data storage that RT typically just can’t match. Do you need to integrate with some weird DLL or third-party drivers? Then a PC may be your only friend. 

We’ve built PC-based systems for everything from EV battery validation labs to simple torque acquisition carts. Yes, these systems can be stable—if engineered with experience and care. We have clients that run PC-based testers for years without problems. The secret? Thoughtful architecture, plenty of lessons learned, and smart error handling. 

Stability Isn’t Exclusive to RT 

While RT systems are quickly becoming all the rage, a common misconception is that only RT systems are stable enough to handle long-term testing. While RT does offer inherent stability, Windows systems can be just as reliable with the right design. We’ve modernized many legacy LabVIEW codebases to run on modern Windows platforms, with smart improvements for stability. The result? Systems that are easier to maintain and just as robust. 

Hybrid Systems —The Best of Both Worlds 

Here’s where things get interesting. Many clients don’t realize that they don’t have to choose between RT and PC—sometimes they really need both. Hybrid systems combine RT for deterministic control and PC for orchestration, visualization, and data management. 

We’ve been building hybrid architectures for decades. Consider a test system where a cRIO handles real-time DAQ and control, while a Windows PC manages the UI, logging, and remote access. They also naturally facilitate extension outside of the NI Universe, if additional third-party RT systems are needed, like UEI, Beckhoff, etc. These systems require well-designed interfaces (TCP/IP, UDP, shared memory, OPC UA, EtherCAT, etc.), but when done right, they’re elegant yet robust, scalable and cost-effective. 

One of our engineers likes to say, “RT is the brainstem, PC is the cortex.” It’s a metaphor that works. Each part does what it’s best at, and together they form a complete system

Real-World Examples and More to Explore 

Explore some examples of DMC’s work.

• RT-101: Real-Time Operating Systems (RTOS)
• RT-301: Capabilities of Distributed LabVIEW Real-Time
• Real-Time EtherCAT Motion Control with NI cRIO and Embedded UI
• Real-Time Battery Testing: A Synergy of NI LabVIEW, TestStand, and VeriStand
• LabVIEW Real-Time solution for Chemical Process Monitoring
• Real-Time FPGA System for Fast-Responding High-Voltage Arc Detection
• Browse more examples across industries. 

What We’ve Learned at DMC 

From NI VeriStand to RT Linux to PAtools, NI cRIO to UEIdaq and PowerDNA to NI PXI, we’ve worked across platforms and industries. We’ve learned that the best solution often isn’t the most complex one. Sometimes a PC-based system with a solid framework beats a full RT deployment. Other times, RT is the only way to meet timing and safety requirements. Often, the sweet spot is somewhere in between. 

We’re proud to be one of NI’s Platinum Partners and an NI Center of Excellence. That means we don’t just build test systems—we build the right test systems for your requirements. 

Conclusion 

Choosing between LabVIEW RT and PC-based systems isn’t a binary decision. It’s a conversation—one that should consider timing, cost, stability, and long-term goals. Sometimes, the best answer is “both.” If you’re wondering which path is right for your next test system, let’s talk. We’d love to help you engineer a solution that’s not just functional—but exceptional. 

The post LabVIEW Real-Time: When to Opt for RT and When to Stick to PC appeared first on DMC, Inc..

Standardizing helps, but building a “company framework” from scratch can take quarters (or years) and divert your best engineers. Even after it’s built, engineers inevitably come and go, and soon you may be left with no one who truly understands what you’ve built in-house. 

CORTEX changes the equation. 

What Is CORTEX?

CORTEX is a modular automated test framework built on NI TestStand and LabVIEW that engineering teams use to standardize production and non-real-time validation workflows. It combines a hardware abstraction layer (HAL), custom step types, process model and reporting plugins, and an operator-friendly application to deliver a repeatable platform you can deploy across benches, stations, and sites. 

Is CORTEX Right for Your Team? 

Choose CORTEX if you want to stop reinventing a framework for every new station, deploy consistently across benches and sites, integrate quickly with diverse hardware, and improve reliability with standardized safety and reporting. 

CORTEX Highlights 

• CORTEX standardizes sequencing by leveraging TestStand with a custom Sequence Editor and reusable step libraries. TestStand is an open and industry-leading test sequencer, with plenty of experts who know how to develop tests using this tool and plenty of training for those looking to get started. 
• It abstracts hardware through a HAL and plugin classes for your devices and instruments, including but not limited to: DMMs, Digital/Analog IO, Serial & Industrial Communications, Power Supplies, PLCs, and more. 
• It prioritizes configuration over code with dynamic workspaces, station configurations, and socket mapping for multi-up stations. Your team can spend more time on the configuration without needing to be programming experts. 
• It delivers a production–grade user experience with Auto and Manual test modes, device dashboards, live data channel viewer, alarms, and a roles-based user-permission schema. 
• It ensures reporting and traceability with a combination of Test reports and engineering waveform logs, so you can understand what your test system was doing over the entire test, regardless of what you actually graded. 
• It integrates with your ecosystem: Need to connect to your PLCs/MES for material handling? What about that company database you’ve standardized on? Does your IT want to control user permissions? No problem—CORTEX can integrate with PLCs, custom databases for custom reporting, and IT systems by using LDAP to ensure the application works well in your environment. 

Architecture at a Glance

• The CORTEX app runs tests in Auto or Manual mode and provides dashboards, alarms, and live data visualization. 
• The CORTEX Sequence Editor enhances TestStand with custom tools for workspace management, signal mapping, and test point configuration. 
• TestStand process model and plugins handle device management along with safety interlocks, configuration management, and reporting workflows. 
• The HAL and device plugins integrate instruments like power supplies, standard DAQ, and common industrial communication protocols like Modbus and Ethernet/IP that let engineers configure tests at a high level without the need to dive into low-level code. 
• Data is captured in TDMS logs and TestStand reports, with the ability to correlate data output from both of these files and view them together to provide a comprehensive understanding of the test results. 

What You Get Out of the Box

• Auto Test Mode runs looping, operator-focused sequences with perUUT reports and live sequence execution view with debugging tools. 

• Manual Test Mode gives engineers direct control to run subsequences and operate instruments via device widgets. 

• The Channel Viewer provides real-time signal plots for monitoring and troubleshooting. 

• The Test Results Viewer correlates parametric results with waveform data for faster root cause analysis. 

• Alarms and history views simplify troubleshooting and improve operator understanding of system operations. 

• User permissions enforce role-based access for operators, engineers, and administrators. 
• Safety monitoring runs independently to terminate execution if limits are exceeded. 

How to Get Started with CORTEX

1. Schedule a Discovery Call 
   We’ll start by learning about your current testing setup, your pain points, and your future needs. This helps us understand where CORTEX can deliver the most value. Contact us to schedule a call.

2. See a Live Demo 
   We’ll walk you through the CORTEX framework, including its Sequence Editor, operator interface, and hardware abstraction layer. You’ll see how it simplifies test development and standardizes workflows. 

3. Discuss Your Hardware and Integration Needs 
   We’ll review the instruments, PLCs, and systems you need to connect, and outline how CORTEX’s plugin architecture can support them. These can include both short and long-term needs. 

4. Plan a Pilot Deployment 
   Identify a representative test station that we can deploy CORTEX to for an initial assessment and quick win. The best way to help you become convinced of the value of CORTEX and demonstrate the savings to your management is by experiencing it. After an initial deployment, we’ll work with your team to build a roadmap for scaling across your organization. 

Need hard Real-Time Test Sequencing?

TestStand is awesome at many things, but one thing it’s not suited for is real-time deterministic sequencing (e.g., submillisecond HIL control). If you need software that can do real-time simulation, emulation, or test sequencing, reach out to DMC to learn more about our custom HIL test solutions, as demonstrated in these case studies:  

• Power HIL Test Stand for an Autonomous Air Vehicle
• Battery Stack Simulator for Hardware in the Loop (HIL) Testing of Electric Vehicles

The post Standardize Your Automated Test Systems—Without Starting From Scratch appeared first on DMC, Inc..

Target Connection

Firewall issues typically emerge when communicating with multiple targets (computers or DAQ hardware). The first step when connecting to an external target is to confirm that you can at least ping it—preferably both directions. By default, Windows Firewall disables incoming ping requests to its computers.

Enabling Ping

Perform the following steps on any Windows device where you want to receive pings.

1. Open Windows Defender Firewall and select Advanced Settings in the sidebar. Depending on your organization, you may need administrator rights or an IT employee to do this.
2. Switch to Inbound Rules via the Getting Started page or the sidebar.
3. Find the rule named “Core Networking Diagnostics – ICMP Echo Request (ICMPv4-In).” Right-click the rule and Enable Rule for all relevant network types (Private, Domain, Public). The rule may also be named “File and Printer Sharing (Echo Request – ICMPv4-In).”

Once you can ping back and forth between your two targets, then you know the connection is set up correctly, and any additional issues are in the LabVIEW and Windows Firewall interaction.

Common Firewall Issues

So, how do you know if Windows Firewall is causing your problem? Here are a few common symptoms you might see.

1. TCP or UDP messages sent between two separate LabVIEW applications on the same or different targets aren’t making it to their destination.
2. Intermittent connection errors to external devices or computers. If connecting via TCP, this will likely manifest as Error 56.
3. Failure to connect to NI hardware in NI MAX, or open DAQmx or IMAQdx resource connections.
4. If using Shared Variables, errors when pulling data from the Shared Variables.

If you’re seeing unexplained or inconsistent network operation errors after you’ve confirmed that the two targets are connected, then Windows Firewall should be a suspect.

Troubleshooting and Resolution

Disable the Firewall and Add Rules

The first step to determining if the firewall is the culprit is, if possible, disabling the firewall altogether. If this resolves the issue, but you can’t leave the firewall off, then it’s time to explore adding firewall rules. NI has a list of ports that they use that can be worth enabling if you are experiencing an issue with one of their listed tools. However, it’s common for custom LabVIEW applications to use custom or dynamic port numbers. In that case, you’ll want to make firewall rules not only for the ports you’re using, but also to allow all ports for the specific LabVIEW application you’re running. Microsoft outlines some risks to doing this, as well as instructions. The important thing to remember is that with no firewall, the ports and applications are more vulnerable, so only allow what you actively plan to use.

Run a TCP or UDP Tester

If you’ve added firewall rules or haven’t been able to troubleshoot whether the firewall is the issue, a great way to test LabVIEW’s ability to access network resources is using a tester. LabVIEW ships with a TCP/IP communication tester. Running this for a while and logging any errors can help determine if the issues you’re encountering are intermittent and possibly firewall-related, or if there’s something else in your application causing issues. Running just this tester distills out only the network operation from LabVIEW—it’s like the LabVIEW equivalent of constantly pinging. If you’re able to run this successfully, then there may be other issues at play beyond the firewall.

We Can Help

Fighting with the firewall, or any mysterious LabVIEW TCP connection errors, is better with a partner. If you’re looking for support as you troubleshoot existing systems or prepare to set up new ones, we’d love to help.

The post Diagnosing LabVIEW: Windows Firewall and What to Do appeared first on DMC, Inc..