Broadcast Events cluster is private - unable to launch my DQMH modules

[Thoric]

Perhaps someone can help me understand why the Broadcast Events cluster is designated Private in DQMH modules?

The only way I can appear to launch a DQMH module without causing a privacy conflict is like this:

In the above example, the Module Start VI provides the Broadcast Events user event cluster and it's wired directly to a Register for Events node. LabVIEW is OK with this.

This is OK for the Test API VI perhaps, however I don't want to launch my many modules like this, I want to use a bigger architecture. Perhaps like this:

I want to wrap my module launching into a subVI, and pass the Broadcast Events clusters out for later processing. Mainly this is because I launch within a Consumer loop and the user event references need to be passed to a separate event structure elsewhere. However, this VI is broken, because the indicator "All Broadcast Events cluster" needed to pass the broadcast event clusters out is in breach of the privacy rule. This little subVI cannot run.

So I tried another option, whereby the event refs are read directly within the event structure at the moment I need them:

This way I'm not passing my Broadcast Event clusters about my code, instead they're read from each module's Obtain Broadcast Events for Registration VI. However, this VI is also broken because the left-hand RegEvents node has no inputs, and as soon as I create defaults I once again have the privacy conflict issue.

Am I missing something obvious here? Is it safe to override the DQMH module recommendation and make the broadcast event cluster public? Why is it private anyway if you're meant to be able to use it?

Thanks in advance everyone for your replies.

[FabiolaDelaCueva · Accepted solution]

Hi Richard,

You need to use "Obtain Broadcast Events for Registration". Look at the API tester for reference, there, this VI is used to declare what type of event you have. If the module is not running, it only declares the broadcast events cluster type. If the module is already running when the API Tester starts, then it returns the actual broadcast events for the current module.

BTW, please don't do this:

---

@Thoric 

---

Do this instead:

The Synchronize for Module events should happen after the Register for Events. More details come in the documentation of these VIs, but mainly the idea is to wait until the calling code is ready to receive events (meaning the calling code has registered for the events) before moving on with the code. This is achieved via rendez-vous that ensure the DQMH module is ready to receive Request events and the calling code is ready to receive Broadcast events. If you look at the API tester in the Start Module event case, we put the register for events in between these two VIs. This is also why these two VIs are not in a single subVI.

Refer to points 5 and 6 on this section of the documentation:

http://delacor.com/documentation/dqmh-html/DQMHProjectStructureOverview.html 

As far as alternatives for calling multiple DQMH modules in a large architecture, I will let others jump in. Also, keep your eyes open for a blog post that we will be publishing at http://delacor.com/blog tomorrow with what Kabul did at Renishaw.

I hope this helps,

Regards,

Fab

[FabiolaDelaCueva]

[Thoric]

Thank you Fabiola,

I hadn't fully appreciated the need to synchronise the caller event registration with the module launch, but I see now that without it there's a possibility of misplaced events. A good safety feature!

My Producer/Consumer main VI launches the modules in one case of the Consumer loop. The registration for broadcast events occurs in the Producer. I therefore have to pass the several "Wait for Event Sync?" outputs from the consumer case back up to the producer for triggering informed event registration. It looks odd, but I see that it's necessary.

It now looks like this:

(ignore the complete lack of error handling etc.)

Thanks for your support Fabiola! Feel free to criticise or comment on the above.