Workers for LabVIEW Community

What's new?

2026 Webinars - Introduction to Workers 5.0

Our Introduction to Workers 5.0 webinars are returning for 2026! Join us to discover how this framework can transform your LabVIEW development. Our monthly Getting Started with Workers for LabVIEW webinars are designed for LabVIEW developers who are curious about the Workers framework. Each session introduces newcomers to what Workers is, why it was developed, and how it addresses common LabVIEW development challenges. What You'll Discover in 60 Minutes The “Why” Behind the Design – The real-world problems Workers was built to solve and how its architecture makes LabVIEW development faster, cleaner, and more scalable. Simple, Practical OOP – How Workers uses object-oriented programming only where it adds value, so you get the benefits without the complexity. Scalability, APIs & HALs – How to structure applications for growth with modular Workers, decoupled Public APIs, and flexible hardware abstraction layers. Live Q&A – Ask your questions directly to the framework creator. Whether you’re a beginner user looking for a LabVIEW framework or an experienced developer exploring better architectural options, this webinar will give you a clear understanding of how Workers can level up your LabVIEW projects. 📅 Dates & time — Register here: http://webinar.workersforlabview.io/

🚧 Under Construction: The next version of the Workers SDK!

It’s official — development on the next version of Workers for LabVIEW is now underway! After almost two years away from the deep world of LabVIEW scripting, I’m diving back into the internals of the Workers SDK to add new features, improve existing ones, and continue building the next generation of the framework. Over the past two years, the Workers Community has continued to grow and thrive. I want to express my sincere thanks for all the questions, feedback, and discussions that have taken place here and during the monthly webinars. Your input has been instrumental in shaping where the framework is heading next. The core mission remains the same: Good architecture made simple. This next version will stay true to that philosophy — but with even more to offer: More flexibility for advanced applications Smarter, faster workflows for developers Improved scripting tools, faster with new features Cleaner, scalable multi-process design An even better fit with LabVIEW’s natural dataflow paradigm In short, the goal is to help you build better architectures with less effort, while keeping the clarity, structure, and performance that make the Workers framework what it is. Stay tuned for development updates as we move forward. For now, it’s time to open up those scripting VIs again… Wish *us* luck! 🍀 Peter Scarfe Creator of Workers for LabVIEW

New: PEIP (Project Explorer Integration Pack) for Workers 5.0

I'm excited to announce the release of the first third-party add-on for Workers for LabVIEW, PEIP (Project Explorer Integration Pack) by Stanislav Rumega makes working with Workers faster and more streamlined. What PEIP brings to your workflow 1️⃣ Faster loading of the Workers Tools menu — the menu opens instantly 2️⃣ Right-click options in the project tree — create new Workers directly from your project 3️⃣ Toolbar icon + Ctrl+M Quick Drop shortcut — quick access to the Workers Tools menu 4️⃣ Visible icons for Worker and Worker Base classes (like HALs), making it clear which classes in your project are Workers I’ve installed PEIP on every one of my development machines, and it’s hard to imagine working with Workers without it now. ➡️ Available for LabVIEW 2020 and later, download it here 👇 (And don’t forget to give it a thumbs-up in VIPM to show support for Stanislav’s work!) A huge thanks to Stanislav for his contribution to the Workers Community — this add-on makes the framework faster, easier, and more enjoyable to use for everyone. Peter Scarfe Creator of Workers for LabVIEW

Announcing Our First Certified Training Partner: Kreiseder IT Services

As the Workers for LabVIEW framework continues to gain momentum across the LabVIEW community, we’re excited to announce a major milestone in its journey: 🥇 Kreiseder IT Services is now the first official Certified Training Partner. Led by Andreas Kreiseder, this Austria-based organization has established itself as one of Europe’s most trusted providers of professional LabVIEW education. Over the past decade, Andreas has personally delivered 100s of courses, training 1000s of developers across a wide range of industries and applications. With a strong foundation in software architecture, test systems, and best practices, his approach to training blends deep technical know-how with a clear, engaging teaching style — exactly what the Workers ecosystem needs as adoption grows. 🎓 What is a Certified Training Partner? The Certified Training Partner (CTP) program is designed to ensure that developers and teams around the world have access to official Workers for LabVIEW training, delivered by professionals who understand the framework at a deep level — and know how to teach it effectively. CTPs are authorized to deliver: The official Workers 5.0 Training Course Using the full course manual, guided course exercise set In both in-person and remote formats, tailored to team needs This initiative complements our existing Certified Support Partner program — which focuses on consulting, implementation, and project support — by making high-quality education more broadly available for those just getting started or looking to train internal teams. 🤝 Why Kreiseder IT Services? We couldn’t have asked for a more capable or aligned inaugural partner. Andreas is a Certified LabVIEW Architect and Certified Professional Instructor (CPI) He has extensive experience teaching LabVIEW, TestStand, DIAdem, and Python. His courses are known for being practical, engaging, and directly applicable to real-world projects Kreiseder IT Services brings a high standard of quality to every session — whether on-site at a customer location or through remote interactive delivery. With their involvement, the Workers for LabVIEW framework becomes easier than ever to adopt, scale, and teach. 💬 A Word of Thanks “Andi — I’m incredibly grateful for your support, and excited to team up with someone who cares deeply about teaching, precision, and empowering developers to do their best work.” — Peter Scarfe, Creator of Workers for LabVIEW 📍 What’s Next? To learn more about Workers for LabVIEW classroom training with Kreiseder IT Services, click here: https://kreiseder.org/veranstaltung/workers-for-labview 💛 Let’s Build Together This is a big step forward in growing the Workers for LabVIEW ecosystem — not just as a technical framework, but as a supported, teachable, scalable path for LabVIEW developers around the world. If your organization is interested in becoming a Certified Training Partner, feel free to reach out. We’re just getting started.

