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

The goal of this post is to provide concrete examples, explanations, and definitions of terms so you can more easily make use of the QAbstractListModel class. For your reference, you can see the complete example code on GitHub.

Example GUI

Let’s say we’ve got a list of devices with which our software interacts. The data we’ve got for each device is:

• A human-readable name (a string)
• A serial number (an integer)
• Whether or not the device is currently connected (a Boolean)

Our example GUI will look like this:

Part of the appeal of Qt is that you can make extremely slick UIs. We will not be doing that here in order to keep the focus on listmodel concepts. I’ve resisted the urge to add eye candy for the sake of clarity, and I have crafted the example to make it clear how you could stylize the list if you wanted to.

Additionally, the example uses Qt’s Python bindings (PySide6). Everything here is equally applicable to C++, but again, for the sake of simplicity, it is presented as a Python application. The QML is identical in both cases.

The QML Description

First, we’ll describe the visualization of our list of devices in QML. The QML ListView class is a great start. We’ll set three properties:

• model: this is what we’ll use to bind the QML ListView to a QAbstractListModel class defined in C++ or Python

• delegate: this is used to define how each item in the list is rendered as a QML object
• highlight: this is not necessary to use a ListView, but it is generally useful to visualize a selected item in the list

Basic Example

A rough first draft of the QML might look like this (for the final version, see here):

ListView {
    id: deviceList

    model: controller.listmodel
    delegate: Item {
        width: deviceList.width

        Text {
            text: "Placeholder"
        }

        MouseArea {
            anchors.fill: parent
        }
    }  // Item delegate

    highlight: Rectangle { color: "lightBlue" }
}  // ListView

Using the Model and the Delegate

In my main() function, I set a context property called controller that refers to an instance of my Controller class:

qml_app_engine = QQmlApplicationEngine()
qml_context = qml_app_engine.rootContext()
controller = Controller(parent=app)
qml_context.setContextProperty("controller", controller)

qml_app_engine = QQmlApplicationEngine()
qml_context = qml_app_engine.rootContext()
controller = Controller(parent=app)
qml_context.setContextProperty("controller", controller)

The Controller class exposes a Qt property called listmodel. Note that that property is declared as a QObject in my Python code, and that it does not need a property change signal (i.e., I use constant=True). In the QML above, I bind the ListView‘s model property to the listmodel property of my controller object:

model: controller.listmodel

The delegate property of ListView is like a template that defines how each item in the list is rendered as a QML object. For the sake of demonstration, we’ll keep it simple here. I made it a QML Item that is as wide as the ListView itself and contains a Text object and a MouseArea, but you can make it anything you like (you’ll generally make it much fancier)! For example, you might instead have something like a RowLayout containing a Checkbox, an Image, and a Text. (Haven’t used layouts yet? Start here!) However you want each item in your list to be visualized, you can define it in your delegate. For simplicity, I often start by just rendering it all in a Text item. We’ll look at how to access each item of data (name, serial number, and connection status) in the next section.

Note also that the MouseArea in my delegate is used to select an item in the list. Each item in the list is instantiated as a delegate object, so each item in the list has a MouseArea that can handle click events. We’ll look at this in more detail later also.

The QAbstractListModel Class

If you are managing a large quantity of data and you want to visualize it on your QML GUI, you have a few options. For simple cases, a Repeater can usually get the job done just fine and is conceptually very easy to grasp. However, for very large lists, a Repeater is not recommended because it instantiates all visual items at once. In cases where you have a lot of data, you often only want to view or update a small section of it. For these cases, QML provides the ListView object, which expects to be bound to a QAbstractListModel object in your C++ or Python application.

QAbstractListModel is an abstract class that cannot be instantiated itself, so you need to create a new class that inherits from it and is specialized for your needs. I would first suggest reading the section of its documentation titled “Subclassing,” which states that:

When subclassing QAbstractListModel, you must provide implementations of the rowCount() and data() functions. Well behaved models also provide a headerData() implementation.

If your model is used within QML and requires roles other than the default ones provided by the roleNames() function, you must override it.

