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..

Here are three practical ways DMC has used AI and Python to optimize a real-time inspection system and deliver real results to our clients.

1. Profile Your Pipeline to Find the Bottlenecks

As you move from implementation to production, the slower parts of your code can become painful while remaining hidden. In fact, slow lines of code can show up in surprising places and, depending on how your pipeline is structured, have an outsized effect on your speed. The solution is to bring a magnifying glass to your code by profiling it.

I’ve been a heavy user of Jupyter notebooks inside VS Code, which allows me to use the AI coding agent of my choice to easily set up and run experiments against my inspection pipeline to understand how it runs in practice against specific examples and, more relevantly, how long each section of the pipeline takes to run.

For example, one recent system DMC worked on involved belt masking. A client needed to inspect yellow tortillas moving down a blue conveyor belt, so we had to isolate each tortilla on each frame, separating it from the background for later steps in our analysis. The naive-but-useful approach we started with computed a full-resolution color distance, each pixel relative to the average color of the belt. This gave us a reference for what a functionally correct approach looks like, but profiling the code in conversation with AI showed us that it took up the majority of its time analyzing each frame.

2. Redesign Expensive Metrics to be Computationally Cheaper

Once you know which stage is slow, the next lever is the algorithms inside it. Many vision metrics have a naive implementation that’s accurate but expensive, and a smarter implementation that’s nearly as accurate and far faster.

After profiling the inspection system, we looked for ways to optimize it. A faster approach involved shrinking the frame by 50% on each side to reduce the number of computations by 75%. Comparing against the full-frame approach, we saw minimal reduction in accuracy. Additionally, by computing distances, we were performing a square root operation before comparing the distance to a threshold parameter; we could ditch that operation by squaring the threshold parameter and then comparing the squared distance, which sped up the process even further with no reduction in accuracy.

Eventually, we switched from checking RGB color distance to an axis-aligned range, which had similar accuracy while drastically reducing the computational load per frame. AI was vital here for quickly brainstorming and drafting these alternative formulations so we could compare their performance and accuracy.

3. Use Synthetic Data to Stress-Test Thresholds and Edge Cases

Optimization isn’t only about speed; it’s also about ensuring the system remains correct under pressure and across the full range of inputs. It’s hard to verify with only a handful of real images, which is often the case at the pre-deployment stage of a project.

Synthetic data can fill this gap. By generating test subjects across the entire pass/fail spectrum, including rare failure modes, you can stress-test thresholds and confirm the optimized pipeline still behaves correctly on edge cases.

In our example of the tortilla inspection project, we used a Python script to programmatically generate AI images of tortillas with different levels and types of defects by varying the prompts. For example, each tortilla prompt was given a probability of having a prompt addition specifying a torn edge or a burn mark. After generating 100 tortillas, we used another script to create simulated footage of these tortillas moving down a looping belt texture, with added random noise and motion blur, which we then used to verify our pipeline’s capabilities before we had any real footage to work with. These efforts allowed us to deploy our code into production quickly for our client.

Conclusion

These threThese three practices work together to create a more efficient and reliable system:

• Profiling identifies where to focus your optimization efforts.
• Metric redesign speeds up slow stages exposed by your profiling.
• Synthetic data ensures your system remains accurate across edge cases.

Each of these stages has always been essential to vision inspection, but AI and modern coding tools have made them faster and easier to implement. Additionally, unlike certain uses of AI that have greater exposure to risk, like code implementation, using AI here is less likely to cause major faults in your system. That said, AI should be an accelerator, not a replacement for engineering judgment. It is essential to verify that AI-generated code is correct and aligned with system requirements.

Ultimately, the impact of these practices is clear. By combining these approaches, you can confidently improve the speed and reliability of your real-time vision inspection pipeline.

The post 3 Ways AI Improves Real-Time Vision Inspection with Python 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..

TDMS files store data in a binary format that allows you to rapidly write data as waveform chunks. This works well for the kind of high-frequency data we handle often in the world of test and measurement. When working with LabVIEW, it serves as a complement to their DAQ API which reads high-frequency data in chunks from a hardware buffer. In contrast, writing such data to CSV files would usually require either writing data a few rows at a time or storing data in memory until it is ready to be written in uncompressed plaintext.

For all these reasons, it is a great format to write to except for the fact that reading TDMS files can sometimes be a hassle.

Currently, if you want to view TDMS files, you have a few options:

• DMC SuperViewer: I might be biased but our free downloadable utility to browse TDMS files is probably the best offline option.
• TDM Excel Add-In: This NI plugin lets you open your TDMS files in Excel. If your machine has an MS Office subscription, then it might be a viable option.
• NI DIAdem: A powerful application that lets you process multiple streams of data but requires an NI license.
• NI FlexLogger: As part of a larger feature set, NI FlexLogger allows you to view TDMS files. The Lite version is free.

These options all require a download and installation process.

As an alternative, we’ve developed a WebTDMS–a TDMS and CSV file viewer which you can open in your browser. There’s no installation necessary! It is designed to be flexible with its many advanced analysis tools but easy to use with its clean interface.

Features

On the left side, you can drop in your various TDMS and CSV files to be read. You can also explore the example data that displays by default to test its various features. Let’s review the various tabs to see what features we have.

Charts

On the left side, you can select all the waveforms you would like to view in each file that you’ve uploaded. On the right side, you can view those waveforms as a scatter plot, line plot, or histogram.

Raw Data

You can view the raw data from your files next to each other and even download all your data as a single CSV file. You can even use filters to exclude rows where values for a column are outside your specified range.

Profiler

Data Tab

This section has a separate raw data viewer with paginated rows as well as an indication of the distributions of each column’s values.

Visualization View

For a more complicated multivariate analysis of data, you can use the Visualization section.

Group/Channel Properties

In this section, you can view the group and channel properties for TDMS files alongside a preview of each channel.

Calculated Channels

Finally, we have the flagship feature that lets you quickly perform mathematical analysis on your data. Taking inspiration from what makes LabVIEW great for data–that it is a dataflow language–this section allows you to create new channels that you can use in all the sections above using blocks of logic.

The logic above creates the chart below in the Charts section:

There is also a public version of the app with a 50 MB file limit that you can access. If you think this application is useful and that maybe a customized version of it would be perfect for your needs, please reach out to us!

The post WebTDMS: A Powerful TDMS and CSV Analyzer appeared first on DMC, Inc..

Hardware experts don’t always have hours of time to invest in staying updated on the latest in LabVIEW like we do at DMC. Understandably, this can result in code that doesn’t follow standard architecture or best practices.

We’ve seen every kind of graphical code structure under the sun. It takes time to follow the hundreds of wires and many parallel loops to figure out what makes a program behave the way that it does.

Me analyzing LabVIEW code for the first time

Using OpenAI and LabVIEW

Text-based languages have benefitted from recent advancements in tools used to analyze and write code like Python with tools like GitHub Copilot. NI has been hard at work too, as evidenced by their recent demo of Nigel, but they haven’t yet released it.

In the meantime, I thought I could try something rudimentary to achieve a similar outcome using the GPT API from OpenAI with a few tricks to make it work on VI files (files for LabVIEW written in their G language). I wanted to see if I could use GPT to describe LabVIEW code.

Here are the steps:

1. Convert the LabVIEW graphical code to text-based code.
2. Pass the text-based code to GPT and ask it to analyze the code.

Converting Graphical Code to Text-Based Code

Step 1 basically describes a transpiler which is a compiler that takes code in one language and produces equivalent code in a target language, though as we’ll see that’s easier said than done. For my purposes, I decided to target Python-like code since it isn’t strictly typed and would let me get away with leaving out a lot of information about data types. It’s also likely that GPT is trained on tons of Python code and trying to use a language more equivalent to LabVIEW code would mean implementing more programming constructs in the transpiler or creating a proprietary intermediary language as NI has been doing with Nigel.

The first major hurdle is the fact that LabVIEW code isn’t written as a series of sequential statements. Instead, it is a data-flow language which uses “wires” to transfer information from block to block. This makes it especially great for simple-looking implementations of multi-threaded applications but annoying for our purposes. Luckily, this construct maps well onto the concept of computational graphs and we can try to move from code to a more abstract graph to make our life simpler. We can think of LabVIEW code as a “directed acyclic graph” with a set of start nodes (controls) and end nodes (indicators) connected by edges (wires).

But how do we convert LabVIEW code to a computational graph? Using VI Scripting of course! NI has a library of tools that lets you find all instances of a specified type of LabVIEW programming construct and if we look for all wires and note what pair of objects each one joins, we can build our graph.