Workers for LabVIEW - Certified Support Partner (CSP) Program

We’re excited to officially launch the Workers for LabVIEW Certified Support Partner (CSP) Program — a recognition program for companies who have demonstrated expert-level proficiency using the Workers framework and are equipped to help others successfully adopt it. This initiative was created to support the growing number of developers and teams using the framework across a wide range of industries and project scales. 🏅 What is a Certified Support Partner? A Certified Support Partner is a company that: Has extensive real-world experience using Workers for LabVIEW Understands and applies the core design principles of the framework Is capable of providing mentoring, coaching, and implementation support Is engaged with the community and contributes to its growth Certified partners have shown that they can guide others through the challenges of modern LabVIEW application design—ensuring projects are modular, scalable, and maintainable. 🧰 What Can a Workers for LabVIEW CSP Offer? Certified Support Partners are qualified to help with: ✅ Implementation support – Integrating the framework into new or existing LabVIEW projects ✅ Architecture guidance – Advising on best practices, including API abstraction, HALs, and call-chain structures ✅ Debugging expertise – Using tools like the Debug Server to diagnose and improve performance ✅ Developer mentoring – Training teams on how to use the framework effectively ✅ Community leadership – Engaging in discussions, contributing to shared tools, and supporting other developers 🎉 Meet the First Certified Support Partners We're pleased to announce the first companies to receive CSP recognition: KUBES AG (Switzerland) HERZOG ENGINEERING (Switzerland) Both companies have been using Workers for LabVIEW for over five years and have applied it across numerous projects. Their contributions to the community and demonstrated technical excellence make them ideal partners for teams looking to scale up with the framework. 🧭 How to Become a Certified Support Partner We're currently finalizing the application process, and details will be published soon. If your company is already using the framework and is interested in becoming a Certified Support Partner, we’d love to hear from you. 📬 In the meantime, feel free to reach out directly or keep an eye on the community announcements for the full certification criteria and how to apply. Thank you to everyone who continues to build, share, and support the Workers for LabVIEW ecosystem. This is just the beginning of a broader effort to support and recognize those who are helping the community grow stronger, together. 💛 Let’s build better LabVIEW applications—together.

Worker User Library now on GitHub

Welcome to the Worker User Library on GitHub—a growing collection of reusable Workers designed to support and accelerate development with the Workers for LabVIEW framework. Each Worker in this repository provides useful functionality that can be dynamically loaded into your Workers applications and communicated with via their standardized Public APIs. What This Library Contains This repository includes a curated set of Workers contributed by the community or created in response to developer needs. Each Worker is: Self-contained and easy to add into a project. Compatible with Workers 5.0. Designed to be modular and reusable. Documented with a description of its purpose and usage. How to Use These Workers You can pull these Workers directly from Github onto your PC, allowing you to add copies of these Workers in your projects directly from within LabVIEW. More information on how to set this up can be found in the repository's Readme.md file located in the root directory of the repository. See link to the GitHub repository below. 👇

Latest Articles

Worker PPLs - An example using the DMM HAL Demo Project

