Sharing/reusing messages between DQMH plugins

[McQuillan]

Hey All,

Context:

I'm writing a new user interface that contains lots of subpanels. Each nested UI is a VI in a PPL (called by reference / launched asynchronously) that can communicate to/from the main user interface using user-events.  I decided to use user-events instead of queues because I want the modules to be able to run independently, and while queues need to be dequeued, user-events don't care if anything is registered to listen to it.

When writing this framework, I realized I was re-writing DQMH modules (without all the benefits...), so I've decided to learn how to use DQMH properly.

This issue:

I want to make the UI and all the subpanel UIs work as a plug-in architecture, and to have all the related plugins share messages. I'm coming at this as a heavy AF user, where I would just inherit from an abstract actor that defines the messages. In my current UE based framework, I solve this issue by sharing the UE refs with the plugins and it works fine. But if possible I want to use DQMH because it's complete with scripting and testing.

I want it so 'DQMH Actor A' can talk to any other actor with a common interface, without Actor A knowing who exactly it's talking to. Make sense?

Question: Is it straightforward to share messages between related modules using DQMH? If so, how?

[joerg.hampel]

Hey Tom, I think you'll have more luck with answers in the dedicated DQMH forums.

There's a recent thread about dynamically registering broadcasts and requests, maybe that is of interest to you?

Also, I fear that there is no easy way in DQMH to accomplish this in the same way that you're used from AF. But Fab might wanna chime in here...

[FabiolaDelaCueva]

Hi Tom,

Thanks for checking out DQMH. As Joerg mentioned, you may have more luck getting answers on the DQMH forum. His DQMH templates have some clever implementations that may help you.

For subpanels, you may want to check out the MGI Panels package, they have a DQMH module template, although you will have to validate it (via the LabVIEW Tools>Delacor>DQMH>Module>Validate Module... tool) and bring it up to the latest DQMH version. There is a lot of subpanel management done there. The package is available in the Tools Network and you can find it in VIPM. 

Several other options to investigate further:

• The arguments for DQMH events can be anything, so you could make the argument a class and share this class among different DQMH modules
• You can wrap a DQMH module in a class. Your constructor would call the Start Module.vi and the Synchronize Module Events.vi, your destructor would call the Stop Module.vi. Check out how we did it for the Delacor Test Sequencer, look at tip 5 on this blog post https://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/

I hope this helps.

Thanks for your trust in DQMH.

Regards,

Fab

[drjdpowell]

---

@McQuillan wrote:

I decided to use user-events instead of queues because I want the modules to be able to run independently, and while queues need to be dequeued, user-events don't care if anything is registered to listen to it.

---

Side note, but this isn't a reason to use User Events over Queues.   A User Event is analogous, not to a Queue, but to an Array-of-Queues.  A User Event with nothing registered to it is the same as an empty array of queues, which doesn't require any dequeuing.  

[mcduff]

---

@drjdpowell wrote:

---

@McQuillan wrote:

I decided to use user-events instead of queues because I want the modules to be able to run independently, and while queues need to be dequeued, user-events don't care if anything is registered to listen to it.

---

Side note, but this isn't a reason to use User Events over Queues.   A User Event is analogous, not to a Queue, but to an Array-of-Queues.  A User Event with nothing registered to it is the same as an empty array of queues, which doesn't require any dequeuing.  

---

Think the OP is referring to the case of having an independent module which may send out messages to other modules. The independent module does not need any messages from other modules to run correctly.

In this case, a queue sending out messages that aren't dequeued would eventually run into memory problems. For user events, the listener is decoupled from the transmitter, so sending out messages that aren't listened to does not lead to eventual memory problems.

mcduff

[drjdpowell]

Yes, that's exactly what I thought the OP was talking about.  But I think there is a problem with the common mental model people have to think of "User Events" which actually makes them harder to understand.  If instead one thinks in terms of the Event Registration refnums, which are a type of queue, then much of the mental difficulty of "Events" disappears.  You can recreate the features of a User Event with something like a DVR or some similar thing containing an array of queues.  On initial creation, the array is empty, and thus messages can be "sent" even though no one is "listening".

