I wanted to share an update regarding the Worker Framework's performance with high-resolution video acquisition.

The Worker Framework successfully demonstrated its capability to execute at a solid 33 ms cycle time, acquiring 8 MP RAW12 at 30 FPS (~500 MB/s) without freezing or crashing. This performance clearly highlights the quality and robustness of the architecture.

The single bottleneck identified during testing was the transfer of this heavy data payload between workers. Passing raw image arrays through the standard APIs caused the consumer thread to miss loop deadlines and introduced extremely high jitter in the standalone executable. We resolved this by replacing array passing in the APIs with Data Value References (DVRs) for inter-worker data transfer, achieving a Zero-Copy pipeline that completely eliminated memory overhead and jitter.

Proposed Framework Add-on Given these results, I would like to propose a potential extension to the framework architecture: a native Zero-Copy / DVR Data Channel Add-on.

Adding built-in DVR helper methods or dedicated reference-based communication channels (e.g., pre-allocated DVR ring-buffers managed natively by the framework) would allow developers to handle massive data streams without needing custom workarounds or bypassing standard API structures.

Workers 5.0 will also be presented at the GLA Summit - For all LabVIEW and TestStand Enthusiasts! on the 25-26 March 2024, so if you want to see the new version in action, please tune in for the live presentation.
 
Again I’d like to thank the guys at Kubes AG, including or in addition to Matthias Kubli, Andreas Scheuber, Sreejith Sreenivasan, Philipp Herzog, Olivier Compondu, for helping to make this version what it has become. I couldn’t have done it without your feedback, support, creative ideas, discussions and testing during the development process.

You can now use your Workers QMHs on NI real-time targets such as a cRIO. Workers v4.0 allows you to develop and debug your Workers on both Windows and real-time targets, allowing you to run your Windows-developed Workers on real-time targets, without needing to develop real-time specific modules.

I’ll be releasing a demo video in the coming weeks showing how to setup Workers applications on both a Windows host and a real-time cRIO, and stream data between the two applications using the new TCP Server and Client Workers (available in the Worker Library).

You can learn more about developing applications with Workers 4.0 here.

#WorkersforLabVIEW #LabVIEW #engineerambitiously

VIPM Download Link: https://lnkd.in/dxmGSY6
NITN Download Link: https://lnkd.in/dTjh8PW8

#LabVIEW #WorkersForLabVIEW #engineerambitiously #LVOOP

I have a project hierarchy like that:

-Head Worker.lvclass (img-1)

----User Interface.lvlib:App UI SubPanel LEFT.lvclass (img-2)

----User Interface.lvlib:Synoptic.lvclass (img-3)

----User Interface.lvlib:App UI SubPanel BOTTOM.lvclass (img-4)

----User Interface.lvlib:Exec Buffer View.lvclass (img-5)

----User Interface.lvlib:App UI SubPanel TOP.lvclass (img-6)

----User Interface.lvlib:Exec System Task Manager.lvclass (img-7)

----User Interface.lvlib:Exec System Tag Tree View.lvclass (img-8)

----Events Handling.lvlib:Exec Error View.lvclass (img-9)

Other "Standalone Workers" without direct dependencies Exept for the Head Worker.lvclass Override VIs

The Head Workers have some Override VIs of the Framewor VIs (Create Stop Event, Dequeue, Error Handler etc. )

The problem is that as the System.lvlib:XXXXXX.lvclasses and User Interface.lvlib:XXXXXX.lvclasses are loaded using Async/Sync Launchers or Dynamic Loaded with Public API these are dependencies of Head Worker.lvclass, so if i have other "Standalone" workers System.lvlib:XXXXXX.lvclasses and User Interface.lvlib:XXXXXX.lvclasses are automatically loaded as dependencies of these "Standalone" workers as are called from Head Workers that has Override VIs or standard VIs to use between Workers.

Is there an already implemented option to abstract the launch of SubWorkers without having it as dependency of Head Worker?

