New Public API VI for all modules: "Start Module and Wait for Initialization"

[Darren]

Many DQMH developers (including myself!) encounter the stumbling block of firing requests before a module is "ready". We assume that the following code is sufficient for starting and synchronizing a module:



The 'Synchronize Module Events' VI ensures that request event references are valid, but it doesn't do anything about ensuring that the module is actually ready. One very common scenario is a module Main VI that includes code in the 'Initialize' frame of the MHL that fires private events to initialize Helper Loops. If the VI that called Start Module isn't waiting on the Module Did Init broadcast, then it could immediately fire a request after calling Synchronize Module Events, and if a helper loop is registered for that event, then helper loop could run the event frame for that fired event before the MHL has had a chance to fire the private event to initialize the helper loop. There are many other possible pitfalls, but this is one of the more common ones I've seen.

To solve this issue, I think DQMH should ship with a Public API VI that is a wrapper for Start Module + Synchronize Module Events, but includes the extra step of waiting for 'Module Did Init'. The module author needs to ensure that the Module Did Init broadcast is called after all necessary initialization code... if they do so, then it is "safe" to begin calling events externally.

Here's my proposed interface for the Start Module and Wait for Initialization VI:

And my proposed implementation:

If this VI shipped with the DQMH singleton and cloneable module templates, it would help us avoid module synchronization + initialization issues like what I describe above.

[Ozfarmboy]

We have this issue all the time and are constantly creating work arounds.  I agree it would be nice to have this as part of the framework, rather than us having to create the workaround each time!

[MichaelAivaliotis]

I think for singletons, you don't want to wait for the event if the module is already running. So a conditional structure might be required if running. Not sure how to handle this with Cloneables.

[Darren]

> I think for singletons, you don't want to wait for the event if the module is already running. 

Right, my proposal includes a mockup of the cloneable 'Start and Wait' VI because it was the more complex implementation. I anticipate the singleton version will look similar to the screenshot you shared.

[FabiolaDelaCueva]

How would we address the issue that registering for the broadcasts after this new VI means some broadcasts would be missed by the calling VI?

Should we instead change the inside of the Synchronize Module Events to have that VI wait for the Module Did Init Event?

[joerg.hampel]

Just as one data point (not saying this feature request should or should not be implemented): This new API would not do much for our modules here at HSE.

1. We never put any business logic into the "Initialize" case (other than starting helper loops etc.). Any module-specific initialization will be implemented in a separate case, possibly triggered via a separate request. Every HSE module has a "Configure" request for that use case.

2. We usually implement our own module-specific "All business code is ready" broadcast where needed, which means that the module is ready to do its job (again, the "Module did init" only reports that the framework has started the module).

[MichaelAivaliotis]

"We usually implement our own module-specific "All business code is ready" broadcast where needed, which means that the module is ready to do its job (again, the "Module did init" only reports that the framework has started the module)."

It depends on what your definition of "Module did init" is. My modules self-initialize, which makes using them a lot easier for me. That way the caller doesn't need to know details about initialization.

[doyles]

"1. We never put any business logic into the "Initialize" case (other than starting helper loops etc.). Any module-specific initialization will be implemented in a separate case, possibly triggered via a separate request. Every HSE module has a "Configure" request for that use case.

2. We usually implement our own module-specific "All business code is ready" broadcast where needed, which means that the module is ready to do its job (again, the "Module did init" only reports that the framework has started the module)."

Joerg, I would say this means that you have developed a standardized work-around to prevent your team from inadvertently getting caught by this issue.  And that implies, at least to me, that a tip or a trick or a guideline is needed to prevent the issue from occurring. Taking that a step further, I think that means that developers are likely to end up in this situation the more that they use DQMH modules and will have to figure out the hard way that there is a "gotcha" lurking in there and how to avoid it.

At the very least, I think the shipping code could add some additional comment blocks that identifies how this can occur. If one comment states to not place any code before the synchronize caller events.vi and another to place all initialization code between the sync subVI and the Module Did Init broadcast subVI.  Having the Mod Did Init broadcast pushed all the way to the right of the Initialize case would be more intuitive as well.

An alternate option would be to put all of the initialization into a subVI that is place between the two subVIs with a note that says to place all initialization code within that subVI. 

I hope these ideas are not misplaced as I'm not attempting to hijack the thread. They are meant as different perspectives of Darren's original post that this area of DQMH has an opportunity for improvement and "something" would likely be beneficial.

Thanks,

Scott

[joerg.hampel]

Great input, Scott! I'm sad I cannot kudo it, hence my comment here. I'll be sure to bring it up at the next weekly Consortium meeting, and we'll work on a way to improve the situation.

[Darren]

> Having the Mod Did Init broadcast pushed all the way to the right of the Initialize case would be more intuitive as well.

Somebody else suggested this a few months ago, and I agree. This change has already been made and will be present in the next DQMH release.