[McQuillan]

Thanks for cross-linking joerg.hampel the HSE's framework looks really interesting and something I might pull ideas from there when developing (crediting where appropriate as per the license).

Hey FabiolaDelaCueva, I'll have a look at MGI's subpanel toolkit, I've used their AF subpanel toolkit before which was really helpful in a few projects. Assuming their DQMH toolkit has the same functionality as the AF one, I'm not sure it'll fit my architecture. But definitely worth knowing about for future projects.

I had thought about wrapping the messages into classes. However, with this project, I'm attempting to use/learn about other tools/frameworks 'as-is' as opposed to using AF for everything - and I fear if I start using object messages, I may as well use AF.

As this is the first project in a couple of years where I'm attempting to use alternative tools to AF, I think I need to re-evaluate whether I 'need' the dynamic-nature that comes with an architecture using AF - or whether I'm just used to it.

OH! LabVIEW Graphical Programming (fifth edition) will be arriving today! I'm looking forward to learning about all the things I didn't realize I didn't know!

Hi drjdpowell and mcduff, perhaps my original post was unclear, so thank you for clarifying. From reading your posts, I think it's safe to say we're in alignment regarding user events.

It's a nice coincidence that you commented drjdpowell, over the weekend I was thinking about your messenger library. From demos I've seen, I think it could be a good fit for something I'm working on. This week or next, I'll look at the YouTube videos you have on it and have a go using it 🙂

[FabiolaDelaCueva]

---

@McQuillan wrote:

...I'm attempting to use/learn about other tools/frameworks 'as-is' as opposed to using AF for everything - and I fear if I start using object messages, I may as well use AF.

---

Go ahead and use DQMH as is, please keep in mind that you can create your own custom DQMH modules. As you find things that you would have done differently, make a note or see if you can deviate from the original DQMH module template. Eventually, you can create your own DQMH Module Template. That is what Joerg did.

Also, DQMH 5.0 Beta is available as a limited release, we will be opening it to everyone soon. If you would like to give it a try sooner than later, send me an email and I will get you set up with DQMH 5.0.

Regards,

Fab

[drjdpowell]

A note on messages and objects.  There are message objects, that I seldom use, and objects that can be passed in messages but have a lifetime longer than one message pass.  Think "data set", "job", "test step", or "test result" objects that might be passed along a chain of modules/actors.  These would have multiple methods, not just the "Do" method of AF message objects.  No Actor Framework need not mean no objects in messages.

[McQuillan]

Hey James,

Thank you for your advice, it's good to keep that in mind as I see myself using that design pattern later on once this project evolves. By "I may as well use AF", I was in the mindset of if I'm using OOP then I may as well revert to my comfort zone of AF - which so far I haven't done! 😉

Hey Fab,

Thanks for reminding me about DQMH templates, over the last few days I've realized it's not a msg interface I specifically want, it's the ability to be lazy - I just had the AF mentality. I "think" I've solved it by creating a project template* that has 7 DQMH modules that work together (but each plugin could have more or fewer modules) to make a complete plugin for a large project I'm working on.

*The project template idea was from a recording of your NIWeek presentation last year. You mentioned module templates, then said if you have multiple modules working together we could make a project template - That was the light-bulb moment! 

So now when I want a new plugin, I can create a new project from a template, change the user interfaces, change the "business logic", append some local messaging, and build it. It will then integrate with the root UI and all its subpanels with no extra work. 😄

 - Best of all, each of those ~7 actors can be run individually (tree hierarchy), and they all have testers... #bliss

- I haven't yet tried out the DQMH Unit Test Template for each event, that'll be coming soon I think.

I'll DM you regarding 5.0 🙂

Thank you everyone,

Tom