DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Where to dynamically launch a module? EHL or MHL?

I'm dynamically launching a few clones, and I'd like to pass them some info using start.vi (this is fine, no questions there). But I'm not sure where to launch them. The MHL of my launcher carries the pre-launch info I want to pass them, while the EHL of my launcher needs to register for their broadcasts.

 

Should I launch the clones in the MHL where I can give them their data, then message my EHL saying the clones have launched and to register for their broadcasts?

Or launch them from the EHL so the registration can happen... but having the launch info held by the EHL feels terribly wrong. 

 

I don't want to send the info to the clones after launch using a request as it's info I'd like them to have on startup. This is my first DQMH project, but I always enjoyed using ephemeral actors with actor framework and it's an element I'd like to keep using, but am just trying to work out if I can.

-------------------
CLD
Message 1 of 18
(611 Views)

To keep your code readable and maintainable, I think it is worthy to follow some rules - even if you could do it another way.

In case of DQMH I always follow the rule to catch the events in EHL but execute the actions inside MHL. My recommendation is to start the clones inside the MHL. So if you add something later like a configuration or identification request to the clones, your EHL keeps responsible. And if the EHL catches a broadcast from any clone, you can forward a message to MHL to process the follow-up actions.

Message 2 of 18
(601 Views)

Thanks yeah that's a good angle to come at it from. If I'm strict about the MHL always being the doer then even though I didn't like having to have the two parts to the launch (launch the clones and then telling the EHL to register) it at least keeps the responsibilities of the EHL&MHL clean. That's more important to prioritize throughout my design than how many steps something might involve- I was losing sight of that. Thanks! 

-------------------
CLD
Message 3 of 18
(587 Views)

@Ludwig72 wrote:

To keep your code readable and maintainable, I think it is worthy to follow some rules - even if you could do it another way.

In case of DQMH I always follow the rule to catch the events in EHL but execute the actions inside MHL. My recommendation is to start the clones inside the MHL. So if you add something later like a configuration or identification request to the clones, your EHL keeps responsible. And if the EHL catches a broadcast from any clone, you can forward a message to MHL to process the follow-up actions



Trying to follow what you are saying here. In order to have the start inside the MHL, then the event refnum line must be forked down to the MHL?  Then on the back end, how do I merge the two refnum lines?

 

shuttlefan_0-1737152498171.png

 



0 Kudos
Message 4 of 18
(409 Views)

There is no need for merging as this is a reference - no data flow. It is automatically updated in EHL also. Not even a shift register is required here.

Message 5 of 18
(388 Views)

I might be doing this wrong but after I'd launched my module in the MHL I've been sending an event to my EHL to tell it to register for the new modules broadcasts, which then occurs in the triggered event case. 

 

This is limiting though as it requires you to know which module got launched, I'd be interested to know how to set this up for a module which isn't decided to be launched until runtime. 

-------------------
CLD
0 Kudos
Message 6 of 18
(374 Views)

Ok, for better understanding I give you a screenshot from my application:

caption: registering modules in DQMHcaption: registering modules in DQMH

 

 When the module is initialized, it sends back a broadcast to the caller to go forward to the next module.

Message 7 of 18
(369 Views)

@Ludwig72 wrote:

Ok, for better understanding I give you a screenshot from my application:


Where are you calling the "Start and Configure DAQ" MHL case from?

This would be after the Initialize MHL case has already completed?

0 Kudos
Message 8 of 18
(360 Views)

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!




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (Developer Experience that makes you smile )


Message 9 of 18
(356 Views)

@shuttlefan wrote:

 

This would be after the Initialize MHL case has already completed?

Yes, correctly.

 


@shuttlefan wrote:

Where are you calling the "Start and Configure DAQ" MHL case from?


I use the HSE state machine for starting my modules in a sequence and the module initialized broadcast triggers the next state in my main module. But you can do this in any other way also.

0 Kudos
Message 10 of 18
(344 Views)