Add Public VI to read the most recent value of a Broadcast

[Photon_Dan]

Once a Broadcast happens, only modules that are registered for it can access the value contained in the Broadcast. If a module starts execution and registers for Broadcasts from another module after that module has sent a Broadcast, the registering module must wait until the Broadcast happens again before it has the latest value. We have encountered some use cases where it is beneficial to know the most recent value of a particular Broadcast. In those cases, we have created workarounds such as a "Refresh" Request that can force a module to repeat all or a subset of its Broadcasts. Of course, that requires the addition of a Request and the code to handle it, etc.

The feature request is to have the Broadcast scripting create two additional VIs for each Broadcast. One VI would be Private, and it would be a data store for the value of the Broadcast event (message). The other VI would be Public, and it would be a Read Accessor for that value. I am picturing the Public VI calling the Private one, and the Private one is a Functional Global. In the Broadcast event VI, the value would get written to the Private VI's Functional Global.

Having a Public VI that contains the most recent value for the Broadcast make it easy to write small state machines or action engines that can access Broadcast value data without Event Structures.

There are other messaging architectures that implement the "Read Global" ability, and it has proven to have value for us in development of some systems.

For Cloneable modules, the "Read Accessor" could take a Module ID as an input.

[mbaudot]

Hello Dan,

Thank you for your continued involvement with DQMH and for submitting this feature request.

After discussing it with the DQMH Consortium and the DQMH Trusted Advisors (of which you are a valued member), we have collectively decided not to proceed with adding this feature by default. We believe that incorporating this additional code into every broadcast may not be the best approach. However, making it a configurable option could be considered.

That said, we believe you can easily achieve this functionality using the Post-Event Creation Hooks—a feature that has already been prioritized for development in the next DQMH release.

Thank you again for your contributions and for being an integral part of the DQMH community.

Best regards,