DQMH Consortium Toolkits Feature Requests

cancel
Showing results for 
Search instead for 
Did you mean: 
j.eggs

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

Status: Released

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
Olivier-JOURDAN
Active Participant
Status changed to: Released
 

Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!