We then take the graph and use a custom scheduler algorithm to create a sequence of operations for each of the code blocks and finally use the metadata of each wire’s two terminals to provide some additional data in the transpiled code.

Ask GPT to Analyze the Code

Add in some logic to avoid accidentally using the variable names in multiple places using UIDs and we’re basically done! All we do now is ask GPT to describe the code in terms of what it represents and not the actual variables themselves and we have a crude AI-powered VI analysis tool.

Except that it doesn’t work for:

• For loops
• While loops
• Broken code
• Cases where there are orphaned blocks
• Feedback loops
• Analyzing sub-VIs
• Etc.

You get the idea. Perhaps with a more structured approach to VI scripting and fine-tuning with example code, it might be possible to get more out of this idea, but I think this serves as a useful demo to see what might one day possible!

The post Creating Custom AI Tools to Analyze LabVIEW Code appeared first on DMC, Inc..

We chose multiplexers that are rated for high voltages, can carry a decent amount current, and are rated by their manufacturer to have their relays switched on and off plenty of times. These are mechanical systems, however, and, if you build enough test systems with multiplexers that constantly switch relays on and off, one of them will eventually fail. Any part of a factory line system failing means downtime, which can lead to losses.

The best approach to test systems that last and deliver value is to expect that they may fail at some point. At DMC, we design tools to delay and diagnose the inevitable as opposed to ignoring it.

To this end, we deployed our project with a diagnostic sequence and additional hardware that the client could use periodically to detect wiring and relay faults so we can fix them. There are several ways in which this idea can be applied.

Take the example of testing a standard 120V AC outlet: we need to check that we see ~120V between live and neutral as well as live and ground but ~0V between neutral and ground.
 
In our case, we mapped DMM and each of the test points to multiplexer coordinate “paths” and those paths to human-readable names through our custom “MUX Manager” library. This enabled us to control relays with Python lines like these:

mux_manager.get_pin_path(<Pin Name>, <Rail>)

mux_manager.set_pin(<Pin Path>, <New State>)

mux_manager.read_pin(<Pin Path>)

mux_manager.clear_all()

mux_manager.get_pin_path(<Pin Name>, <Rail>)

mux_manager.set_pin(<Pin Path>, <New State>)

mux_manager.read_pin(<Pin Path>)

mux_manager.clear_all()

If we wrote a generic method in a test class to measure the voltage between two pins, a first attempt would look something like this:

 class VoltageTest:
    …

    def test_voltage(self, pin_a, pin_b, expected, tolerance): 

        self.mux_manager.clear_all()

        path_a = self.mux_manager.get_pin_path(pin_a, Rail.POSITIVE) 

        path_b = self.mux_manager.get_pin_path(pin_b, Rail.NEGATIVE) 

 

        self.mux_manager.set_pin(path_a, True) 

        self.mux_manager.set_pin(self.dmm_positive_path, True) 

        self.mux_manager.set_pin(path_b, True) 

        self.mux_manager.set_pin(self.dmm_negative_path, True) 

        measurement = self.dmm.read_voltage()

        # Clearing up connections

        self.mux_manager.clear_all()

        if (expected - tolerance) < measurement < (expected + tolerance): 

            return "PASS"

        else:

            return "FAIL"

 class VoltageTest:
    …

    def test_voltage(self, pin_a, pin_b, expected, tolerance): 

        self.mux_manager.clear_all()

        path_a = self.mux_manager.get_pin_path(pin_a, Rail.POSITIVE) 

        path_b = self.mux_manager.get_pin_path(pin_b, Rail.NEGATIVE) 

 

        self.mux_manager.set_pin(path_a, True) 

        self.mux_manager.set_pin(self.dmm_positive_path, True) 

        self.mux_manager.set_pin(path_b, True) 

        self.mux_manager.set_pin(self.dmm_negative_path, True) 

        measurement = self.dmm.read_voltage()

        # Clearing up connections

        self.mux_manager.clear_all()

        if (expected - tolerance) < measurement < (expected + tolerance): 

            return "PASS"

        else:

            return "FAIL"

We need to clear up the connections at the end of each function call to leave the multiplexer in a clean state so that calls to test_voltage can be rearranged in a test sequence by an engineer without worrying about what pins are previously enabled. On the other hand, when we imagine how such a method would be used, we start to see some redundancy. In testing the 3-pin outlet, we would have to enable and disable DMM pins 12 times and get similar inefficiencies with the pins being tested.The problem is compounded when this generic function is run hundreds of times in one sequence and that sequence is run hundreds of times. The likelihood of a single relay failing (and therefore risk of downtime) is made unnecessarily high by lazy programming.

 
Instead, we could use our knowledge about our system and the math abilities of Python to eliminate this redundancy with a method in the MUX Manager:

class MUXManager:

    …

    def masked_set_pins(self, pin_and_rail_list):

        high_pins = set()

        for pin_name in self.pin_names: 

            pin_path_positive = self.get_pin_path(pin_name, Rail.POSITIVE) 

            pin_path_negative = self.get_pin_path(pin_name, Rail.NEGATIVE) 

            if self.read_pin(pin_path_positive):

                high_pins.add(pin_path_positive) 

            if self.read_pin(pin_path_negative):

                high_pins.add(pin_path_negative)

        need_to_be_high_pins = set()

        for pin_name, rail in pin_and_rail_list:

            pin_path = self.get_pin_path(pin_name, rail)

            need_to_be_high_pins.add(pin_path)


        need_to_make_low_pins = high_pins - need_to_be_high_pins

        for path in need_to_make_low_pins:

            self.set_pin(path, False)

        need_to_make_high_pins = need_to_be_high_pins - high_pins

        for path in need_to_make_high_pins:

            self.set_pin(path, True) 

class MUXManager:

    …

    def masked_set_pins(self, pin_and_rail_list):

        high_pins = set()

        for pin_name in self.pin_names: 

            pin_path_positive = self.get_pin_path(pin_name, Rail.POSITIVE) 

            pin_path_negative = self.get_pin_path(pin_name, Rail.NEGATIVE) 

            if self.read_pin(pin_path_positive):

                high_pins.add(pin_path_positive) 

            if self.read_pin(pin_path_negative):

                high_pins.add(pin_path_negative)

        need_to_be_high_pins = set()

        for pin_name, rail in pin_and_rail_list:

            pin_path = self.get_pin_path(pin_name, rail)

            need_to_be_high_pins.add(pin_path)


        need_to_make_low_pins = high_pins - need_to_be_high_pins

        for path in need_to_make_low_pins:

            self.set_pin(path, False)

        need_to_make_high_pins = need_to_be_high_pins - high_pins

        for path in need_to_make_high_pins:

            self.set_pin(path, True) 

By using set differences, we know which relays to turn off and on from a previous state and avoid any calls in the process that would be redundant.

This is not a perfect approach and requires knowledge of the system such as whether you would be performing any hot switching or there needs to be an order to the switch calls.

For our voltage tests, however, this approach was the right one and worked best for our client’s needs. We can rewrite our test_voltage method to incorporate this new method as follows:

class VoltageTest:

    …

    def test_voltage(self, pin_a: str, pin_b: str, expected, tolerance): 

        self.mux_manager.masked_set_high_pins([

            (pin_a, Rail.POSITIVE), 

            ("DMM+", Rail.POSITIVE), 

            (pin_b, Rail.NEGATIVE), 

            ("DMM-", Rail.NEGATIVE),

        ]) 

        measurement = self.dmm.read_voltage()

        if (expected - tolerance) < measurement < (expected + tolerance): 

            return "PASS"

        else:

            return "FAIL"    

class VoltageTest:

    …

    def test_voltage(self, pin_a: str, pin_b: str, expected, tolerance): 

        self.mux_manager.masked_set_high_pins([

            (pin_a, Rail.POSITIVE), 

            ("DMM+", Rail.POSITIVE), 

            (pin_b, Rail.NEGATIVE), 

            ("DMM-", Rail.NEGATIVE),

        ]) 

        measurement = self.dmm.read_voltage()

        if (expected - tolerance) < measurement < (expected + tolerance): 

            return "PASS"

        else:

            return "FAIL"    

Our method is more readable and efficient while reducing the relay switches per measurement. The animation given shows the decreased switching actions needed (from 24 down to 12) with this new approach — which is even more pronounced for outlets with more pins.

 
What I like most about this whole endeavor is that it confronts the fact that it illustrates how thoughtful engineering design can be exemplified in many ways — in hardware and software. By complicating how our software works, our hardware takes fewer steps and lives longer. Good multiplexing is, well, multiplex.

Learn more about DMC’s Battery Pack and BMS Test Systems and contact us today for your next project.

The post Using Algorithms for Efficient Multiplexing appeared first on DMC, Inc..