For editable list models, you must also provide an implementation of setData() and implement the flags() function so that it returns a value containing Qt::ItemIsEditable.

It’s unlikely that those few sentences made it immediately obvious what you need to do. Let’s start with what confused me most when I got started: the concept of a “role.”

Roles

Think about the data we’re presenting. We have a list of devices, and each device in the list has three pieces of data (name, serial number, and connection status). You might think of each device’s data as a row in a table:

The simplest analogy is that the “role” is the piece of data that goes in each column. You might also think of it as identifying each piece of data in each object in the list. So, we will define our “roles” as name, serial, and connected.

Notice also that Qt provides a built-in ItemDataRole enum. I initially found this very confusing, because it provides roles with names like Qt::DisplayRole and Qt::EditRole, which don’t really sound like individual data items to me. The built-in roles are intended for use with built-in classes like QString and QIcon, and they don’t necessarily make sense for this particular custom class, so don’t let it throw you off. Consider though, that you might have roles (items of data in your class) that aren’t pieces of data that you’d want to render as text but are instead pieces of data that determine how the display of that data behaves (like a background color or an icon).

Roles that you want to define yourself for your own custom class can use enum values starting with Qt::UserRole, which has value 0x0100 = 256.

An Aside on Tables

It’s worth mentioning that there is indeed a QAbstractTableModel class as well. As shown above, we can use the role as the “second dimension” of our one-dimensional list, making it look like a table. So, when would you use QAbstractTableModel? You might use it when you have a 2D array of objects, where each object has a set of properties that you identify as “roles.”

What makes the most sense as a data model will depend on your specific data, and it may be confusing to think about a list in terms of “rows” if your data doesn’t really seem like a table (you may not even arrange items vertically on your UI, which makes the terminology much worse!). We’re stuck with the “row” and “column” terminology used by Qt here, but the models can be used in whatever way makes the most sense for the data you need to represent.

In most real-life applications (as well as in the example code here), I use a 1D array with multiple roles, because I find that to be the simplest and most natural data structure. However, both QAbstractTableModel and QAbstractItemModel are available to you if you need a more complex visualization of more complex data. Once you get a handle on QAbstractListModel, the more general classes will make more sense.

How are Roles Used in QML?

As shown above, you will use the QML ListView‘s model property to specify an object in your C++ or Python code that inherits from QAbstractListModel. The delegate property is then used to define the QML object that will visualize that data. In this case, each item in the list has three roles (name, serial, and connected), and we’ll want to access each of those data items in QML independently.

Looking at the GUI again:

Each item in the list is visualized as a Text item where the content follows this pattern:

[index of item]: [name role] ([serial role]) - [connection role]

In our delegate, we can access each item of data using the name of the role:

ListView {
    model: controller.listmodel
    delegate: Text {
        text: `${index}: ${name} (${serial}) - ${connected ? "OK" : "NOT FOUND"}`
    }
}

Inside the delegate object we can simply use index, name, serial and connected as if they are bound to the individual data items inside that element of the list. index is provided out-of-the-box by ListView, but name, serial, and connected are the names of roles we define ourselves. Within the delegate object, we can refer to those names, and our child class of QAbstractListModel will provide methods that QML can use to link those names to specific pieces of data.

The index value is also useful in our MouseArea. We added the MouseArea so that the user could click an item in the list and manipulate it. Since the MouseArea is inside the delegate, we have access to the index value. In the MouseArea‘s signal handler onClicked, we will want to set the currentIndex property of the ListView to the index of the item in the list that was clicked:

ListView {
    id: deviceList

    delegate: Item {
        MouseArea {
            onClicked: deviceList.currentIndex = index
        }   // MouseArea
    }  // Item delegate

    highlight: Rectangle { color: "lightBlue" }
}  // ListView

Setting the currentIndex of the ListView enables the ListView to automatically animate the highlight object that we defined. When the user clicks an item in the list, it will move the Rectangle to highlight the selected list item.

As an exercise for the reader, try making the delegate more interesting. Instead of indicating the state of the connected role with just a Text, try using the connected role to set the text color of the delegate, or add an icon to each row that indicates whether or not the device is connected.

