Wait for init?

[1984]

Is there an easy way to know if a module is initialized? I mean I can register and capture the "did init" event but I'm launching about 20 modules in parallel so this seems tedious. My current solution is to simply wait 750ms, but this is quite poor.

Wouldn't it make sense to have a VI generated automatically for the modules which can be used wait for the "did init" event of the module?

I may miss somehing, though.

[joerg.hampel]

I'm curious: Why do you need to know exactly when the "Did Init" broadcast was sent? Is it to understand when additional code that you put inside the "Initialize" case of the MHL has finished executing?

[Darren]

I'm also curious. I've definitely needed this functionality before, but only a handful of times in some corner case scenarios... definitely not enough that I ever wished the framework scripted it for me.

[Ozfarmboy]

Our standard approach at Wired-in is that every module has a request and wait for reply called "Initialise settings". Here we send down the parameters/settings that we want the module to run with.

We call this immediately after starting/syncing the module, and basically when the reply comes back, we know it's now setup and initialised.

[1984]

---

@joerg.hampel wrote:

I'm curious: Why do you need to know exactly when the "Did Init" broadcast was sent? Is it to understand when additional code that you put inside the "Initialize" case of the MHL has finished executing?

---

From time to time I got into a situation when I assume that a module missed a request right after starting the module. Now I did a test with my logger module and couldnt reproduce so it might be an issue on my end.

[joerg.hampel]

---

@1984 wrote:
From time to time I got into a situation when I assume that a module missed a request right after starting the module. Now I did a test with my logger module and couldnt reproduce so it might be an issue on my end.

The design of DQMH should make it impossible for modules to "miss" requests if the sequence of steps is implemented correctly. 

1. At the caller, we run "Start Module.vi"
   1. "Start Module.vi" starts the module's Main.vi
   2. In Main.vi, "Init Module.vi" creates both broadcast and request events
   3. All other infrastructure is created, to the point where the MHL starts executing and the "Initialize" case runs
   4. In "Initialize", "Synchronize Caller Events.vi" lets the "Start Module.vi" know that all resources have been created and the module is ready to operate,
   5. "Synchronize Caller Events.vi" then waits for what we call Event Sync.
2. "Start Module.vi" returns the broadcast event references
3. At the caller, we run "Synchronize Module Events.vi" 
   1. Here, we acknowledge the Event Sync 
   2. Then, we wait for Module Sync
4. In the Main.vi's "Initialize" case, the "Synchronize Caller Events.vi" acknowledges the Module Sync and returns.

As you can see, after (4), both the module and the external caller are both ready to start exchanging data. 

If you send requests to your module only after the "Synchronize Module Events.vi" at the caller has returned, then all the event references and the queue reference have been created successfully, and there should not be any scenario where a request can get lost. 

Please let me know if you feel like I'm missing something - I think this is a very important topic and I want to make sure we get it all right!!

[1984]

Thanks a lot for the very detailed explanation. 

Your explanation used the VIs in this order:

While I just found that for couple modules (including the logger) I used something like this:

Is it possible that could cause a missing event? I guess not, but this is the only difference between your implementation and mine.

At this point I'm not sure if what I saw is related to DQMH at all, it might be a programming error on my end. The module works fine, its just that some time in the past I've seen that the first message was not logged.

[joerg.hampel]

If you don't wait for the event registration to return before executing the "Synchronize Module Events.vi" (i.e. not wiring the error cluster as shown in your snippet), you could miss the first broadcast(s) sent by the module. Seeing as the request events and module queue have been created once the "Start Module.vi" returns, I can't see how requests could get lost. 

My recommendation is to invest the energy to make sure the VIs and event registration are executed in the correct order. This usually pays off in being able to spot problems at module start time - similar to a plane taking off, this is usually a critical point in time.

I know that this is sometimes a pain because of where you start modules (MHL?) vs. where you need to register for the broadcasts (EHL?), but there are a few ways to get this done. I might write an article about this sometime soon.