✨ Wishlist

Got an idea to make Workers for LabVIEW better? We'd love to hear your great ideas!

  • Allow Public API Responses in the EHL

    Consider allowing Public API Responses to be used in the EHL. One of the things I REALLY LIKE about Workers is that receiving a Public API message (request or response) requires a case only in the MHL, whereas receiving the same kind of message in an event-based framework requires a case in both the EHL and MHL. Currently, though, sending a Public API Response in Workers to announce a user action (e.g. button click) requires an EHL case to capture the user action and an MHL case to send the response. Also needed is a Local API Request to go from EHL to MHL. It would be great to eliminate the need for the MHL case when sending a response. Seems like there are two ways this change could be implemented, in order to share the Response Cases with the EHL. Send an event to the EHL from the MHL Initialize case. Store the Response Cases in a DVR and use read/write VIs instead of bundle/unbundle. Thanks for considering this idea!
    1

  • Remove Unnecessary VI Outputs

    Consider removing outputs from Core and generated VIs that do not modify data. A few years ago, I read this post that recommends removing unneeded outputs. Once I got used to this approach, there was no turning back. There are fewer wires and it is obvious which VIs change data (or generate errors) and which VIs do not. If you decide to implement this change, it need not break existing code. You could put the new version of the palette VI inside the old version of the palette VI. A reason for retaining the "dup" outputs is that it gives the option to wire the unneeded outputs or not to wire them. So it is understandable if you decide to retain the "dup" outputs.
    0

  • Multiple Statically Linked Instances of a Worker

    Given a Worker named 'MyWorker', called statically by the head worker, an attempt to create(from Create/Add worker>>Add Existing tab) a second statically called instance of 'MyWorker' will result in the subWorker class object and subworker setup VI's suffixes to use 'MyWorker 2 ' as the name. It will be nice to have an option to modify this name while adding multiple instances of a statically called subworker. For example, a 'DigitalOutput' worker can be called statically by the head worker as 'ValveControl' and further instances as 'Safety Interlock', 'LightsAndFans' etc. This way the name is non ambiguous and very direct. Or should I be using the inherit option in the 'Create New' worker menu and select inherit from 'DigitalOutput'?
    3

  • Convert Option for Public Request API's (Public Request <> Public Request w/ Reply)

    Often there is a case where the developer creates a list of 'Public Request' API's and later realize that it has to be of the type 'Public Request w/ Reply', or vice-versa. It will be really useful to have an option to convert between these request types.
    1

  • "Message Pump" Worker that sends a message a specified number of times

    I enjoy programming an implementation for the "dining philosopher problem" for different LabVIEW frameworks. For an implementation based on Workersforlabview I needed a "one-shot message pump worker" that can send different messages. The same functionality as the Actor Frameworks Time Delayed Send Message.vi. Take a look at a possible implementation Timer Worker 5.0 in https://github.com/Lua4LV/DPP-LabVIEW.
    1

  • Dynamically Loaded Workers in Call-Chain-View

    I'm heavily using the abstraction to switch between real - hardware and simulation. Depending on a configuration-file (json) my application decides, which "modules" are going to be loaded and in which configuration (hw / simulation). Workers coming out of case structures will not be shown in the "Call Chain View", this would be nice 🙂 🔽 See Code below 🔽
    1

  • Convert Worker Public API to Worker base class

    Sometimes I create a Public API in a Worker, yet wish that I had actually created it in a Worker base class so that I can use the abstract Public API instead of the concrete Public API. Reworking this takes a lot of effort, but this could be scripted.
    0

  • Check number of elements in Worker Message Queues through Debug Server

    It would be great if there was a way to display the number of elements in each Worker's Message Queue... periodically even, once per second should be enough, in the Application Manager of the Debug Server application.
    0