DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Registering to broadcast events from many modules

Thanks a lot for such a great toll like DQMH! It indeed speeds up design process and leads to less and less flaws in general system design.

However, I have encountered a slight discompforting issue. I have created a supervising module, which role is to start up a bunch of submodules and communicate with them. Therefore, in my supervising module I need to register for broadcast events from all submodules. By following the convention used to register to own broadcasts, I have placed all "Obtain broadcast events for registration" vis from respective modules public API in initialization line between module admin init and queue creation.

register to events.png

Where all outputs go though "Reg events" block to create event refnums, which then are bundeled in cluster and thrown in "event dynamic registration" terminal of event loop.

Then my problem starts:

There is a request my supervisory module gets, which should start up all submodules. Following exemplary code in tester vi I have created a startup-handler for each submodule like in following snippet:

start submodule.png

where event refnum comes from unbundeled event refnum cluster, and leaves to "bundle" vi which assembles again one big cluster containing refnums from all submodules.

It looks pretty nasty in block diagram and cries for throwing into a subvi. However it is impossible, as refnums have their typedefs in private data of respective libraries, which unables me to greate sub-vi connectors for those.

Is there any elegant way to solve this issue other than having block diagram populated with numberous startup-handlers?

Message 1 of 15
(9,097 Views)

Hi Mike,

Here are the two ways you could do this (well, there are others, but these are the most common). It all dependens if you want the supervisory module to be in charge of launching the other modules or not and when those other modules can be launched.

You can create a DQMH project from Project Template and look at the Appliction.lvlib:Main.vi to see an example where the VI registers to listen to the broadcasts but launches the modules only when the end user clicks on "Start Module" button.

Option 1: Launch modules at the beginning

register for events at Launch time.png

Option 2: Launch modules elsewhere and register just for the events types:

register for events Launch of modules happens elsewhere.png

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 2 of 15
(8,166 Views)

Thanks Fabiola!

I indeed should have checked the project template not olny the exemplary modules.

It makes it a bit easier, but still does not solve the case full. i.e. passing registgerd events refnum to a subvi, where it could be altered. Is there an efficient way to do that? in DQMH case?

I have another tiny question, which, i think, does not deserv own thread: WhyDQMH queue handler wrapper have private accessors? I am in need to monitor message queue length and control timeouts. My initial plan was to create a descendant queue wrapper class, which will allow me to do planned actions, but I have realized, that the wrapper hs private accessors, so my descendant class would be unable to reach private data.  Is there some particular reasoning behind it?

If one would like to contribute to development od DQMH framework, is there a way to join such project?

0 Kudos
Message 3 of 15
(8,166 Views)

_Mike_ wrote:

Thanks Fabiola!

I indeed should have checked the project template not olny the exemplary modules.

It makes it a bit easier, but still does not solve the case full. i.e. passing registgerd events refnum to a subvi, where it could be altered. Is there an efficient way to do that? in DQMH case?

I am sure Darren Nattinger is expecting to see my answer to this. The QMH Project Template that ships with LabVIEW used to have the register for events inside a subVI. I gave him lots of grief about it, so much that eventually in LabVIEW 2015 it got removed from the subVI. I am sure I was not the only one complaining about it, but I might have been one of the loudest

There are mainly two reasons I don't like to have the Register for events inside a subVI:

1) It makes it to easy for a junior developer to branch that wire coming out of that subVI and wiring it to more than one Event Structure. That is trouble, if you have attended an Advanced Architectures in LabVIEW course from NI they have a very good demonstration about it. The Register for Events is creating an event registration engine that handles the events. If no body is registered to listen to an event, the event doesn't get queued in the event queue. For each event registration there is one event queue behind the scenes. When the Event Refnum gets forked it is like having two dequeuers, except it is worse than that! Because sometimes both event structures will get the event and sometimes only one of them will..... tl;dr: DO NOT FORK THE REGISTRATION REFNUM wire

2) The user events names on the event structure are not as descriptive as to when the event registration is on the same VI as where the event structure is.

Now, let's suppose for a very brief minute that I am OK with the Event Registration being inside a subVI... in that case your VI in the image is broken, because you don't have the correct event registration type. If you look at my examples, the event registration has multiple elements, one for each cluster. Yours has only one, it should look the same as the one on my picture, except inside each VI the events will be wired to different elements. Once you do that, you will see why I like to keep everything on the same VI.

I will try to make a video about this soon. You are not the first one to ask about this.

_Mike_ wrote:

I have another tiny question, which, i think, does not deserv own thread: WhyDQMH queue handler wrapper have private accessors? I am in need to monitor message queue length and control timeouts. My initial plan was to create a descendant queue wrapper class, which will allow me to do planned actions, but I have realized, that the wrapper hs private accessors, so my descendant class would be unable to reach private data.  Is there some particular reasoning behind it?

