DQMH Events not firing?

[macjock]

PS: I dare say that having to put wait or stall VIs is almost always a code smell...

Yeah caught... It's something I always give my staff grief over!

In this instance my logger is only there to inform me of the order modules are starting and stopping, so won't make it into a release version.  Unless there is some handy VI that does this for me? 

I'll use the method you outline in future - seems really obvious now you point it out..

[joerg.hampel]

*shameless-advertising-ON*

> won't make it into a release version.  Unless there is some handy VI that does this for me? 

We have VIs that do release stuff for us: rat.hampel-soft.com

> my logger is only there to inform me of the order modules are starting and stopping

We use our own open-source logger for that kind of debug information. Public-facing documentation is very light, but you can see it in action in our Windows Application Template. 

*shameless-advertising-OFF*

[ChrisFarmerWIS]

We have hit this problem many a time.  You can solve it a few ways:

1) The magic fairy delay which you already tried - but what we found is we were constantly tweaking this (because we had quite a few children modules) and timing didn't always work.  So this is the simple but unreliable approach.

2) Have the children modules broadcast up that it is ready, before registering everything.  For instance:

• Module 1 launches (and registers for events) of Module 2, and then Module 2 launches (and registers for events) Module 3.  We hold off Module 1 registering for Module 3's events til later.
• Then we have Module 3 broadcast a message to say it is initialised and running.  Module 2 will receive this broadcast.
• Then we have Module 2 broadcast a message to say it is initialised and running.  Module 1 will receive this broadcast. 
• At this point all children modules are confirmed to be up and running, so then Module 1 can re-register for the events of ALL children we need to register for (in this example Module 1 still hasn't registered for Module 3's events).  This is done the same way you've already shown - via a private request.
• Now we're up and running, and there was no magic fairy delay. 

PS.  Still waiting for the JKI Magic Fairy Delay toolkit to become a reality.  That would solve a lot of problems! 🙂

[macjock]

Thanks Ozfarmboy,

Magic Numbers... it's the newbie "I don't really understand this process so I'll try this hack" approach. 

Cascading INIT messages is a much more pragmatic approach.

Cheers!

[FabiolaDelaCueva]

One more option is to have a launcher launch all the modules that you will eventually use.

This works fine if you don't have that many modules. I leave the modules that are "optional", meaning they won't run every time to be loaded later when they are needed.

Tom McQuillan is working on an excellent DQMH Video series, this particular video shows how he created a launcher VI to launch all the modules in order. Now, notice that he is using Singleton modules, his approach would need to be modified to handle cloneable modules.

https://youtu.be/NOy0n8MerVk

Happy wiring!

Fab

[macjock]

Thanks Fabiola, 

I'll be sure to check this out. 

Steve,

[HS254]

Hi Fabiola,

I am in a similar situation where I have to launch Clonable Modules but the modules are triggered. Can you please suggest how can I do this?

Secondly, I am using a JKI SM to start the modules, one is a Singleton which starts perfectly but the other is Clonable.

The two Modules A and B and Singleton and CLonable respectively. "Module Main" consists of Main_JKI which starts the modules. Module A launches Module B (Clonable). And Do I need a launcher VI for Main_JKI too?

[ChrisFarmerWIS]

Hi Himanshu25488,

I don't understand exactly what you're asking here.

Maybe it would be better to start a new discussion thread and elaborate a little more.

What do you mean exactly by "triggered"?