DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

“Obtain Request Events for Registration.vi” of modules that are not started yet

Solved!
Go to solution

Hi everybody,

 

I am new to DQMH and have issues registering to events of modules that are not stared yet. 

My architecture:

 

"Module Main":

  • Starts Module "TestSelection"
    • Starts Module "Test01"
      • Starts Clonable Modules "A", "B", "C"  (and stops them when finished)
      • I did it this way so that each "TestXY" Module starts and stopes the required modules itself.

 

I would like to register for the "Error Reported" Events of all modules in "Module Main" for a centralised Error Handling (to avoid implementing Error-Handling/Error Messages in each Module).

 

What would be a good way to do this? 

 

In https://delacor.com/dqmh-documentation/dqmh-best-practices/ a "Private DQMH Request Event" was mentioned, but I didn't fully understand this approach. 

 

Alternatively in a similar case in https://forums.ni.com/t5/DQMH-Consortium-Toolkits/What-is-a-good-method-that-is-used-specifically-fo... it was mentioned that the Main-Module should do all the starting and stopping of modules (but this seems a bit more messy because the Main-Module would need to do much more than I wanted). 

I am thankful for any advice!

0 Kudos
Message 1 of 3
(1,167 Views)
Solution
Accepted by topic author hallo2014

@hallo2014 wrote:

In https://delacor.com/dqmh-documentation/dqmh-best-practices/ a "Private DQMH Request Event" was mentioned, but I didn't fully understand this approach. 


The best practices talk about having a request for the sole purpose of communicating from the MHL to the EHL. When the MHL starts a module, it sends the event references to the EHL so the EHL can update the event registration. This request should not be called from outside the module, so its access scope should be set to private. Taken from the best practices:

 

You can create a Private DQMH Request Event as a regular DQMH Request Event and then move its API VI call to a virtual folder in your Module (configure the virtual folder with private access scope). This is to make it clear to you and others that this Request is intended to be used only within this module and it is not part of the public API as regular DQMH Request event would.

 


@hallo2014 wrote:

Alternatively in a similar case in https://forums.ni.com/t5/DQMH-Consortium-Toolkits/What-is-a-good-method-that-is-used-specifically-fo... it was mentioned that the Main-Module should do all the starting and stopping of modules (but this seems a bit more messy because the Main-Module would need to do much more than I wanted). 


You can implement a tree (or bush 🙂 ) structure with your modules, much as you describe:

 

"Module Main" -> "TestSelection" -> "Test01" - > "A", "B", "C" 

 

In that case, in my opinion, TestSelection should not have to know about A, B, C, and Main should not have to know anything about Test01 or A, B, C. It's each module's concern to take care of its own dependencies.

 

In such a case (and we do that in our projects), Main would only register for the broadcasts of TestSelection. TestSelection only registers for the broadcasts of Test01.

 

If Main needs to know about an error that occurred in A, B or C, then Test01 needs to register for their broadcasts, and then forward (i.e. broadcast) such an error to TestSelection. TestSelection then does the same thing and forwards that error to Main.

 

The advantage of that system is that you have a much finer granularity to deal with errors on the correct level and/or add to or rewrite the error information.

 

Imagine having multiple tests running in parallel - then you'd have multiple clones of A, B and C running. If Main receives an error broadcast directly from a clone of A, it's hard to know which Test actually failed.




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® (The Future of Team-Based LabVIEW Development)


Message 2 of 3
(1,149 Views)

Thank you very much for your detailed reply! 

 

I am very pleased, that I do not have to redo my architecture. The forwarding of the errors looked a bit counter-intuitive to me at first, but it seems to be a valid and easy solution for my problem 🙂

0 Kudos
Message 3 of 3
(1,145 Views)