Registering for cloneable module broadcasts from a top level module

[SolPS]

Hello,

I have a question. The scenario is this:

A top level module launches two singleton modules A and B.  Module B then launches cloneable modules C and D. The issue now is that Module A needs data from C. What is the best way for module A to register for the broadcasts from C? I know I could go up the tree and send another broadcast through the launcher module but I was wondering if it is possible for A to register and receive broadcast data.

Thanks

[Darren]

If Module A depends on broadcasts from C, and B is what launches C, then I think Module A should launch module B. Module A can use the Null Broadcast Events VI from Module C to initialize its Register For Events function to define the type, even though Module C hasn't launched yet.

Once Module C launches, Module B should be registered for Module C's 'Did Init' broadcast, and when it gets that broadcast, it should then tell Module A (through a broadcast is fine) that Module C has started, then Module A can use Module C's 'Obtain Broadcast Events for Registration' VI to update the event registration (which was previously defined with the Null Events VI) with the actual events.

[SolPS]

Hello Darren,

Thanks for the quick reply. I will give it a try and let you know.

[joerg.hampel · Accepted solution]

An alternative could be for Module A to ask Module B for the broadcast event reference but for both A and B to use a separate typedef for the event datatype. That way, no static dependency is created between A and C.

We do this quite often when a generic data sink (eg a logger) shall receive data from a generic data source (eg a DAQ module). The logger knows it expects data of the type of Array of Waveforms, for example, but doesn't care where the data actually originates. It prepares its own event registration with its own typedef for an event of that type (i.e not using the Null broadcast event ref typedef of the DAQ module).

The Main module - which starts both the DAQ and the Logger - has static dependencies to both modules. It can read the DAQ broadcast reference from the DAQ's Obtain Broadcast Events for Registration.vi and forward it to the Logger. The Logger can now use the live reference to register for the event without creating a static dependency to the DAQ module (or even knowing about it).

These pictures are from a training we gave a while ago:

 

 

[SolPS]

I ended up following Joerg's suggestion by having module B share the broadcast event reference with module A.  I always strive to keep my application designs at no more than three layers whenever possible. Having module A launch B would create an additional layer which increases the complexity a little bit. Again thanks Joerg and Darren for your timely suggestions. Much appreciated!