Setting Up the Roles

Let’s circle back to this statement in the documentation:

If your model is used within QML and requires roles other than the default ones provided by the roleNames() function, you must override it.

We want to use our own role names for this, so we can use names that make sense in our delegate (like name, serial, and connected). The mapping from integer role enum values (like Qt::UserRole) to strings of characters is established with the QAbstractItemModel::roleNames() method, which your custom listmodel will inherit. All classes that inherit QAbstractListModel need to implement this method, which returns the map from integers to byte arrays. In C++, this map is a QHash<int, QByteArray>, and in Python it is a basic dict. The integer is the role enum value, and the byte array is the string name used in QML to access that role in each item of the listmodel.

I like to set up my roles by doing two things: creating an enum (starting with the value Qt::UserRole and incrementing from there) that enumerates my custom roles, and then creating a dictionary that maps the role enum values to byte arrays (the names used by QML to access elements of the model). In our example, I might do:

class DeviceItemRoles(IntEnum):    
  NAME = Qt.UserRole
  SERIAL = auto()
  CONNECTED = auto()
  _role_names = {
      DeviceItemRoles.NAME: b'name',
      DeviceItemRoles.SERIAL: b'serial',
      DeviceItemRoles.CONNECTED: b'connected'
  }

class DeviceItemRoles(IntEnum):    
  NAME = Qt.UserRole
  SERIAL = auto()
  CONNECTED = auto()
  _role_names = {
      DeviceItemRoles.NAME: b'name',
      DeviceItemRoles.SERIAL: b'serial',
      DeviceItemRoles.CONNECTED: b'connected'
  }

Note again that in Python, the values are byte arrays (b''), not strings.

With this setup, the delegate of our ListView can access each piece of data in each list item using the strings name, serial, and connected. QML knows how the role integers (from the enum) map to the names because it knows that a QAbstractListModel must have a roleNames() method, so now we just need to give it a way to access each piece of data given the list index and the role. That is the job of the QAbstractItemModel::data() method, which we will get to shortly.

Subclassing a QAbstractListModel

Recall from the documentation that subclasses of QAbstractListModel need to implement the rowCount() and data() methods, plus roleNames() if the listmodel is used in QML. We’ll cover these one-by-one, but first let’s define how we’ll store our data.

Data Storage

I find that the easiest way to store the data (for a Python application) is with a list of dictionaries, where each dictionary uses the role enum as the key for each data value. This is by no means the only way, but it is very simple and often sufficient. So, you might start developing your custom listmodel class like this:

class DeviceListModel(QAbstractListModel):

    def __init__(self):

        super().__init__()

        self._data = []



    def add_device(self, name, serial, connected):

        new_row = {

            DeviceItemRoles.NAME: name,

            DeviceItemRoles.SERIAL: serial,

            DeviceItemRoles.CONNECTED: connected

        }



        self._data.append(new_row)

class DeviceListModel(QAbstractListModel):

    def __init__(self):

        super().__init__()

        self._data = []



    def add_device(self, name, serial, connected):

        new_row = {

            DeviceItemRoles.NAME: name,

            DeviceItemRoles.SERIAL: serial,

            DeviceItemRoles.CONNECTED: connected

        }



        self._data.append(new_row)

When we create a new listmodel, the list of data, self._data, is just an empty list. We can then add device data to the list with the add_device() method, which takes the name, serial number, and connection status, puts them in a dictionary with the appropriate role enum values as keys, and then appends that dictionary to the data list.

Now that we’ve established how the data is stored, we can fill out the required methods.

The roleNames() Method

roleNames() is the easiest to implement, because it’s already done! The _role_names dictionary from above is exactly what roleNames() should return, so this one’s a no-brainer:

def roleNames(self):
    return _role_names

def roleNames(self):
    return _role_names

That’s it!

The rowCount() Method

rowCount() is similarly straightforward. The number of rows is just the number of elements in our self._data list. We don’t need to do much here either:

def rowCount(self, parent=QModelIndex()):
    return len(self._data)

def rowCount(self, parent=QModelIndex()):
    return len(self._data)

