As industrial vision engineers, you’ve probably all encountered this mysterious issue: The algorithm runs quickly and accurately when tested locally, but as soon as it’s deployed on the actual equipment, it starts experiencing frequent freezes, missed detections, and inconsistent cycle times—sometimes fast, sometimes slow. After spending half a month optimizing operators and even upgrading to a higher-end camera, the on-site stability still remains extremely problematic.

In fact, most of the time,The root of the problem doesn't lie in the algorithm itself; rather, the software thread architecture was designed incorrectly..

The most widely recognized, stable, and versatile solution in industrial vision equipment is...Multi-threaded Pipeline Architecture A well-designed thread architecture can even elevate the device’s rhythm and stability to a whole new level—without needing to upgrade hardware or modify algorithms. Today, we’ll thoroughly explain this architecture from top to bottom.

I. First, understand: Why your single-threaded architecture is bound to fail.

Many beginners who write visual software tend to end up with a “serial, one-stop” approach: camera captures images → algorithm runs → motion commands are sent → interface is refreshed—all the logic crammed into a single thread. As soon as any one of these steps gets stuck, the entire pipeline simply collapses. If the algorithm takes even a brief pause, the camera starts dropping frames; if there’s any delay in motion control, the interface immediately freezes.

The core requirement of industrial vision systems is:Real-time, stable, high throughputThis naturally conflicts with a single-threaded architecture. Truly mature device software must be modular and parallel: acquisition, processing, control, and display each run in their own separate threads, completely non-blocking and relying on queues to pass data between them.

II. What does a standard industrial vision software architecture look like?

A complete industrial vision system features a data flow that follows a typical “pipeline” structure, with data moving sequentially from top to bottom while each stage operates in parallel.

Camera Acquisition Thread   ↓   Image Cache Queue   ↓   Image Processing Thread   ↓   Result Output Queue   ↓   Motion Control Thread   ↓   Device Executes Action

In addition, there are three independent sub-threads running in parallel throughout the entire process: the UI display thread, the logging thread, and the external communication thread. All modules operate independently, ensuring that fluctuations in the processing time of any single component won't bring down the entire system.

III. The Five Core Threads: Each Has Its Own Role—That’s the Key to Stability

A qualified visual equipment software package should at least be divided into 5 core threads, with each thread handling only one specific task. The clearer the boundaries between these threads, the more stable the system will be.

1. Camera acquisition thread: Only handles acquisition; never touches the algorithm.

This is the source of the entire production line—and also the most likely to fail. It has only three responsibilities: waiting for a trigger signal, controlling camera exposure and image acquisition, and writing the images into the cache queue.Core principle: The collection thread must be extremely lightweight.Under no circumstances should you run any image-processing algorithms—not even simple grayscale conversions—in the acquisition thread. Once the acquisition thread gets blocked, the immediate consequence will be frame loss and missed captures; no matter how powerful your subsequent algorithms are, they’ll be rendered useless.

2. Image processing thread: Focus on calculations—don't worry about anything else.

This is the algorithm’s main processing hub, responsible for fetching images from the image queue, running the detection algorithm, extracting features, calculating localization coordinates, and outputting the final results. In multi-camera systems, each camera typically corresponds to a separate processing thread, preventing multiple images from competing for resources. This thread can tolerate some fluctuations in processing time; however, thanks to the image queue acting as a buffer, an algorithm that’s a few milliseconds slower won’t affect the camera’s image acquisition at all—and certainly won’t overwhelm the motion control system.

3. Motion control thread: Just execute—don't participate in calculations.

After the vision system calculates the coordinates, how do we send them to the servo and PLC? All of this is handled by the motion control thread. The motion control thread retrieves the detection data from the result queue, converts it into motion control commands, and then sends these commands to actuators such as servo axes and cylinders. The biggest advantage of separating vision and motion into two separate threads is that...Visual computing does not impede motion execution, and returning the motion to zero delay camera image acquisition.The two are completely decoupled, which will significantly enhance beat stability.

4. UI display thread: The interface must never run algorithms.

