Ask a question, offer your knowledge by answering others, and explore topics discussed by community members.
Ask and Discuss
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 18Using 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? 03Launching 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? 22How to disable Workers application running when LabVIEW starts up.
When I launch LabVIEW the Workers init splash screen takes a long time and I don't want it running at all as I don't use it regularly, but I pay the penalty for having it installed. Is there a way to disable this init on Load? 04Integrate Existing Implementation on WORKERS 5.0
Hello everyone. I’m currently working on an application that’s basically a large GUI with some communication modules for different systems. This GUI manages a large number of different panels. Many of these panels come from existing systems that aren’t implemented for WORKERS 5.0, and many don’t even follow a QMH scheme for their operation. Many are nothing more than simple state machines. I have currently integrated it using a somewhat crude ‘patch’. Is there a simple way to make a VI a Worker-compatible VI without it having a QMH as such? 01Overrides of methods in a worker base class instead of override of MHL cases in childs
Hi, I´ve checked the examples under https://docs.workersforlabview.io/getting-started/example-projects, especially the Workers DMM HAL Project. The abstraction is done by using a worker base class "DMM HAL" and the concrete devices are overriding the MHL cases of the base classhttps://files-us-east-1.t-cdn.net/files/FqgMCKXXTT8mFym4dtMJj . Original Implementation: My question is , why not creating a method like "xReadMeasurement" in the base class and then just override this method without the override of the MHL case? Is there any disadvantage? Is this against the framework somehow? My suggestion: In my opinion unit testing would be easier but I´m afraid of running in some problems I do not see at the moment for the reason just starting with the framework. So I would be happy for some feedback 😃 12Call-Chain Viewer not showing workers after migrating project to LabVIEW 2025 Q3
Hi everyone, I’ve recently updated my environment to LabVIEW 2025 Q3 and I'm using Workers Framework. While the framework itself is running perfectly (Workers are launching and communicating as expected), I’ve encountered an issue with the Call-Chain Viewer utility. It fails to list any active workers in my legacy project. Here is what I’ve observed: New Projects: If I create a brand new project in LabVIEW 2025 Q3 and launch a Worker, the Call-Chain Viewer works perfectly and displays the hierarchy. Migrated Projects: In the project I migrated from LabVIEW 2020, the Call-Chain Viewer opens but remains empty, even though the Workers are definitely running in memory. What I’ve tried so far: Verified that VI Scripting is enabled in Tools -> Options. Performed a Mass Compile on the project and the framework folders. Cleared the Compiled Object Cache. Has anyone experienced this specific "ghosting" of Workers in the Call-Chain Viewer after a version upgrade? Any tips on how to force the Viewer to re-link or recognize the instances in a migrated .lvproj? Thanks in advance for the help! 07Pub/Sub or data broadcasting possibilities
I am about to start a new software application and am exploring options. I am enjoying what I see so far for Workers, but had a question for how you see the "standard" way of streaming data from N to N. Our system would have N number of Hardware Workers that handle all of the interaction with each piece of hardware. These would be subWorkers from a "control" worker. I want to broadcast that data so that any other worker can receive it, if they have subscribed to it. (I'm imaging using User Events for this.) The number of subscribers could be N number and would need to operate asynchronously. Imagine these as "reporters" that could be writing to file, database, or display. The User Event would be created at the Top Level Worker and be given to all subWorkers as they are generated, to ensure a single shared User Event that any given Worker can choose to subscribe to or not. I know this inherently breaks the 1 to 1 messaging Workers has, but unsure how else to stream data like this in the framework. All the rest of messaging would follow the standard Workers API. The data being streamed would all be some child of a custom Data.lvclass hierarchy, so handling the data types wouldn't be a concern at this level. Is there a better way of doing this in the Workers framework that I am not seeing? 01Password-Protected Workers Core VIs
I'd like to look under the hood of the Workers Core. I can guess what it's doing but I'd also like to see the code. Do you share the password to let people look under the hood or is there another way? You describe the Workers Core as open-source, so I'm guessing my request is not out of line. Thanks. 11Subpanel with workers
Hi Peter Could you give me the example that existed with version 4.0, where workers are used with sub‑panels? thanks 03