Packed Project Libraries (PPLs) are commonly used in LabVIEW to create modular plugin architectures. However, once inheritance and dynamic loading are introduced, dependency management can quickly become difficult. This guide describes how to create a Worker PPL plugin. For this example, we will take a working source-code example and turn it into a deployable PPL plugin architecture. To make it easy to follow, this guide uses the DMM HAL Demo Project that ships with the Workers SDK, allowing you to follow along with the steps. The result is a version of the example project in which both the DMM HAL and the DMM Workers are PPLs, suitable for deploying in production in place of the source code. What you will need The DMM HAL Demo Project — one of the example projects that ships by default with the Workers SDK. This is the Source Project you will work from throughout this guide. LabVIEW Solution Builder — a free tool that builds packed libraries in the correct dependency order. Download the master branch from github.com/jovianarts/LVSolutionBuilder, then unzip it somewhere convenient.. LabVIEW 2019 or later — required by the LabVIEW Solution Builder. Important: Source and PPL modules are not interchangeable A library compiled into a PPL belongs to the PPL runtime tree. The same library in source form belongs to the development source tree. The two are not interchangeable: a PPL plugin cannot be loaded with source-based parents, and a source plugin cannot be loaded with PPL parents. Figure 1 : Source and PPL modules are not interchangeable. PPL Workers must inherit from the exact same parent libraries. Because the source code and the PPLs belong to separate trees, the workflow uses two separate projects: a Source Project, where development takes place, and a PPL Project, where the built PPLs are assembled into an application. Steps 1–3 produce the PPL runtime tree from the development source tree. Steps 4–5 work within the PPL runtime tree. Let's begin... Before starting, create a copy of the DMM HAL Demo Project example project that ships with the Workers SDK. (This can be found under the Workers tools menu > Example Projects). Confirm that the example project runs correctly from source. The code should be working before it is built. Step 1 — Organize the Source Project into libraries The Solution Builder works at the library level, so each component to be turned into a PPL must reside in its own library. Create a library named DMM Workers.lvlib and add the Worker plugins (Fluke, Keithley and Keysight DMM) to it. Create a library named DMM HAL.lvlib and add DMM HAL.lvclass to it, together with its launchers — Asynchronous Launcher - DMM HAL.vi and Launcher - DMM HAL.vi. The Source Project should now contain two libraries, each holding one layer of the architecture, as shown below in Figure 2. Figure 2 : The Source Project. DMM Workers and DMM HAL are both moved into separate libraries, and both libraries have PPL build specs. Step 2 — Create the packed library build specs Create a Packed Project Library build specification for each library, as shown in Figure 2: PPL DMM HAL — built from DMM HAL.lvlib. PPL DMM Workers — built from DMM Workers.lvlib. In each build spec, open the Source Files page and confirm that the library created in Step 1 is the source — not loose classes or VIs. Open the Additional Exclusions page and tick Exclude dependent packed libraries, as shown below. This setting prevents the builder from embedding a private copy of the HAL inside the Workers PPL. Both PPLs then resolve to one shared HAL at runtime — a single shared class identity rather than two separate ones. Figure 3 : Make sure "Exclude dependent packed libraries" is checked Step 3 — Build the PPLs with LabVIEW Solution Builder The PPLs must be built in dependency order: the HAL first, then the Workers that depend on it. ⭐ Good news! You don't need to manually do this! The Solution Builder determines this order and carries out the builds. Open SolutionBuilder.vi from the copy downloaded earlier from the LabVIEW Solution Builder GitHub repository, and point the Path field on the front panel to your Source Project. Run SolutionBuilder.vi. The Solution Builder analyses the library dependencies, builds PPL DMM HAL first, relinks it in memory, then builds PPL DMM Workers with the PPL DMM HAL as its linked dependency. After the tool completes, the Status for both build specifications should say Built. Figure 4 : Solution Builder.vi The two output PPLs — PPL DMM HAL.lvlibp and PPL DMM Workers.lvlibp — are written to the build destinations defined in their build specs. Note these locations; the files are needed in the next step. Step 4 — Create the PPL Project Create a new, separate project as shown in Figure 5 below, and add the two PPLs produced by the Solution Builder — PPL DMM HAL.lvlibp and PPL DMM Workers.lvlibp. This is the PPL Project. Everything in it works with the packed libraries, which are not the same VIs the Source Project uses. This project corresponds to the PPL runtime tree in Figure 1 above. Figure 5 : PPL Project. This project does not contain the source code, but the PPL DMM HAL and the PPL DMM Workers. Step 5 — Use the PPLs The PPL Project needs its own top-level VI to run the example. Add a VI named PPL Universal DMM User Interface.vi (as in Figure 5) to the project. It can begin as a copy of the Universal DMM User Interface.vi from the Source Project, but every Worker class and Public API VI used on its block diagram must be replaced with the equivalent Worker class or VI from the PPL libraries, as shown in Figure 6 below. The Source Project and the PPL Project use different files, and the deployed VI must reference the PPL versions throughout. Figure 6 : a copy of the Universal DMM User Interface.vi (taken from the source project) but all Public API VIs and Worker class constants are replaced with the PPL versions. With that done, you have successfully built Worker PPL plugins. Because PPL DMM Workers.lvlibp was built with PPL DMM HAL.lvlibp as its linked dependency, its Worker classes inherit from the PPL HAL. A Worker (e.g. Fluke, Keithley, etc.) can therefore be wired directly into the PPL HAL Public API VIs. Building every layer as a PPL, in dependency order, with Exclude dependent packed libraries enabled, places the whole system on a single PPL tree: one DMM HAL, one shared class identity, and any DMM Worker that inherits from it can be loaded without modification.. Step 6 — Update the Workers and rebuild You can now continue development in the Source Project. New DMM Workers can be created, and existing ones modified, in the usual way. To deploy those changes, run the Solution Builder again as in Step 3. As long as the DMM HAL source code is unchanged, the Solution Builder detects this and does not rebuild PPL DMM HAL — it rebuilds only PPL DMM Workers. The updated PPL is written to the same destination, and the PPL Project picks up the new Workers without any further changes. This is the ongoing workflow: develop in the Source Project, build with the Solution Builder, and the PPL Project always references the built PPLs. Best of luck! 🙂

