DQMH Consortium Toolkits Feature Requests

Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Add "Module ID" to bordcast event generated when creating a "Round trip" event on cloneable module

Status: Accepted

Now, when creating a round trip event, the broadcast event uses the exact same typedef as the reply payload. When using a cloneable module, this causes the broadcast event to miss the module ID and therefore any listener to this broadcast event does not know from which module it comes.


One typical use case we have which illustrates this is a cloneable module to drive a thermal chamber. The "get thermal chamber status" must be a request + wait for reply, but we also added a helper loop in the module's main to execute a periodic status check and the status update must be shared to everyone using a broadcast event so it can be displayed on a top VI's user interface for example. Actually, if we create a "round trip event" the brodcast event created misses the module ID, therefore the top VI cannot know the status of which thermal chamber was updated.


A possible solution I see is the broadcast event to have it's own typedef, composed of the module ID and the typedef of the reply payload.


What do you think about this proposal? Do you have other suggestions?

1 Comment
Active Participant
Status changed to: Accepted
Olivier Jourdan

Wovalab founder | DQMH Consortium board member | Certified LabVIEW Architect |