Hello,

Without much difficulty, I have just completed my first Workers project with a basic architecture. The goal was to familiarize myself with the framework before moving on to more complex projects.

Now comes the time to generate an executable. As a long-time LabVIEW developer, I obviously know how to build executables. However, I still have a few questions regarding this framework, since it requires a Launcher.

I assume that the HEADER Launcher should be defined as the Startup VI. Is that correct?

How should the application be stopped when running as an executable?

Is it possible to do this using a button placed on the front panel of MAIN UI? If so, what action should be performed in the EHL to shut down the application properly? For example, should a local request be sent to trigger the "Start Exiting" state of the MHL?

The help documentation and the training manual, both very well written, do not seem to say anything about building executables. Or perhaps I have simply missed those instructions.

Thank you for any clarification you can provide.

Best regards,

JB

Description
When a Caller is registered for Public Responses that share the same name but belong to different Workers, Ctrl+8 on any of the senders cycles through all matching response cases in the Caller instead of landing on the one belonging to the originating Worker.

Root cause
The shortcut searches only for the VI name rspvtd_<response name>.vi rather than the fully qualified name <Worker name>.lvclass:rspvtd_<response name>.vi, so same-named responses from different Workers all match.

Fix
Match on the fully qualified name, including the owning Worker class.

Before adopting Workers, I put it through its paces, and if feel it has been vetted as a solid framework that on its own, won't introduce random bugs or race conditions.

I currently run Thetic Engineering Ltd (thetic.co), in the UK, where I consult on automated test systems, usually focused on semiconductor or materials research. In parallel, I run my own training courses in LabVIEW, Python, and TestStand that are designed to advance the users to understanding specific test scenarios. My company has sponsored GDevCon #6 and #7 to promote Automated Test Excellence, the concept of implementing consistent, best practices within Test Teams (such as adopting Workers).

Happy to meet up and talk with anyone enthusiastic about the above.

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.