Worker Reuse Patterns: The Four Types of Structure and Behavior Reuse in the Workers Framework

Modern modular LabVIEW applications grow quickly, and without structured development they can become difficult to maintain, scale, and test. The Workers framework for LabVIEW was designed around a simple but important principle: Reuse is not primarily about saving time today. It is about controlling complexity tomorrow. The framework provides several structured ways to reuse functionality, each suited to a different design need. This allows you to build systems using: reusable boilerplate shared behavior reusable functional modules shared APIs with interchangeable implementations Each of these represents a different architectural reuse pattern. This article explains the four architectural reuse patterns available in the Workers framework and helps you understand when and where to use each. Let’s get started. 1️⃣ Template Workers Multiple different Workers that share the same starting boilerplate Every time you create a new Worker using the Create/Add Worker tool, the framework generates it from a template. You can also define your own templates to establish consistent starting structures for future Workers. Use a Worker template when you want to create new Workers that start with the same structure but will eventually diverge in behavior. A template provides: the same Main VI structure (MHL and/or EHL(s), default cases) the same virtual folder layout the same naming conventions and icons Each generated Worker becomes its own independent asynchronous process at run-time. Changes made later to the template do not propagate to existing Workers. Use a Worker template when: You need several Workers that begin with the same boilerplate The Workers will diverge in logic or purpose You want consistent structure and style across your application Example The framework provides two default Worker templates: Worker with EHL (EHL + MHL) Worker without EHL (MHL only) Every Worker you create begins from one of these templates and then evolves as you add custom functionality to it. 2️⃣ Multiple Instances Same Worker, multiple roles Every Worker is a class, which means you can create multiple instances of it at run-time. By either statically-linking the same Worker multiple times or dynamically loading it, you create multiple clones of the same Worker's Main VI, with each running independently. Using multiple Worker instances gives you: identical logic and behavior the same Public API differences only in Alias, configuration, or role This is the most maintainable pattern when all instances behave the same. At run-time, each Worker instance is assigned a unique alias and address, making it easy to identify and communicate with each instance in your application and from the Workers Debug Server. Because all instances use the same Worker class, you maintain one codebase. Use multiple Worker instances when: All instances should behave identically You want low maintenance overhead You need only Alias or configuration differences Example You have one Worker class: NI USB-6009 Device You want to control three separate NI USB-6009 devices, so you add multiple static instances: NI USB-6009 Device 1 NI USB-6009 Device 2 NI USB-6009 Device 3 All instances share the same implementation (i.e. logic) but represent different physical devices or logical channels. 3️⃣ Worker User Library Pre-built, fully functional Workers reused across projects The Worker User Library tool allows you to reuse entire, fully implemented Workers, not just structure or behavior, by adding a copy of a functional Worker (or library of Workers) directly into your LabVIEW projects. Workers stored in your Worker User Library: contain complete, working functionality can be integrated into new applications using their Public APIs help standardize functionality across teams and projects eliminate the need to reimplement common features become part of your organization’s internal “Worker toolbox” These Workers are often team-developed, well-tested modules that can be dropped into new projects with confidence. Use the Worker User Library when: You want to reuse functionality, not just structure A Worker already exists that solves your problem You want consistent, proven behavior across projects Your team wants a shared library of reusable Workers Example Your organization maintains reusable Workers such as: Modbus TCP Client OPC UA Tag Monitor PID Controller MySQL Data Logger Digital Output Device Once part of your Worker User Library, these modules can be added to any new application without recreating their functionality. 4️⃣ API Abstractions (e.g. HALs) One Public API shared by multiple Workers API abstraction is the most flexible form of Worker reuse. It is ideal when you need true polymorphic behavior: Multiple Workers share the same Public API but implement different functionality internally. This pattern is provided directly by the framework’s Public API Builder tool. To implement this pattern, you create: a Worker base class defining a shared Public API multiple derived Workers implementing device-specific logic Callers (and systems such as NI TestStand) interact only with the Public API defined in the base class. This is the abstraction layer. Specific implementations, i.e. the derived Workers, can then be loaded and swapped dynamically at run-time. Use this pattern when: Devices or logic vary behind a common Public API You need run-time interchangeability You want clean API polymorphism You want maximum design flexibility Example (taken from the Workers Training Course) Base Worker class: DMM HAL (shared Public API) Derived Workers: Fluke DMM (device logic) Keysight DMM (device logic) Keithley DMM (device logic) All three Workers share the same Public API that exists in the DMM HAL base class but contain their own device-specific logic. The implemented behavior is abstracted behind the Public API in the base class. 🎯 Conclusion The Workers framework for LabVIEW provides you with four flexible Worker reuse patterns, each suited to a different design need: Template Workers establish consistent starting structure. Multiple Instances reuse one implementation across multiple roles at run-time. The Worker User Library enables reuse of complete functional modules across projects. API Abstractions provides run-time flexibility through shared Public APIs and interchangeable implementations. As your applications grow, you may find yourself using different reuse patterns for different parts of the system. The key is that you should never need to duplicate code when reuse is possible. The Workers framework gives you the tools to build systems that are modular, maintainable, and scalable, whether you are developing a simple application or a large, multi-device, multi-team system. Thanks for reading — and remember: architect first. — Peter Scarfe, Creator of Workers for LabVIEW 📬 If you’d like to receive future articles like this directly in your inbox, consider joining the Workers Community website. By signing up, you’ll stay up to date with new articles, discussions, framework updates, and developments within the Workers ecosystem.