The only thing to address is that weird parent argument. What’s that about?

It comes from the base class, QAbstractItemModel. The base class is more general. Whereas QAbstractListModel represents a one-dimensional list of items that all have the same type of elements, QAbstractItemModel can describe trees and other complex hierarchical structures. In those cases, you need to provide the index of a parent object in the tree so the rowCount() method can return the number of children of that parent. Once you get your bearings with the QAbstractListModel, you can dig into the QAbstractItemModel, but for now, let’s just ignore parent, because it doesn’t apply to a one-dimensional list. Just give it a default QModelIndex.

The data() Method

Finally, we need to implement a method that will return data values when QML asks for them. The C++ signature of this method is:

QVariant QAbstractItemModel::data(const QModelIndex &index, int role = Qt::DisplayRole) const

QVariant QAbstractItemModel::data(const QModelIndex &index, int role = Qt::DisplayRole) const

So, our implementation of the method needs to take the index of the row we want (as a QModelIndex object) and the role of the individual data item we want (as an integer, like our convenient DeviceItemRoles enum), and it will return the data as a QVariant. With the PySide6 bindings, there is no QVariant. We can return whatever Python object we want, and if there’s no data at that index or with that role, we can just return None. A simple implementation in Python looks like:

def data(self, index, role):

    if role not in list(DeviceItemRoles):

        return None



    try:

        device = self._data[index.row()]

    except IndexError:

        return None



    if role in device:

        return device[role]

    return None

def data(self, index, role):

    if role not in list(DeviceItemRoles):

        return None



    try:

        device = self._data[index.row()]

    except IndexError:

        return None



    if role in device:

        return device[role]

    return None

There’s a little more meat here than in our roleNames() and rowCount() methods. First, we check that the role integer that was passed in is an item in our DeviceItemRoles enum. If it isn’t, then something is looking for a role we aren’t providing, so we’ll just return None.

Next, we’ll try to get the index of the item in the list. Note that you can’t index the self._data list using the index argument directly. You need to call index.row(), which is a consequence of the fact that QAbstractListModel is a child of the more general QAbstractItemModel class, which is not necessarily a 1D list. If you look at the QModelIndex class, you’ll see that, in addition to row(), it also provides column(), as well as various other methods that only apply to more complex structures.

Anyway, if the given index is out of bounds, then something is looking for an invalid row, and we return None. Beyond that, both the index and the role are ok, so we return the appropriate value by indexing the list to get a dictionary, and then looking up the value of the role key in that dictionary. Whatever data was stored there gets returned.

Updating, Inserting, and Removing Data

What was implemented above is sufficient for a listmodel that will never change, but that’s probably in the minority of use cases. If you only have a small-ish amount of static data, it would probably be easier to use a Repeater. More likely, you’ll want to add data to your list, remove data, or change data at runtime, and QAbstractListModel is a much better fit in these situations. In order to manipulate our list contents, we need to understand a few additional concepts.

Signaling Changes to Existing Row Data from the Application

In general, when we bind properties to QML, we provide a signal that we emit when the property changes. QML listens for that signal, and when it gets emitted, it calls the property getter to refresh the value. This is done by a QAbstractListModel by using the dataChanged signal provided by its parent, QAbstractItemModel, which specifies which elements of the model changed (in terms of rows, columns, and roles).

In some cases, you need to emit this signal yourself. For example, we might want our listmodel class to have a method that sets all devices to “disconnected.” That would look like:

def set_all_disconnected(self):

    for d in self._data:

        d[DeviceItemRoles.CONNECTED] = False

    self.dataChanged.emit(self.index(0), self.index(self.rowCount() - 1), [])

def set_all_disconnected(self):

    for d in self._data:

        d[DeviceItemRoles.CONNECTED] = False

    self.dataChanged.emit(self.index(0), self.index(self.rowCount() - 1), [])

In this method, we first loop over all items in the data list and set the connected value to False. Then, we only need to emit a single signal that says that all items in the list have changed (i.e., every index from 0 to rowCount() - 1). The empty list in the last parameter of the signal is a list of roles that changed, which can be left empty to indicate that all roles have changed. In this case, you can specify [DeviceItemRoles.CONNECTED] if you prefer. This only makes a difference if you have many roles.

