DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH modules listening to each other's broadcasts

Solved!
Go to solution

In the standard DQMH project, the main.vi in the main application, uses the static event registration (if that's what it's called, I'm not a labview expert) just before the execution enters the do-while loop. Then as the individual modules get launched the event structure inside one of the states of the do-while loop gets dynamically registered with the "current", "fresh" copy of the event ref-num from the module instance being launched. Since when the main application is launched, no other module is running the initial static registration is null, in which case why bother? it is to establish certain registration order? I realize this is more of a labview/events question than DQMH question, but up until DQMH I've never seen or used dynamic event registration before, and I really like it. See attached photo.

0 Kudos
Message 1 of 5
(3,124 Views)
Solution
Accepted by topic author Rafal_Kor

Hey Rafal_Kor,

 

this post might answer your question: https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Helper-loops-for-active-repetitive-tasks/m-p/3.... The whole thread and the blog post mentioned in it might be of interest to you.

 

Cheers,
Joerg

 

Edit: The editor ate up the URL, fixed it.




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 5
(3,115 Views)
Solution
Accepted by topic author Rafal_Kor

It's to define data type.  User Events and Registration refnums and event structures all need defined data types.  The initial event registration code is defining the data types at edit time, even though at runtime none of the events are yet created.

Message 3 of 5
(3,105 Views)

I knew I had seen this topic mentioned before, thank you for bringing up the link. Your explanation in that other post makes sense if I think about it. I am still a little curious about certain "what-if", what if there was no registration present feeding the shift register before the do-while loop is entered into. Wouldn't the internally placed registration (from within the event structure) effectively type define the events, and by the virtue of the shift register, an uninitialized shift register, still allow the event structure to recognize the events intended for registration? I think I might just give it a try just to convince myself that you are indeed correct and that my thinking about this is wrong. 

0 Kudos
Message 4 of 5
(3,084 Views)

No kidding, I've just tried it. It is the darn-est thing. You were right. I was wrong. The uninitialized shift register did not provide the event structure enough information about the events, so any event I declared externally and tried to register for within the event structure simply resulted in broken wire connection. As soon as I placed an external registration for that event and fed that into the shift register... voila... the event structure knew what the event was, that I was trying to register for. Now subsequent to that if I delete the external registration labview seems happy too. This doesn't count however because I had to externally register for the event at least once, otherwise the internally placed registration just wouldn't connect to my user event. I think I'm all set now. Thank you for taking the time.

0 Kudos
Message 5 of 5
(3,080 Views)