Using Workers 5.0 on NI Real-Time Targets - What you need to know

At the recent GLA Summit 2025, I presented how Workers for LabVIEW (version 5.0) has evolved into an effective framework for structured, modular development on NI Real-Time (RT) targets like the CompactRIO. This article summarizes the main insights and key takeaways from my presentation. 🖥️ Modern Hardware Makes It Possible The capabilities of CompactRIO systems have drastically improved in recent years, making structured frameworks feasible and practical on RT targets. Consider these performance improvements: CPU Power: Modern cRIO CPUs are 20 to 50 times faster (DMIPS) than early models. Multicore CPUs: Current models provide dual or quad-core processors, enabling genuine parallelism for multiple real-time processes. RAM and Storage: Up to 32 times more RAM and significantly greater onboard storage capacities allow for modular and dynamically loaded applications. FPGA and Ethernet Capabilities: FPGA logic density has increased by approximately 10 times, and Ethernet throughput is substantially higher, enhancing real-time data streaming. This evolution in hardware means developers are no longer restricted to creating small, tightly coupled, monolithic applications—modular architectures are now practical and beneficial. Feature Early cRIOs (2004–2008) Modern cRIOs (2020–2025) Improvement Factor CPU Power ~500 DMIPS ~10,000–25,000 DMIPS ~20x to 50x CPU Cores Single-core only Dual-core and Quad-core available 2x to 4x RAM 64–128 MB 512 MB – 4 GB 8x to 32x Storage 128–256 MB Flash 4 – 64+ GB eMMC / SSD 16x to 256x FPGA Fabric ~200K logic gates (Virtex-II) 1–2M logic elements (Zynq-7020, Kintex-7) 5x to 10x Ethernet 10/100 Mbps Gigabit Ethernet, Time-Sensitive Networking 10x Application Size Small, monolithic apps only Large modular apps with HALs, dynamic loading 10x capability 🧩 Why Use Workers on NI Real-Time Targets? With hardware constraints largely resolved, Workers for LabVIEW becomes an ideal choice for structured RT development, providing: 1. Modern Hardware Compatibility Current cRIO hardware comfortably supports modular, message-driven architectures like Workers. There's no need for compromise on software design principles. 2. Unified Architecture for Windows and RT The Workers framework allows you to maintain consistency across platforms—develop once and deploy to both Windows and RT targets seamlessly. This dramatically reduces redundancy and simplifies development workflows. 3. Modular and Scalable Design Workers naturally encourages breaking applications into isolated, reusable modules. This scalability and modularity help manage complexity as systems grow. 4. Built-in RT-Compatible Tools Workers includes comprehensive tools designed explicitly for RT development—like automated Worker creation, API scripting, and the Workers Debug Server—greatly simplifying development and troubleshooting. 🔍 Solving Common RT Development Challenges Challenge 1: Debugging Reentrant VIs Debugging reentrant VIs on RT is challenging—typically, you can’t pause execution, probe wires, or set breakpoints. Workers resolves this by providing two types of Worker Main VIs: Main.vi (Reentrant): Standard, suitable for multiple instances. Main NR.vi (Non-Reentrant): Specifically for RT debugging, allowing standard LabVIEW debugging tools (breakpoints, probes, and stepping). Switching between these modes is quick and easy using the provided RT Worker Convert Tool, offering flexibility and control during development. Main.vi (re-entrant) and Main NR.vi (non-reentrant) Challenge 2: Limited Runtime Transparency RT targets traditionally offer minimal runtime feedback. The Workers Debug Server addresses this problem by providing live runtime monitoring and detailed message logs of applications deployed on remote RT targets, significantly enhancing visibility and debugging effectiveness. Workers Debug Server application connects to your Workers applications via TCP over your local network Challenge 3: Host-to-RT Data Streaming Complexity While Network Streams or Network Shared Variables are common, they have limitations and setup complexity. Workers simplifies host-to-RT communication through built-in TCP Server and TCP Client Workers, facilitating robust, scalable, and straightforward data streaming over TCP/IP. TCP Server and Client Workers can be used to communication between your Workers applications running anywhere on your local network ⚠️ Two Crucial Tips for RT Development Lastly, my presentation highlighted two critical recommendations to avoid common pitfalls: Disable "Separate Compiled Code from Source" Keep this flag off for all classes and VIs deployed to RT targets to avoid random deployment issues. Maintain Separate Projects for Host and RT Targets Using distinct LabVIEW projects for Windows and RT prevents class-locking and ensures compatibility with Workers development tools. 🎯 Final Thoughts Workers for LabVIEW 5.0 bridges the gap between modern software architectures and embedded RT systems. Thanks to the dramatic improvements in RT hardware, adopting a modular and structured development framework like Workers on CompactRIO targets is now not only possible—but practical and highly effective. Thanks for reading—happy wiring! — Peter Scarfe, Creator of Workers for LabVIEW