This is the most common mistake made by beginners: writing image-processing code directly in the click event of interface buttons. The UI thread is responsible for only one thing: refreshing the interface, configuring parameters, displaying real-time images, and showing the current status. Once the UI thread starts performing time-consuming operations, the interface immediately becomes unresponsive—no matter what the operator clicks, nothing happens, resulting in a terribly poor user experience. Remember this iron rule:The UI thread handles only display tasks; all time-consuming logic is offloaded to background threads..

5. Communication thread: specifically responsible for external interactions.

PLC communication, IO signal interaction, TCP data reporting, and Modbus/EtherCAT communication are all handled in separate communication threads. This prevents the main vision processing flow from getting stuck due to external communication delays or connection disruptions and subsequent reconnections.

IV. Stop using shared variables to pass data between threads.

After threads are split, how do you pass data between them? Many people take the easy route and rely on global variables for sharing, which often leads to frequent data corruption, thread conflicts, and sporadic crashes. The standard solution in the industrial vision industry is the thread-safe queue.

• The acquisition thread writes the image into the “image queue.”

• The processing thread retrieves images from the queue, and after completing the computation, writes the results into the “result queue.”

• The control thread retrieves data from the result queue and issues motion commands.

Commonly used, for example, in C#:ConcurrentQueue, in C++BlockingQueueIt natively supports multi-threaded read and write operations, eliminating the need for you to manually add locks—making it both safe and efficient. The queue also plays a crucial role:Peak shaving and valley fillingIf the algorithm on a certain frame is slightly slower, the queue can buffer the images without causing the acquisition end to get blocked. Even if the motion end experiences occasional delays, it won't affect the algorithm's continuous operation.

V. The True Power of Pipeline Architecture: Maximizing Throughput

Why is it called a pipeline architecture? Because it shares the same logic as a factory assembly line:

• Frame 1: Collecting...

• Frame 2: Under algorithmic processing

• Frame 3: Motion control in progress

• Frame 4: Outputting results

At the same time, different frames are processed in parallel at different stages, rather than waiting for one frame to complete entirely before moving on to the next. Let’s do a quick calculation: consider a typical single-station inspection device:

Table

If executed sequentially, the total latency per frame is about 20 ms; but when run using a pipelined architecture,The system beat can easily be squeezed down to just over 10ms.Throughput doubles directly. That’s also why, with the same hardware, equipment from large manufacturers can always achieve a significantly faster cycle time than that from smaller manufacturers—the difference often lies in the architecture itself.

VI. The 3 most common architectural mistakes in the industry—step into just one and you’ll fall into a pit.

Error 1: Single-threaded, serial execution throughout the entire process

Acquisition, algorithms, control, and display are all handled within a single thread—resulting in complete system lockups. Even slight fluctuations in algorithm execution time can cause frame drops, leaving the device’s timing completely unreliable.

Error 2: The UI thread is running the algorithm.

To save time and convenience, some developers directly process images in the UI thread, resulting in a frozen interface, unresponsive operations, and even the awkward situation where “the algorithm hasn’t finished running, yet the interface is completely unresponsive.”

Error 3: Directly sharing variables between threads

Without using queues, relying on global variables to pass images and results can, at best, lead to data corruption, missed detections, or false alarms; at worst, it can cause sporadic crashes, leaving on-site troubleshooting efforts stuck for days without pinpointing the root cause.

VII. Finally: The Core Design Principles of Industrial Vision Software

Many senior visual engineers agree on one statement:A good vision system, at its core, is essentially a real-time pipeline.Each module operates independently, each with its own specific function, decoupled via queues and made more efficient through parallelism. The algorithm determines the upper limit of the device’s precision, while the architecture sets the lower limit of its stability.

If you're developing WinForms or WPF applications using C#, this architecture is very easy to implement: The main thread handles the UI, and you can separately create four background threads—Camera, Vision, Motion, and IO—to work in tandem.Task,Thread,ConcurrentQueueandasync/awaityou can build an industrial-grade, stable visual software framework.