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

Siemens provides two Instruction blocks for setting up Client/Server Modbus TCP connections – you can find them under Communication on the Instructions Window – MB_SERVER and MB_CLIENT.

As an example, let’s set up a Modbus TCP server on our PLC. I’m starting a project from scratch, so I’m going to add an instance of MB_SERVER to my OB1. When you add the instruction, you’ll notice it will need its own instance DB, so go ahead and create one.

You’ll see there are only a few inputs to this block:

• DISCONNECT: the default for this input is 'FALSE.' Setting the input to 'TRUE' will cause the server to sever any active connection and refuse any connection attempts.
• CONNECT_ID: this defines a connection number on the PLC. This must be unique for each instance of MB_SERVER or MB_CLIENT.
• IP_PORT: by default, the IP_PORT will be set to 502, which is the standard port used for Modbus TCP communications. If you would like to use an alternative port, this is where you set it. Just be careful not to use any ports already used by the PLC: 20, 21, 25, 80, 102, 123, 5001, 34962, 34963, and 34964.
• MB_HOLD_REGISTER: This defined the location (start and size) for the available Holding Registers (40001 to max defined register). This pointer can be any global data block or a memory area (M). These holding registers are used for Modbus functions 3 (read Word), 6 (write Word), and 16 (write multiple Words). You can set this pointer using the ANY format (“P#bit address” “data type” “length”):

That’s really all you need. There are some status bits you can use to debug connection issues and a few static tags that can be accessed, but in most case you shouldn’t need them.

Now, ignoring the hold registers for a moment, let’s look at what this MB_SERVER instruction gives us out of the box. There’s a handy table in the help file explaining the codes and data sources automatically made available. To sum it up, function codes 1, 2, 4, 5, and 15 will immediately support direct read and write access to the process image of the CPU.

For example, function code 01 (Read Bits) allows read access to the output process image, with registers 1-8192 corresponding to Q0.0-Q1023.7. Likewise, function code 5 (Write Bits) allows write access to the same registers/bits. Function code 02 will allow read access to the input process image, mapping registers 10001-18192 to I0.0 to I1023.7. Check the help file for the other options.

Getting back to the hold registers, these are accessed with function codes 3, 6, and 16. Unless you’ve modified the start position, the hold registers will begin at 40001 and continue for the length defined in  MB_HOLD_REG. To wrap things up, I’m going to create a global DB for my hold registers and include the following:

Looking at the DB above, you can see I’ve created an array of Bools that make up the first Word (this will be Register 40001). The next Word will be the data for Register 40002, in this case, an Int. Finally, I’ve added a Real, which is a DW and will use Registers 40003 and 40004.

We should now have a single rung of logic to control our Modbus TCP server.

Now, I can update information in my global DB from my code and read it from a Modbus TCP master, or the master can write data to my PLC.

That’s it. All you need to run a Modbus TCP server on your S7-1200. Have fun.

Learn more about DMC's PLC Programming services and contact us to get started on your next PLC Programming project.

The post Using an S7-1200 PLC as a Modbus TCP Slave appeared first on DMC, Inc..