To Object or Not to Object, That Is the Question 🎭

In Shakespeare's Hamlet, "to be or not to be" reflects on a choice between two fundamentally different paths. In object-oriented programming, we often face a similar existential dilemma: To object or not to object? That is the question. Here we’re talking about the decision to objectify a concept in your code—or not. It’s a question (and a very important one) that comes up frequently, especially as you build more complex applications with more advanced architectures. In LabVIEW, you can technically turn anything into an object, even simple types like integers, timestamps, or booleans. But here’s the catch: Both under-objectifying and over-objectifying your code will increase the complexity of your application. If you underuse objects, your architecture can become: Rigid Repetitive Difficult to scale However, if you overuse objects, your codebase can become: Bloated Hard to read Frustrating to debug The good news is that there’s a sweet spot in the middle, where the right use of objects makes your code cleaner, more flexible, and easier to maintain. This article explores how to find that balance, and explains how the Workers framework uses OOP to make your applications more modular, scalable, and easier to develop. 🔍 What Does “Objectifying” Something Mean? In LabVIEW, objectifying something means encapsulating it inside a class, giving it: Private state (data) Associated behavior (methods) Optional inheritance structure This enables powerful design patterns, including: ✅ Encapsulation – Keeping data and logic together ✅ Polymorphism – Swapping out different implementations with a common interface ✅ Inheritance – Sharing and reusing behavior between related components But these benefits come with trade-offs. Objectifying too much—or too early—can introduce overhead, abstraction layers, and unnecessary indirection. So while you can objectify everything, it’s often better to objectify only what adds real structure or value. ✅ When Should You Use an Object? Use an object when the thing you’re modeling: Has behavior, not just data Represents a conceptual entity (e.g. a device, task, or module) May have multiple implementations (e.g. real vs. simulated) Requires reuse, extension, or protection of internal state Benefits from being accessed through a defined interface Examples of good candidates for objects: A hardware device with IO and configuration A service process like logging, messaging, or control A Worker that encapsulates a modular, stateful thread of execution ❌ When Not to Use an Object Avoid objectifying when: You're working with simple types (scalars, booleans, strings) There's no behavior or internal logic to encapsulate You only need fast, lightweight data passing The object would add no clarity, reuse, or abstraction benefit Over-objectifying these types often leads to: More code and file overhead Slower development Frustrating debugging sessions Unnecessary complexity in small applications 🧱 How Workers for LabVIEW Uses Objects In multi-process applications, the most architecturally obvious use of objects would be to turn each process into an object—and that’s exactly what the Workers framework does—by encapsulating each process in a class called a Worker. This design choice improves the structure, modularity, and scalability of multi-process applications, and significantly improves code reuse. ✔️ What is objectified: The only thing that is objectified in the Workers framework are the Workers themselves. This alone provides the framework with the following benefits: Workers (the processes themselves): Each Worker is a stand-alone modular process that provides a stateful thread of execution, whose methods act on its own private encapsulated data. Worker base classes: Each Worker inherits from the ancestor class Worker.lvclass providing common functionality to all Workers. Developers can further extend this common functionality by adding their own base classes into a Worker's inheritance hierarchy. Dynamic Abstraction: Workers can be dynamically loaded at runtime and interacted with through API abstractions. This allows applications to run entirely on abstract interfaces, enabling simulation swapping, hardware abstraction, and plug-in extensibility, all without touching the business logic. ❌ What is not objectified: Public API Methods: Worker methods are contained within the Message Handling Loop (MHL) cases of a Worker's Queued Message Handler (QMH). They are invoked by the use of a Worker's (or Worker base class's) Local API or Public API VIs. This keeps the logic simple, direct, and intuitive. Message queue data: Message data sent between Workers is wrapped in a message-specific typedef stored in variants—not message objects—preserving the simplicity of the QMH pattern that many LabVIEW developers are familiar with. Data structures and state: Runtime data used by a Worker is stored as simple typedefs, scalars, or clusters within the class’s private data. These are not objectified unless there's a clear reason to encapsulate additional behavior (and is left up to the user). 🛠️ Example: Creating a Hardware Abstraction Layer (HAL) using Workers Let’s say you're developing a system to control a power supply, and you want the flexibility to swap between a real device and a simulation. The fact that Workers are objects allows for the easy creation of HALs in the framework. Using Workers 5.0, this is how you would achieve this: Step 1: Create a Worker Base Class (scripted) Create PowerSupply_Base.lvclass that contains the following Public API Requests: Set Voltage Get Voltage Power On/Off These are method declarations only, no behavior yet. Step 2: Create Two Workers (scripted) RealPowerSupply.lvclass : Communicates with the physical device SimulatedPowerSupply.lvclass : Returns mock values and logs actions Both classes inherit from the base class and implement the Public API behavior in their own Message Handling Loop (MHL) cases. Step 3: Load a Worker via Factory Pattern at Runtime (scripted) At startup, load either the real or simulated Worker based on a config file. The rest of your application talks only to the base class Public API, and remains unaware of which implementation is active. Without objects, this HAL implementation would require: Duplicated logic Scattered conditional code A brittle architecture that’s hard to maintain or extend 💬 Final Thoughts Object-oriented programming is a powerful tool, but with great power comes great responsibility. Whether you're just starting out with LVOOP or developing an enterprise-scale application, remember: Good architecture isn’t about turning everything into an object, it’s about objectifying what makes sense. And by objectifying the right things—and avoiding it where it's not needed—you get: ✅ Cleaner code ✅ Faster development ✅ Easier debugging ✅ Happier developers The Workers for LabVIEW framework follows this philosophy, providing you with the power of LVOOP where it makes sense, while keeping the rest of your application lean, readable and efficient. 📚 What's next? If you want to learn more about how to put the OOP features of the framework into practice, the best place to start is with the Workers for LabVIEW Training Course. This free course walks you through the core concepts, API design, debugging tools, and real-world exercises to help you build scalable applications with confidence 📖 Download the training course here: 👉 https://community.workersforlabview.io/training-course

“Do I need to know LVOOP to use Workers for LabVIEW?”

One of the most common questions I am asked by LabVIEW developers discovering the Workers framework for the first time is: “Do I need to know LabVIEW Object-Oriented Programming (LVOOP) to start using Workers for LabVIEW?” The short answer? No, you don’t. While having a background in LVOOP or general OOP concepts can be helpful, Workers for LabVIEW was intentionally designed to be accessible to developers who have: Completed NI LabVIEW Core 3 Achieved CLD certification Built applications using the NI Queued Message Handler (QMH) design pattern A Framework Built for Where You Are — and Where You're Going When designing Workers, I was guided by a simple question: “What kind of framework do I wish I had access to right after finishing Core 3 — one that also helped me grow as a developer?” The result is a framework that supports advanced architectural design without requiring deep LVOOP knowledge upfront. 💡 It’s Easier Than You Might Think Many beginner and intermediate developers have told me that Workers felt familiar and intuitive from day one. Why? Because you still build applications in the style of the NI QMH template — only now, with powerful tools that handle the hard parts for you. 🔧 Development Tools Do the Heavy Lifting: Create and plug in new Workers to build your application architecture Auto-generate Local and Public APIs, including ones callable from NI TestStand Debug your system — whether running in the LabVIEW IDE, as an EXE, PPL, or on a cRIO Visualize call chains with the Call-Chain Viewer Use pre-built Workers, including: Message Pump Worker TCP Server/Client Workers 👨‍🏫 What About LVOOP? Let’s be honest — LVOOP can feel daunting at first. That’s why Workers gently introduces object-oriented principles in a way that feels natural and manageable. The only required use of LVOOP is the Worker itself — each module is implemented as a class Think of Workers as smart LabVIEW libraries — classes with enhanced capability The scripting tools handle the boilerplate code: API generation, inheritance setup, and more You’re never left on your own to figure it out — Workers supports your learning curve and offers a practical, visual, hands-on path to LVOOP understanding. 🧱 Build Your Skills Naturally Over time, you’ll become comfortable with the use of LVOOP introduced by the framework, and you’ll see how features like: API abstraction Worker inheritance and polymorphism Runtime selection of concrete Worker classes ...can lead to reusable, maintainable, scalable application design. 🚀 Final Thought You don’t need to be an expert to build something powerful. You just need the right structure — and a clear place to begin. 📚 Want to Get Started with Workers for LabVIEW? To help developers get started with the framework, the best place to start is with the Workers for LabVIEW Training Course. This free course walks you through the core concepts, API design, debugging tools, and real-world exercises to help you build scalable applications with confidence 📖 Download the training course here: 👉 https://community.workersforlabview.io/training-course

Latest Questions and Discussions

SC
PPL Plugin Architecture Issue in DMM HAL: Type Casting Failure Due to Inheritance Dependency
I am working on building a PPL plugin architecture for the Shipping example in the DMM HAL. While I can successfully build the PPL, the example fails at runtime. After debugging, I found that the PPL built for the HAL layer breaks during type casting. This appears to stem from the child class being dependent on the parent class. Even when attempting to build a minimally dependent PPL (similar to the Keithley approach), the HAL classes are still pulled in due to inheritance relationships, which ideally should be avoided. One approach I considered was disconnecting or removing typedef dependencies before building the PPL, so that the child class is no longer tightly coupled to the parent. However, it looks like the child Main VI directly calls MHL Cases.vi, which introduces another hard dependency. Because of this, even if the typedef dependency is removed, this direct VI linkage becomes another bottleneck and prevents proper decoupling. Has anyone encountered a similar issue? Is there a recommended workflow or best practice when building PPLs for the HAL layer, especially when dealing with workers and inheritance hierarchies? Main vi of Keithly DMM class
Using device drivers in a workers application
Hello everyone, this might be a beginner’s question, but what’s the best way to integrate a device driver – which I wrote in a separate project – into a Workers project? The driver is used to control two linear axes. I have it as a .lvlib file. Would it make more sense to rewrite this as a Worker?
Launching a Workers HAL as a remote plugin using a config file
After creating a HAL using the traditional method where the base class and child classes are part of the main application project, I wanted to try launching the same HAL after moving it to another location on disk and putting it in isolation in its own Workers project. The goal would be to have no LabVIEW project dependency between the main application and the HAL that is called. An external config file is used to give a path to the base class and which child classes are launched, giving a worker alias to each one. The code I created, which uses "Get LV Class Default Value.vi" and "To More Specific Class.vi" seems to be working correctly as I can launch the remote HAL and it functions normally. However, I see a difference in how the Workers Debug Server shows its status. In the traditional HAL project, all the Workers show their status as "Initialized", but in the remote HAL project, the Workers Debug Server show their status as "Initialize called", which implies the workers did not complete their initialization (even though they seem to be functioning normally). My question, is the status shown in the debug server expected or is there still a problem to be solved here?

Guidelines

1. Be kind and respectful

We encourage members to interact with kindness, empathy, and respectful language.

2. No SPAM, please

No one likes SPAM, so please avoid sharing links repeatedly or you may be restricted.

3. Sharing is caring

Found something interesting? Share it with the community. Remember sharing is caring.

4. Stay on topic

We love movies and TV shows too, but for the sake of keeping order, please stay on topic.

Welcome to Our Community

In this vibrant space, we unite under shared values of respect, growth, and collaboration. Our guidelines serve as the foundation for a constructive and supportive environment where every member can thrive.

Content and Behavior Policies

Illegal content, profanity, and misinformation have no home here. We strive for authenticity and accuracy in our exchanges. Inappropriate behavior may lead to account suspension, so let's build trust and safety together.

Posting Guidelines

To maintain order and relevance, please:

Review these guidelines thoroughly before engaging.
Avoid illegal activities and content.
Eschew threats, bullying, and harassment.
Check for existing discussions before starting a new thread.
Never share personal information without consent.

Together, We Build Better

As a member of this community, your insights, experiences, and contributions shape our collective journey. Let's engage, innovate, and elevate our community with every post.