We are evaluating the accessors scope issue, I think you are correct and they should be protected. Expect an annoucement in the following weeks about a new release of the DQMH toolkit to address this issue.

_Mike_ wrote:

If one would like to contribute to development od DQMH framework, is there a way to join such project?

We don't have any plans like that at the moment. We are listening to comments, suggestions, frustrations shared in this forum and directly with us via other means. Let us know how you would improve the DQMH and we will be happy to evaluate including your suggestions.

I hope this helps.

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 4 of 15
(8,166 Views)

Thank you a lot for overwhelmingly detailed and elaborative answer! Great job! It indeed shows details of your concept and allows for clear understanding of reasoning beind it.

I completely agree with your arguments. Mine was more of "esthetic"/code organization type, so I can easily adapt to suggested solutions.

Regarding improvements - in our team we are discussing at the moment what would be the best way to handle project design and implementation with usage of QMH. Our main concern is separation of framework (DQMH) code from particular implementation. We plan to create some document at the end of our talks,, which I will be happy to share with you.

0 Kudos
Message 5 of 15
(8,166 Views)

FabiolaDelaCueva wrote:

_Mike_ wrote:

I have another tiny question, which, i think, does not deserv own thread: WhyDQMH queue handler wrapper have private accessors? I am in need to monitor message queue length and control timeouts. My initial plan was to create a descendant queue wrapper class, which will allow me to do planned actions, but I have realized, that the wrapper hs private accessors, so my descendant class would be unable to reach private data.  Is there some particular reasoning behind it?

We are evaluating the accessors scope issue, I think you are correct and they should be protected. Expect an annoucement in the following weeks about a new release of the DQMH toolkit to address this issue.

One of the new features in DQMH 2.1 is that we made the Message Queue accessors protected so they can be overriden by children.

DQMH Toolkit 2.1 is here!

Hope this helps.

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 6 of 15
(8,166 Views)

Hello together

 

First of all, a big respect. You did a really good framework which is useful to work with.

Unfortunately, I am currently a bit helpless with my issue. I just wanted to dynamic registrate the user events by a call by reference sequence. To debug I just wrote the paths statically. Later on, they should be executed before. But due to the events in the module are different I got an error as soon as the number of events is incorrect. Is there a way to set the VI-ref path?

 

br Markus

0 Kudos
Message 7 of 15
(7,069 Views)
Hi Markus,
 
Looking at the image you posted, it appears you are using the Obtain Broadcast Events for Registration before the Start Module.  The  Obtain Broadcast Events for Registration only contains the datatype when the module has not started yet.  We recommend you use the output from the Start Module for the registration, so you are assured the correct dataflow.
 
Please see item 6 on this documentation page:
 
 
Let us know if this fixes your problem!
 
 
0 Kudos
Message 8 of 15
(7,060 Views)

Hello again

Thanks for the really fast response.

Unfortunately, the idea with executing the start.vi and register the event does not solve the issue. The issue is that the BLE-Module from where the type specifier is made loads correctly. But the other modul (Resultfile) hits the error 1031. The same behaviour is made by changing the typedef. I am relatively sure that the connector pane is identical. Only the to be registered events are different. Is that the reason why it won't work with this setup? Or how can I setup type specifier dynamically?

 

br Markus

 

Below the error log:

 

 

Error 1031 occurred at Open VI Reference in ApplicationMaintain.lvlib:Main.vi

Possible reason(s):

LabVIEW:  VI Reference type does not match VI connector pane.

VI Path: C:\rep\111240700_AllStarConnect_Rapid_EOL_TesterSW\trunk\HighLevelDriver\Resultfile\Start Module.vi

0 Kudos
Message 9 of 15
(7,047 Views)

Markus, I don't think that there's a way to do what you are describing (setting the type specifier dynamically). Also, you write that the connector pane is identical when in fact it might not be, as each Start Module.vi has its own typedef'ed cluster of broadcast event references. 

 

There is a way to load DQMH modules dynamically, though. We do that for our DQMH-based windows applications. Each DQMH module gets a few "wrapper VIs" with identical connector panes to encapsulate all those module-specific VIs. These wrapper VIs can then be called dynamically.

 

First, each DQMH module has a wrapper VI that encapsulates the Start Module.vi and the Synchronize Module Events.vi which we load dynamically:

load.png

 

Then, there's another wrapper for each DQMH module that only returns the generic broadcast event references (those that every module has to have). We call that dynamically and can thus collect all "generic" broadcast references of all loaded modules:

ref.png

 

Does this help or answer your question?

 

Cheers,

J.




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 10 of 15
(7,040 Views)