Signaling Changes to the Collection of Rows

Even if you don’t change any existing data, you might add or remove entire rows, and QML will need to know what to update when that happens. In this case, we use a pair of methods, beginInsertRows() and endInsertRows(), to specify that we’re adding data (and how many rows we’re adding).

Let’s say we want to add a new element to the list after the selected index. We can do that with a method like:

def add_device_after_index(self, idx, name, serial, connected):

    index_of_new_device = idx + 1

    new_device = {

        DeviceItemRoles.NAME: name,

        DeviceItemRoles.SERIAL: serial,

        DeviceItemRoles.CONNECTED: connected

    }



    self.beginInsertRows(QModelIndex(), index_of_new_device, index_of_new_device)

    self._data.insert(index_of_new_device, new_device)

    self.endInsertRows()

def add_device_after_index(self, idx, name, serial, connected):

    index_of_new_device = idx + 1

    new_device = {

        DeviceItemRoles.NAME: name,

        DeviceItemRoles.SERIAL: serial,

        DeviceItemRoles.CONNECTED: connected

    }



    self.beginInsertRows(QModelIndex(), index_of_new_device, index_of_new_device)

    self._data.insert(index_of_new_device, new_device)

    self.endInsertRows()

beginInsertRows() needs three things: the QModelIndex of the parent into which rows are inserted (for 1D listmodels that we’re talking about here, just give it a default one), the row number that the first new row will have after insertion, and the row number that the last new row will have after insertion. I’m never able to remember this, so I almost always consult the helpful diagrams in the documentation for this method.

After that, we insert the new data into our list, and then we call endInsertRows(). The beginInsertRows() method handles emitting a signal for you (rowsAboutToBeInserted), and endInsertRows() handles emitting a different signal for you (rowsInserted) so you don’t have to emit any signals yourself! These signals are used to notify QML that it’s time to refresh the ListView with new rows, and which ones need to be updated (if the model contains large quantities of data, we obviously only want to update as few as possible).

Signaling Changes to Existing Row Data from the GUI

The final scenario we’ll discuss addresses the last part of the QAbstractListModel documentation on subclassing:

For editable list models, you must also provide an implementation of setData() and implement the flags() function so that it returns a value containing Qt::ItemIsEditable.

As you can see above, if the application manipulates data in the QAbstractListModel, it simply needs to emit a signal (dataChanged) to notify QML that there’s something new. The setData() method is used when information goes the opposite direction, from the UI to the application. For example, say the delegate contains a checkbox. If the user clicks the checkbox in a particular row, QML needs to tell the QAbstractListModel that there is a new value for the checkbox’s role at a particular list index. It does this by calling the setData() method, which takes three arguments: the index, the new value, and the role. It will look very similar to the data() method above, perhaps like:

def setData(self, index, value, role):

    if role != MyRoleEnum.SOME_EDITABLE_ROLE:

        return False



    try:

        data_row = self._data_list[index.row()]

    except IndexError:

        return False



    data_row[MyRoleEnum.SOME_EDITABLE_ROLE] = value

    self.dataChanged.emit(index, index, [MyRoleEnum.SOME_EDITABLE_ROLE])

    return True

def setData(self, index, value, role):

    if role != MyRoleEnum.SOME_EDITABLE_ROLE:

        return False



    try:

        data_row = self._data_list[index.row()]

    except IndexError:

        return False



    data_row[MyRoleEnum.SOME_EDITABLE_ROLE] = value

    self.dataChanged.emit(index, index, [MyRoleEnum.SOME_EDITABLE_ROLE])

    return True

In short, you use the index and role arguments to find the data you’re looking for in the model, you set that data to the new value, and then you emit dataChanged.

Summary

The QAbstractListModel (and its base class, QAbstractItemModel) is a powerful way to present a list of data to a user interface, but the extensive abstraction can make the documentation hard to parse. A simple example should help clarify, as well as a small number of important concepts:

• Many of QAbstractListModel‘s methods are inherited from its base classes, and consequently involve a parent QModelIndex that doesn’t apply to a simple list and can be very confusing.
• A “role” is simply a way to specify individual pieces of data in a list item.
• Roles can be used to make a list seem like a table, and that’s fine… you can still use QAbstractListModel!
• When adding items to the list or removing items from it, call the beginInsertRows() and endInsertRows() methods before making your changes, and the correct signals will be emitted for you at the right times.
• If your application updates the model by changing data in an existing item in the list (or multiple existing items in the list), make sure you emit the dataChanged signal after the changes are made to notify QML that it needs to update its views.
• If the user interacts with the QML UI and modifies data in the model, you will need to implement setData() to store the new information in the model object, and then you will need to emit dataChanged.

Building a Qt app?

I’d love to help! Give us a call or send us an email to discuss! 

Learn more about our Application Development expertise and contact us for your next project.

The post Using a QAbstractListModel in QML appeared first on DMC, Inc..

Although most Ignition functions work the same across Perspective or Vision, there are some adjustments to work better in a web-friendly environment. This multi-part blog will serve as a guide to setting up dynamic Perspective screens that take full advantage of its powerful new features.

In this part, we will cover how to configure button presses to modify properties and tags in Perspective. Using Python scripting can be intimidating at first, but it is a key skill in creating HMI and SCADA systems that can send commands to other systems. This blog will teach you how to use button events to write to component properties and tags.

Example 1: Toggling a Boolean Property

First, we will create a button and use it to toggle the enable/disable custom property that we created in the last Perspective blog. Drag a button from the component toolbox onto your view. Then change its text property to "Toggle Enable"

Right click your button and select "Configure Events" to open the event popup. You can also use the handy shortcut Ctrl+J.

The left-hand list shows all possible button events. Select "onActionPerformed", which is triggered when the button is pressed. Then click the plus icon and add a script action for this event. There are many different actions, but scripts are used for manipulating properties and tags.

The runAction Python script is called when the button is pressed. We are going to write a short script to read the "enable custom property" value, toggle that value, then write back to the property. First, press the property reference button, find the property in the tree, and click Ok to add the reference to your script.

Next, write the following script. The exact reference may change depending on your object names. First, assign the property value to "input". Then, assign "output = not input" to toggle the bit. Finally, assign "output" back to the original property.

To test out your script, enter preview mode by clicking the Play Button icon. This simulates your view as it will run on the Ignition webpage. To exit preview mode and go back to editing, press the button again.

In preview mode, you can press the button to enable and disable the custom property.

Example 2: Incrementing a Numeric Tag

Next, we will learn how to use a button to update a tag value. The core workflow of using a script to manipulate a property is the same, but that property will now be bidirectionally bound to a tag.

Create a new button, rename it "counter", then add a custom property "count" to it. Next, add a tag binding to the custom property and navigate to an integer or float tag on your gateway. Make sure to select the bidirectional checkbox. This makes sure that the property can write back to the tag. For help with these steps, see "Tag Binding" in the previous Prespective blog installment.

Next, we will update the button text to display the current counter value. Add an expression binding to the button's text property. Insert the expression shown in the screenshot below. You can use the property reference button on the right side to find your custom property. 

We will now add a script to manipulate the custom property that is bound to the tag. Like the previous example, create a script action on the button's onActionPerformed event. Next, insert the property reference to your custom property. This script is even simpler than the last. Simply add " += 1 " to the end of your property reference to increment the value by one.

Enter preview mode and click your new button to watch the counter increment on each press. This basic technique of creating a bidirectional tag binding and an event action script can be used for simple and complex behavior. 

Learn more about DMC's Ignition expertise.  Contact us to get started on your next HMI, SCADA, or MES project.

See other blogs in this series: Creating Dynamic Ignition Perspective Projects
Part 1: Bindings and Transforms
Part 2: Button Event Actions
Part 3: Embedded Views and Flex Containers
Part 4: View Parameters, Indirect Bindings, and Flex Repeaters
Part 5: Flex Repeaters with Variable Number of Instances (coming soon)
Part 6: Changing Colors and Other Properties (coming soon)

