Timing Issues/Event not firing

[nikvl]

Hi all,

so this is a similar issue to this post but I thought I'd start a new topic instead of hijacking that solved post.

I have Module A which is supposed to start the Module B (which in turn starts Module C, etc.). If I were to start Module B immediately after Module Did Init in the Module A's "Initialize" case, the event does not fire according to the Event Inspector Window. Only after using a Stall Data and/or Highlight Execution did I manage to start Module B. This would indicate a timing issue but I'm perplexed as to why events do not fire right after the "Module Did Init" (In other sub-modules this seemed to have worked fine). 

This is what worked:

1) I send a message back to the MHL to "Init Acquisition Module"

2) Init Acquisition Module contains a private request to start the Acquisition module

3) From there it starts the module and then sends a private request to reregister for Broadcast in the EHL, and finally syncing the events (this architecture is what I gleaned from Joerg's post on tips for Starting DQMH modules but perhaps I have applied it wrongly)

When I first tried to run it, I placed the private request to start the Acquisition module right after the Module Did Init if it does not have an error (in place of the DQMH Enqueue Message circled in red in the first image). However, this didn't work even though there was no error and the private user event would not fire. After replacing with the slightly rube-goldberg-resque method shown above, it works as expected. I suspect this is due to a timing issue and solved by the magic delay fairy by going through the message enqueue-ing system. 

So even though it works now, I would like to understand why and whether there is better practice for issues like these. I suspect this is also related to another issue where I could not catch Module Did Init events from other sub-modules.

Thank you in advance.

[joerg.hampel]

Hey nikvl,

thanks for using DQMH and taking the time to post here.

I'm afraid it's difficult to follow the details of what you tried and what you ended up with. Can you share a minimal example project of two modules that reproduces the symptoms you're seeing?

[nikvl]

Hi Joerg,

thank you for taking the time to reply. The above images are what I ended up with. What I tried was skipping the MHL by putting the private request directly after Module Did Init in the "Initialize" case (i.e. without inserting a message in the queue). That's basically the only difference.

If that's still unclear, I will see if I can try to reproduce it in an example but time-wise it might be a bit difficult.

[Olivier-JOURDAN]

@nikvl, it would be interesting to see what you get with Lumos (there's a 15-day trial version) when your application starts. It may help us understand what's happening.

[nikvl]

---

@Olivier-JOURDAN wrote:

@nikvl, it would be interesting to see what you get with Lumos (there's a 15-day trial version) when your application starts. It may help us understand what's happening.

---

Hi, thank you for taking the time to reply. That looks like a very interesting tool. Unfortunately, I could not recreate a simplified sample that reproduce the problem because there were too many nested modules and I figured that might have been part of the problem. Because while I'm waiting for one module A to report its Did Init, the module A also starts a different module B, which in turn needs to wait for broadcasts from module C, which also relies on module D, etc.

So I've decided to go back to all my individual modules and rework each of them so that each module would be triggered by broadcasts only after specific steps were first completed and instead of module A receiving a broadcast directly from C, C sends broadcast to B which sends back to A. And this time it worked as intended without needing to add a time delay or an extra message in the MHL. 

However I will keep the Lumos tool in mind if I run into further timing issues.

Thank you very much.