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.