From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Registering for multiple broadcast events when modules not running

Solved!
Go to solution

Hello!
 
Right now, I'm working on my first project using the DQMH and ran into a problem I’m not sure how to solve.
 
Let’s say we have a singleton module called “Test Manager”, one called “Logger” and one cloneable called “Test Runner”. The Test Manager and Logger are started by the main application. The Test Manger is then starting up to 40+ Test Runner modules which are performing long term tests on different motion controllers. Each Test Runner is testing one device but all devices running different test scenarios.
 
The Logger should now register for the “Status Update” broadcast events of every Test Runner and that’s where I ran into some problems. I did a lot research in the forums and all the documentation and found quite a lot of threads with similar but still different problems.
 
The Logger is using the “Register for Broadcast Events.vi” of the Test Runner module to get the event refnums but if no Test Runner is actually executing when doing this, the broadcast events are not fired inside the EHL of the Logger.
 
I found this example https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Registering-to-broadcast-events-from-many-modu... which is the way I do it right now (option 2). I’m not sure how to do this the right way. The Logger must start before the Test Runner so how do I get all the broadcast events from the Test Runner modules inside the Logger module?
 
Best regards

0 Kudos
Message 1 of 6
(2,851 Views)
Solution
Accepted by topic author Jens_S

The "Test Manager" could let the "Logger" know when it starts the "Test Runner(s)". The "Logger" can then (re)register for the broadcast events of the "Test Runner(s)".

 

Seeing as the cloneables share the same event references, the "Test Manager" can either just notice the "Logger" whenever a "Test Runner" is started, or you could put some logic there to only send the notification for the first clone that's instantiated.




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 6
(2,833 Views)

Agree with Joerg.  

 

If the Test Runners are dynamically being launched throughout the duration (and not all at the start), either the Test Manager needs to keep letting The Logger know of this. 

 

Or just have The Logger independently and periodically check for new registrations.

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Message 3 of 6
(2,815 Views)
Thanks for the quick response!

Oh I’m surprised that it’s that easy :)…. but to let it get me straight.
 
When registering for the broadcast events and the module is not running, all I get is some kind of a null reference. I can then use the events in my EHL but they aren’t bound to something.
When I start the module then these references point to the actual module and the reference is then shared between all the instances of the cloneable module. So, this is why it is enough to reregister for the events because all share the same reference?
 
Letting the Test Manager inform the Logger seems the most logical way to me so thanks for this!
0 Kudos
Message 4 of 6
(2,800 Views)

Maybe you'll find the article on Helper Loops interesting, and also this specific post that talks about this stuff...




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)


0 Kudos
Message 5 of 6
(2,787 Views)

Thanks! Thing I got it 😉

0 Kudos
Message 6 of 6
(2,775 Views)