DQMH - Communicating between modules of different projects

[Jguglielmo]

Hello everyone, 

I have been working toward moving many of my lab automation drivers over to DQMH and have just run into an issue in allowing modules from different .lvproj's to communicate to eachother (or at least I *think* that's the problem). Take 3 simple functions illustrated below. Each function is in it's own .lvproj. My intention is to have the Data Analysis portion listen for broadcasts from the two data sources (DMM and ADC) so that it can operate on each source's data asynchronously. 

Solutions attempted:

1. Because the DMM and ADC modules are not started by the Analysis module, I first tried to simply use the public "obtain broadcast events for registration" method at the initialization of the Data Analysis module.  I recognized that the modules from which to obtain broadcasts may or may not have been started at the time of obtaining/syncing broadcasts so there was a chance I would not get valid references to the events. Not only was this not robust, it never actually worked, even if I knew the DMM or ADC modules were running.  So I dug deeper...
2. The last two paragraphs in the link below helped me understand that I can still register for events of modules not running and can also "start" a module even if it's already running so as to take the traditional approach of start, register for events, sync events.  I was certain that this was going to be the solution but I still am not able to respond to the broadcasts from the DMM or ADC modules.  I have verified that my testers see the broadcast, but for some reason I can not get the Analysis module to see it. https://dqmh.org/rsvp-how-we-do-event-registration/

I attached 2 of the projects.  To understand my current attempt, see:

1. "Capture Measurement" within the MHL of the 3458 Driver for the broadcast.  
2. "DMM Listener" in the Test Studio Project.  See the "Start" case in the EHL for how I am registering. 

NOTE: these two projects are solely proofs of concepts that I put together in about an hour so be easy on me 😉

Thank you!

[Gregory]

Hi Jguglielmo,

I think you'll want all of your modules in the same project, so that when you build an executable they can still "see" each other.

[Jguglielmo]

Hey Gregory,

Thanks for the response - I had a feeling that was going to be a recommendation and unfortunately wish it weren't so. Mixing these projects will make for a mess.  In reality, I am going to have 10+ instrument drivers that are being communicated too and from.  For sake of maintenance and simplicity, it really feels like these should all be separated. Maybe there is another "bundling" option that I am missing? I have no plan to build executables.  

Jared

[Gregory]

I would treat it the same way I treat other instrument drivers / re-usable code.

I tend to have a "source-controlled version" that I copy to other folders and LabVIEW projects.

You could also have them installed in a central location, like how LabVIEW's instr.lib works. And then you can use those libraries (DQMH modules) in as many projects as you'd like.

[rolfk]

Each LabVIEW project is its own independent application context and Refnum objects are only valid in the context they were created. You should treat them as if they were in different executables so you would need interapplication communications such as TCP/IP to communicate between them or use a single project for the whole.

[AlexElb]

We have implemented network communication to make DQMH modules on RT talk to DQMH modules running on a Windows PC. It is open source, so you could give it a try. Please reach out directly to us for support.

You can find more information in our Dokuwiki:

https://dokuwiki.hampel-soft.com/code/dqmh/generic-networking/overview

[Yamaeda]

Network published variables should work, or check out RabbitMQ.