DQMH broadcast event not received

[marcoctln]

Hi all,

I'm working on a project with a launcher module that starts all the DQMH's modules of the project.

In particular I have a NS module that launches a broadcast event to the the other modules.

 

Here the initial registration in the launcher modules.

and here the registration after the startup of all modules:

Most of the times program seems to work well, but sometimes the modules called RTA and PWM (red circled) don't recive the broadcast event from the NS modules (the event case isn't executed at all).

Anyway if i manually close and open againt the registered "RTA" or "PWM" modules it works again and the event is received correctly.

That's way i think that the problem concerns the startup timing or the launching order.

Do you have any suggestion?

Thank you in advance.

[1984]

Hi,

What is an 'NS' module?

If the first two screenshots are from the same VI then why do you register to the events again in the second screenshot instead of just starting the modules and putting the wait for event sync VI right after?

When the problem you described appears I'd launch the API tester of the given module and check if the module responds to any requests or if its completely dead. Are the rest of the modules receiving the broadcasts? It would sound fishy that everybody registered to the same events but one module doesnt receive them while the rest do. 

[marcoctln]

Hi, thank you for you answer.

"NS" is the name of the module that launch the broadcast event.

I've tryed to use the API tester the "RTA" and it's work fine so it is alive.

Also athor two modules that are registered to the same event receive corretly the message as you can see in the images below:

Broadcast received from "CVT_RT" and "TEST EXE step manager" modules:

Not recived from "RTA" module:

Yes the first two screenshot are from the same vi, the second registration is not necessary? I don't have to register again after the modules are started?

 

 

 

[1984]

Certainly weird. I'm also not a real expert in DQMH (still coming here a lot for advice) so lets wait until smarter people arrive. Just one question: the modules are the part of the same labview project right? Cause if you launch the RTA and the rest from different projects then it could cause issues.

Yes the first two screenshot are from the same vi, the second registration is not necessary? I don't have to register again after the modules are started?

---

I've never done anything like that before and never seen anybody doing that before so, I really dont thing that it is neccessary. But the experts will comment this as well.

[marcoctln]

Yes sure, modules are in the same project.

Also while writing i think to have found the problem, error wire not wired...ops 🙂

So the modules RTA and PWM sometimes can start before the "NS" module... my bad.

But i'm interested for the second registration, if it not necessary this can semplify a lot the "startup" block diagram.

[joerg.hampel]

---

@marcoctln wrote:

sometimes the modules called RTA and PWM (red circled) don't recive the broadcast event from the NS modules (the event case isn't executed at all)

---

As you already mentioned, I'd have also guessed that the missing error wires will screw your timing. 

@marcoctln wrote:

But i'm interested for the second registration, if it not necessary this can semplify a lot the "startup" block diagram

---

This question comes up quite a lot of times, I might look into writing a blog post about better practices for starting modules.

In terms of event registrations, LabVIEW needs two things for them to work correctly:

1. At edit time, we need to provide the data type of the event reference(s) and write it to the event registration node. If we didn't do that, we could not even create a frame for that event in the event structure - what would be its name, what would be the data...?
2. At runtime, we need to provide the real, life event reference to the event registration. This can be done in multiple places: Either when creating the event registration (in your example the first screenshot, to the left of the EHL), or later by updating the event registration (in your example, the second screenshot inside the EHL)

From the point of view of DQMH, we can only register for broadcast events after the module has started. The actual event references for requests and broadcasts are only created when starting the (first clone of the) DQMH module! 

In your example, in the first screenshot, you're using the "Obtain Broadcast Events for Registration.vi"s, which will return the correct data type (the module's cluster of broadcast events), but will return different data depending on the run state of the module:

• If the module is not running, this VI will return a cluster of empty (default, null, invalid) references
• If the module is running, this VI will return the actual references (not null, valid)

If you put all these things together, what this means for starting modules and registering for their broadcast events is this:

1. Wire the broadcast cluster to the DQMH_REG_EVENTS event registration node to the left of the EHL
   1. You can use the "Null Broadcast Events--constant.vi" which was introduced with DQMH 6.1 to document and make clear that you're only wiring the empty references to set up the registration, and that the modules are not (or might not be) running
2. Inside the EHL, start the module and overwrite the event registration with the live broadcast references as read from the "Start Module.vi"

Bonus information: Be very cautious when placing code outside the main error structure (i.e. outside of EHL or MHL). If that code takes too long (by default longer than 5 seconds) to execute, it will break the synchronisation mechanism between your calling code and the Main.vi and your "Start Module.vi" might return error 403683 (more details here). 

[1984]

---

Also while writing i think to have found the problem, error wire not wired...ops 🙂

So the modules RTA and PWM sometimes can start before the "NS" module... my bad.

Yes, its the order of execution (missing error cluster in this case). I have modelled this by creating ModuleA and ModuleB where ModuleB is subscribed to one of the Broadcasts of ModuleA. ModuleA definitely has to be started before moduleB otherwise ModuleB doesn't get it's EHL fired.

Experimental data supports the theory presented by Joerg 🙂