The post Creating Dynamic Ignition Perspective Projects, Part 2: Button Event Actions appeared first on DMC, Inc..

Using Octoprint to Monitor 3D Printing

I recently set up a tool called Octoprint on a Raspberry Pi, and am using it to control and monitor the 3D printer here at DMC.

The tool generates timelapses after each print, and it started to take up a lot of space on the Pi’s storage.

I used the following script to take newly rendered timelapses and upload them to SharePoint. This allows users to easily access their print timelapses and frees space on the pi.

Setup

You will need to install the requests package and NTLM authentication package on your environment. In a Linux environment, type the following commands:

pip install requests

pip install requests_ntlm

pip install requests

pip install requests_ntlm

Python Script

#Import required packages
import sys
import requests
from requests_ntlm import HttpNtlmAuth

#Read filename (relative path) from command line
fileName = sys.argv[1]

#Enter your SharePoint site and target library
sharePointUrl = 'https://your.sharepointsite.com/'
folderUrl = '/Your/SharePoint/DocumentLibrary'

#Sets up the url for requesting a file upload
requestUrl = sharePointUrl + '/_api/web/getfolderbyserverrelativeurl(\'' + folderUrl + '\')/Files/add(url=\'' + fileName + '\',overwrite=true)'

#Read in the file that we are going to upload
file = open(fileName, 'rb')

#Setup the required headers for communicating with SharePoint 
headers = {'Content-Type': 'application/json; odata=verbose', 'accept': 'application/json;odata=verbose'}

#Execute a request to get the FormDigestValue. This will be used to authenticate our upload request
r = requests.post(sharePointUrl + "/_api/contextinfo",auth=HttpNtlmAuth('Domain\\username','password'), headers=headers)
formDigestValue = r.json()['d']['GetContextWebInformation']['FormDigestValue']

#Update headers to use the newly acquired FormDigestValue
headers = {'Content-Type': 'application/json; odata=verbose', 'accept': 'application/json;odata=verbose', 'x-requestdigest' : formDigestValue}

#Execute the request. If you run into issues, inspect the contents of uploadResult
uploadResult = requests.post(requestUrl,auth=HttpNtlmAuth('Domain\\username','password'), headers=headers, data=file.read())

#Import required packages
import sys
import requests
from requests_ntlm import HttpNtlmAuth

#Read filename (relative path) from command line
fileName = sys.argv[1]

#Enter your SharePoint site and target library
sharePointUrl = 'https://your.sharepointsite.com&/#39;
folderUrl = '/Your/SharePoint/DocumentLibrary'

#Sets up the url for requesting a file upload
requestUrl = sharePointUrl + '/_api/web/getfolderbyserverrelativeurl(\'' + folderUrl + '\')/Files/add(url=\'' + fileName + '\',overwrite=true)'

#Read in the file that we are going to upload
file = open(fileName, 'rb')

#Setup the required headers for communicating with SharePoint 
headers = {'Content-Type': 'application/json; odata=verbose', 'accept': 'application/json;odata=verbose'}

#Execute a request to get the FormDigestValue. This will be used to authenticate our upload request
r = requests.post(sharePointUrl + "/_api/contextinfo",auth=HttpNtlmAuth('Domain\\username','password'), headers=headers)
formDigestValue = r.json()['d']['GetContextWebInformation']['FormDigestValue']

#Update headers to use the newly acquired FormDigestValue
headers = {'Content-Type': 'application/json; odata=verbose', 'accept': 'application/json;odata=verbose', 'x-requestdigest' : formDigestValue}

#Execute the request. If you run into issues, inspect the contents of uploadResult
uploadResult = requests.post(requestUrl,auth=HttpNtlmAuth('Domain\\username','password'), headers=headers, data=file.read())

Browse to your SharePoint site, and you should now see the newly uploaded file.

Learn more about DMC’s SharePoint Consulting Services and Digital Workplace Solutions team. Contact us for your next custom SharePoint project.

The post How to Upload a File to SharePoint On-Premises Using Python appeared first on DMC, Inc..