For example the Calculations.lvlib have 2 Workers that have no direct dipendency to User Interface.lvlib (User Interface.lvlib is called dependency of Head Worker.lvclass so is automatically loaded as dependency... or at least i think is that the cause as i didn't find other vi in common except the Head Worker override VIs).

I have already made an abstraction to Dynamically call "Standalone" workers by populating the initial data (that has a standard cluster with a JSON configuration) so i can launch multiple workers loading a database configuration... i would like to check if there is a better solution to avoid these circular dependencies.

Thank you and have a nice day.

Welcome to Workers 5.1 beta! It's been over two years since the release of Workers 5.0, and we're very excited to bring you this long-awaited release. Workers 5.1 is full of new features and improvements, many of which have been requested by the Workers community, all designed to make working with the framework as streamlined as possible.

We hope you enjoy the new features in this version. While the official documentation for all the new tools is still a work in progress, here is a quick overview of what's new in this release.

Important to know: You can continue using your existing Workers 5.0 applications with Workers 5.1. No upgrade or changes to your code are required.

NEW: Remove Statically-Linked subWorker

Included now with the Create/Add Worker tool, you can remove a statically-linked subWorker that has previously been added to another Worker. This essentially reverses the changes made by the Create/Add Worker tool when a Worker is added as a statically-linked subWorker to a Caller.

The tool will not delete the subWorker itself. It removes the subWorker from the Caller, including the wiring on the Caller's block diagram and the framework integration VIs that were created when the subWorker was added.

Any application-specific dependencies on the subWorker, such as calls to its Public Request VIs, still need to be removed manually by the developer.

NEW: Local Requests moved to the API Builder tool

The Public API Builder tool from Workers 5.0 has been renamed to the API Builder tool, and now also allows you to create and manage a Worker's Local Requests.

There is also a new QuickDrop shortcut for opening the API Builder tool: Ctrl+7.

Note that the Create Worker MHL Case tool (QuickDrop shortcut Ctrl+9) is still used to create MHL cases in a Worker to receive Public Responses from a subWorker.

NEW: Delete Requests and Responses

Another new feature in the API Builder tool is the ability to delete Local and Public API Requests and Responses. The right-click menu for each API now includes a Delete Request/Response option.

There are two important things to know:

1. When an API is deleted, its associated API VIs and typedef controls are also deleted from the selected Worker. Any instances of the deleted VIs or controls used elsewhere in the project, such as on another Worker's block diagram, are also removed. A bookmarked comment containing the name of the deleted VI or control is placed at each location so you can easily identify what was removed.

2. The MHL case associated with a deleted Request is not deleted. Instead, it is moved to a new section of the Worker's MHL case structure called --- DELETED CASES ---. This preserves any application logic that you had already implemented in the MHL case.
   

NEW: Add EHL to Worker tool

If you create a Worker without an Event Handling Loop (EHL) and later decide that you need one, you can now add it with the click of a button.

The new Add EHL to Worker tool can be found in the Other Tools dropdown menu of the Workers Tools Menu. As the name suggests, the tool adds and wires the default Workers EHL above the Worker's existing MHL.

NEW: Workers Blueprint – Architectural documentation for your Workers applications

You can find the new Workers Blueprint functionality in the Worker Call-Chain Viewer tool. After generating the Worker call-chain diagram for an application, you can export its architecture to the new .blueprint.json format and open it in the Workers Blueprint Viewer.

Workers Blueprint documents the application's supervision hierarchy, inheritance relationships, and messaging architecture, helping make the overall structure of a Workers application much easier to understand.

The interactive Blueprint Viewer runs locally in your web browser and can render the architecture as a Markdown (.md) document with Mermaid diagrams.

A CLI for generating Workers Blueprints will be provided with the official Workers 5.1 release.

NEW: Pull Workers Examples and User Library Items from GitHub

Additional example projects are available from the Workers Community GitHub repository and can now be pulled and installed directly from the redesigned Workers Example Projects tool.

The same GitHub integration has also been added to the Worker User Library tool, allowing additional Workers, templates, and other library items to be downloaded directly through the Workers development tools.

This means new examples and library items can be made available to the community without waiting for a new Workers release.

NEW: gRPC Worker Templates

Available from the Workers Community GitHub repository are new gRPC Server and gRPC Client Worker templates. These templates provide Worker Public API Requests and Responses that map directly to messages sent over a bidirectional gRPC stream.

The templates provide nine message channels in each direction, which can be adapted to carry your own custom payloads.

You can learn more about the gRPC Worker templates here: Using the gRPC Worker Templates.

NEW: gRPC Workers ↔ Python Example Project

To demonstrate the use of the new gRPC Worker templates, we've created an example showing how a Workers application that simulates an oscilloscope can communicate with a Python application over gRPC.

The example starts from the gRPC Server Worker template and adapts the message payloads in the gRPC .proto contract for the simulated scope application. The LabVIEW Workers application then communicates bidirectionally with a scope UI created entirely in Python.

The example demonstrates how the gRPC Worker templates provide a clean separation of responsibilities between LabVIEW and another language, while communication within the Workers application is still implemented using standard Worker Public APIs.

Other Improvements

Workers 5.1 also includes numerous bug fixes, usability improvements, and performance improvements throughout the development tools. You'll notice many smaller improvements here and there, and the Workers Tools Menu now loads significantly faster.

This is a beta release, so if you find any bugs or unexpected behavior, please report them here in the Workers Community. Your feedback during the beta helps us refine the release and lets us know whether we're moving in the right direction.

For an introduction to the gRPC Worker Templates, please see Using the gRPC Worker Templates – Introduction. It is recommended that you read through this before starting this guided walkthrough.

Important: LabVIEW 2019 or later is required (for the gRPC libraries)
Important: Download grpc-labview.zip from the NI gRPC LabVIEW repository on GitHub and install the three VI packages it contains before creating the template projects. The gRPC Worker templates will not work without them.

Download the gRPC Worker templates from Github

Make sure you have an active internet connection and can access GitHub. Then open the Workers 5.1 Worker User Library tool and follow these steps:

1. Press Pull from GitHub. A dialog will open.

2. Press W4LV-Community Repo to automatically copy the GitHub repository URL into the control below.

3. Press Download items from GitHub. The tool will download the Workers Community GitHub repository as a ZIP file, unzip it, and save the new library items.

Create a copy of the gRPC Worker Templates

After the download from GitHub completes, you should see the gRPC Client and Server Templates in the Items in User Library list.

The next step is to create your own copies of both templates:

1. Select the gRPC Client Worker Template from the list.

2. Press Create copy of Project Template. A dialog will appear.

3. Make sure the path where you want the project to be copied is correct. Important: remember this path, as you will need it later. When ready, press Create Project.

4. After the project has been successfully created, repeat the steps above to create a copy of the gRPC Server Worker Template.

5. After both projects have been successfully created, close the Worker User Library tool.

Testing the gRPC Server and Client Worker Templates

Before modifying the templates, let's first verify that the original Server and Client Workers can communicate with each other.

Run the Launcher VIs in both projects. You should see the front panels of the gRPC Server Tester and gRPC Client Tester Workers appear.

Follow these steps:

1. On the gRPC Server Tester, press Create gRPC Server to create and start the gRPC Server. The Server Listening LED should light green.

2. On the gRPC Client Tester, press Create gRPC Client to connect the gRPC Client to the Server. The Client Connected LED on the Client Tester should light green. The Client Connected LED on the Server Tester should also light green.

3. Now that the connection between the Server and Client has been established, enter text into any of the five message controls on either tester. The text should appear in the corresponding message indicator on the opposite tester, demonstrating that messages are being sent and received in both directions.

4. Press Destroy gRPC Client and Destroy gRPC Server, then close both applications and exit LabVIEW completely.

Part A : gRPC Client Worker Project

Modifying template.proto

For the next step, we will modify some of the default message payloads in template.proto.

Go to the folder where you saved your gRPC Client Worker project and do the following:

1. Delete the folder called Generated_client. (Later on we will re-generate this folder using the NI gRPC Code Generator tool.)

2. Open template.proto in your preferred text editor.

3. In template.proto, change the payloads of Msg_ToServer_1 and Msg_ToServer_2 to the following:

message Msg_ToServer_1 { bool run = 1; int32 position = 2; }
message Msg_ToServer_2 { double temperature = 1; }

4. Next, change the payload of Msg_ToClient_1 to:

message Msg_ToClient_1 { string error_message = 1; int32 error_code = 2; }

5. The remaining messages are placeholders that you can customize for your own applications. You can change their payloads to use the protobuf data types supported by the NI gRPC implementation. The NI gRPC Repository and the official Protocol Buffers documentation provide additional information about defining protobuf messages and the data types available in .proto files.

6. Save template.proto.

Important to know: When editing template.proto, only change the message payloads and any supporting types you add. Do not rename the package, service, RPC, message names, or oneof case names. The NI gRPC Code Generator uses these identifiers when naming the generated files, VIs, typedefs, and classes. Keeping them unchanged ensures that the regenerated code remains compatible with the existing gRPC Worker templates.

Regenerating the gRPC Client Library

The next step is to regenerate the gRPC Client library so that it matches the new message definitions in template.proto.

Start LabVIEW again and select:

Tools > gRPC > Open gRPC Server-Client[2] - Code Generator...

With the NI gRPC Code Generator open, perform the following steps:

1. For Proto File Path, enter the path to the modified template.proto file.

2. For Target Project, enter the path to the gRPC Client Worker LabVIEW project you created earlier.

3. For Generate Server or Client?, select gRPC Client.

4. Run the VI. The generator may take a few minutes to complete. Once it has finished, the gRPC Client Worker project should open automatically.

5. Save the gRPC Client Worker project and close it.

6. Back in the Windows Explorer folder for the project, you should now see that the Generated_client folder has been recreated, as shown in the screenshot below. Close the window.

Part B : gRPC Server Worker Project

The following steps repeat the process you just completed for the gRPC Client Worker project, but this time for the gRPC Server Worker project.

It is important that both projects use the same modified template.proto, because the gRPC Server and Client must implement the same message contract.

Modifying template.proto

Go to the folder where you saved your gRPC Server Worker project and do the following:

1. Delete the folder called Generated_server. For this walkthrough, we will regenerate this folder using the NI gRPC Code Generator.

2. Replace the existing template.proto file with the modified template.proto from your gRPC Client Worker project. This ensures that both the gRPC Server and Client are generated from exactly the same message contract.

Regenerating the gRPC Server Library

The next step is to regenerate the gRPC Server library so that it matches the new message definitions in template.proto.

Start LabVIEW again and select:

Tools > gRPC > Open gRPC Server-Client[2] - Code Generator...

With the NI gRPC Code Generator open, perform the following steps:

1. For Proto File Path, enter the path to the modified template.proto file in the gRPC Server Worker project.

2. For Target Project, enter the path to the gRPC Server Worker LabVIEW project you created earlier.

3. For Generate Server or Client?, select gRPC Server.

4. Run the VI. The generator may take a few minutes to complete. Once it has finished, the gRPC Server Worker project should open automatically.

5. Save the gRPC Server Worker project and close it.

6. Close the NI gRPC Code Generator.

7. Back in the Windows Explorer folder for the project, you should now see that the Generated_server folder has been recreated, as shown in the screenshot below.

Part C : Testing your newly generated gRPC Messages

Now reopen both the gRPC Client Worker and gRPC Server Worker projects.

1. Run the Launcher VIs in both projects.

2. On the gRPC Server Tester, press Create gRPC Server.

3. On the gRPC Client Tester, press Create gRPC Client. As before, the Server and Client should connect and the corresponding status LEDs should light green.

4. Test the new message payloads. On the gRPC Server Tester, change the values in Msg_ToClient_1. The new message payload should be received and displayed in the corresponding indicator on the gRPC Client Tester.

5. On the gRPC Client Tester, change the values in Msg_ToServer_1 and Msg_ToServer_2. The new message payloads should be received and displayed in the corresponding indicators on the gRPC Server Tester.

6. Test the remaining gRPC messages, making sure that what is sent is received on the opposite tester UI.

Notice that at no point did you need to modify the gRPC Server or Client Workers themselves. The Tester Workers ran immediately with the new payload typedefs. Because only the payload definitions were changed in template.proto, the names of the files, VIs, typedefs, and classes generated by the NI gRPC Code Generator remained unchanged. This allowed the existing Workers to re-link to the regenerated libraries automatically, with no manual rework required.

Conclusion

You have now demonstrated how to customize the gRPC Worker Templates by changing the message payload definitions in template.proto and regenerating the corresponding LabVIEW gRPC libraries with the NI gRPC Code Generator.

This provides a straightforward way to adapt the gRPC Worker Templates to the data required by your own applications while maintaining a common gRPC contract between the Server and Client.

In Part 3 (coming soon), we’ll look at a real example built from the gRPC Server Worker Template: the Workers ↔ Python Scope Example, which is already available with the Workers 5.1 beta. In this example, a Workers application simulates an oscilloscope in LabVIEW and communicates with a Python UI over the same bidirectional gRPC stream.