Where to dynamically launch a module? EHL or MHL?

[Ludwig72]

---

@joerg.hampel wrote:

We've put some work into updating and tidying our HSE Coding Conventions for DQMH, and I've finally gotten around to starting a new page describing the process of starting DQMH modules (work in progress): 

https://dokuwiki.hampel-soft.com/kb/bestpractices/codingconventions/dqmh

https://dokuwiki.hampel-soft.com/kb/labview-frameworks/dqmh/starting-modules

Please feel free to give them a glance and let me know what's missing. I really appreciate any and all input. Thanks in advance!

---

Thank you for this great tutorial. I couldn't describe it better 😊

[shuttlefan]

---

@joerg.hampel wrote:

We've put some work into updating and tidying our HSE Coding Conventions for DQMH, and I've finally gotten around to starting a new page describing the process of starting DQMH modules (work in progress): 

https://dokuwiki.hampel-soft.com/kb/bestpractices/codingconventions/dqmh

https://dokuwiki.hampel-soft.com/kb/labview-frameworks/dqmh/starting-modules

Please feel free to give them a glance and let me know what's missing. I really appreciate any and all input. Thanks in advance!

---

thanks! digesting this now.  
I do have a question about this.  What's the reason for having another registration inside the EHL before the "stop submodules"?

Can you post what the Stop Submodules MHL case looks like?

Also, for starting in the MHL variant_2, where is the "start submodules" being called from?  

Thanks!

[joerg.hampel]

Thanks for calling me out on that screenshot for MHL variant_2 which I should not have used in the first place 😉

As for your first question, when stopping child modules (submodules), we also want to unregister from their broadcast events. We do that by writing the Null broadcast references to the register for events node (resetting the registration). In the MHL case, the modules are then actually stopped. Ideally, it should be the other way around - I'll have to update that example and screenshot.

Technically, it would probably not be necessary to unregister as the modules will destroy their event references when stopping, and no more broadcasts will arrive at the event structure anyhow. Still, it is good practice to tidy up after oneself.

Regarding your second question, we usually have a state machine that automates sequential actions inside our modules. Also, our Application Template calls the "Configure" request automatically for any module it starts, that's another potential place for sending such a request (usually in combination with a state machine, though).

[adkin]

Hey Joerg, thanks for the detailed breakdown of the various startup options. It's very helpful as a DQMH beginner.

Looking at the 'MHL Variant 2' example, is there a specific reason that you've not wired any incoming error in the MHL? Is this just up to your use case whether you want an incoming error to prevent child module startup or not?

Thanks,

Aaron

[adkin]

It also looks like you're using a "Private Request and Wait For Reply" event. I don't see the ability to create that with the built-in scripting tools. Is that something that you've developed internally? Or you just create a Private Request and add what you need to create the notifier?

Thanks,

Aaron

[joerg.hampel]

---

@adkin wrote:

Looking at the 'MHL Variant 2' example, is there a specific reason that you've not wired any incoming error in the MHL? Is this just up to your use case whether you want an incoming error to prevent child module startup or not?

---

I'd love to claim that there's something very very sophisticated behind this. There's not.

Pretty much the only thing that can happen when entering most MHL cases is for the Variant to Data node to return error 91 if the datatype in the variant doesn't match the constant on the block diagram. Depending on the calling code of the request, that might be extremely improbable.

In the example code I used for the screenshots, I was just careless (as it doesn't make a difference for that example code). I will go and update the screenshot to avoid confusion.

[joerg.hampel]

---

@adkin wrote:

It also looks like you're using a "Private Request and Wait For Reply" event. I don't see the ability to create that with the built-in scripting tools. Is that something that you've developed internally? Or you just create a Private Request and add what you need to create the notifier?

---

What a keen eye! Yes, it is manually created.

Here at HSE, we really would like to use DQMH scripting for creating Private Requests and Wait For Reply. So much so that we first posted a feature request and then sponsored the implementation - DQMH 7.1 will ship with scripting support for this! 

[adkin · Accepted solution]

After going through the process today, I can see how scripting it would be very beneficial for everyone, so thanks in advance!

In case anyone else is interested in creating a "Private Request and Wait for Reply" event for synchronous communication within a module, I've detailed all of the steps below. Some of the steps are only cosmetic so the end result appears as if it was scripted. Let me know if I've missed anything.

1. Create a standard Request and Wait For Reply event. Name this event according to what the EHL will do (Update Sub Module Broadcast Registration) since it will be processing the request.
2. Remove the API Tester case that is created. Since we're converting this to a private event, this call can't be made from outside of the library.
3. Move the new Request.vi from Public API\Requests to Requests\Private Requests
4. Move the new Request Argument--cluster.ctl and Request (Reply Payload)--cluster.ctl from Public API\Arguments\Request to Requests\Private Requests\Priv Req Arguments
5. Open Request Events--cluster.ctl and move the new User Event Refnum into the nested Private cluster.
6. Open Obtain Request Events.vi and update the Bundle By Name to reflect the new private location.
7. Open Destroy Obtain Request Events.vi and update the Bundle By Name to reflect the new private location.
8. Open Request.vi and update the Bundle By Name to reflect the new private location.
9. Remove everything in the EHL case except for the Wait Notifier event data node.
10. Move the Reply Payload and Send Notification from the MHL to the EHL. Remove the case structure around the Send Notification since we will always wait.
11. Wire the EHL Wait Notifier event data to Send Notification and the error output of the Send Notification to the EHL Error Handler.
12. Delete the MHL case.
13. Update the EHL comment to reflect the private call. (This module called the "Private.Request" private request.)
14. Update the EHL comment colour to RGB(218,136,255) to match a scripted private event.
15. Update the Request.vi icon to include the private key (search glyphs for "private") and align any text to the left.

Thanks,

Aaron

[Shiv0921]

Maybe I'm over marking the solutions to this post, but the answer above is very useful for implementing the solution recommended in the HSE coding conventions, so wanted to highlight it as well.