QMH Message Management

[FabiolaDelaCueva]

---

@Gregory wrote:

Hi Fab,

I played around a little bit with the DQMH yesterday and was so impressed! The scripting integration was really amazing as well! The only problem I have is that I don't want to get in the habit of using "magical" templates, and I don't understand a lot of the inner workings of the DQMH. I think it offers a lot of functionality and complexity that I have not needed yet, but I know my applications are pretty small. Just wanted to say thanks for putting out such a cool tool, and it's been very helpful to me to learn how to incorporate user events into my smaller projects!

---

Glad you liked it! and that you appreciate the effort we put on creating this toolkit. 

We put this out, because the number one request from new customers who had more than one window running at a time in their existing code was:

I want my app to stop gracefully and I want my app to handle errors.  

All the code in the DQMH itself is not password protected, the scripting tools are, but all they are doing is do the busy work of creating user events for you. I would like to understand more about what part you see as "magical" and we could look into doing a blog post to help clarify that part. I have no problem in us showing you how the magic is done 🙂

If you haven't done so, I invite you to read the Help>>Delacor>>DQMH Help... document, this document is also available from the Create Project menu if you click on "More Information" and a copy of the documentation is also added to your project if you created your project from DQMH project template.

The reason we created the scripting tools for the DQMH is that we found out that people understood the concept of events, but then got lost on all the steps involved in creating a new user event and most of the time they forgot to do things like unregistering for the events or destroying the events.  When both Chris Roebuck and I had used similar architectures in the past, we would always get called to create a new event for others. We also found ourselves more than once forgetting one of the steps!!!  I will list below all the steps involved in creating a new user event, so you can use them as a reference when creating your own user events (which btw, I think they should be called CUSTOM events, but that is another story 😉 more on that here: http://www.walkingthewires.com/2015/07/20/something-happened-events-in-labview/ )

In the case of the DQMH, the scripting steps for creating a new event:

1) Create a typedef for the argument of your event (putting it inside another cluster to ensure that the argument is available via the Event Node when handling the event)

2) Save the typedef in a consistent location in the project, in our case it is inside the Public API for the module under the Arguments virtual folder.

3) Generate the user event in the correct functional global variable (either the one that obtains the Requests or the one that obtains the Broadcasts)

4) Add the user event to the Request Events or Broadcast Events typedefs (this automatically adds the event to the "Register for Events" node in Module Main.vi or the "Register for Events" node in the tester)

5) Add the user event destruction to the Destroy Event Requests or Event Broadcast events 

6) Create the wrapper VI that unbundles the new event, puts all the arguments as required inputs to the VI, and fires the event (or generates an error in the case the event cannot be fired).

7) In the case of a Request Event: Add a place where this new event generation can be tested in the Module API tester with instructions for the developer to follow

😎 Add a place where this new event is handled in the Module Main.vi with instructions for the developer

9) In the case of a Broadcast Event: Add a place where this new event generation can be called from within the Module Main.vi

10) Add a place where the broadcast can be tested in the Test Module API.vi

The creation/destruction of events is owned by the Module Main.vi, because we wanted to ensure that the module itself owned the events references lifetime. This is important, because in the code presented by Justin, the caller was in charge of creating the events and if this VI went out of memory, the events died. We also did this to facilitate the integration with TestStand.

Hope this helps explain some of the "magic" 🙂

Regards,

Fab

[FabiolaDelaCueva]

See, I already forgot one step!

When creating a user event, you need to make sure that the constant used to create it is named! otherwise it doesn't show on the event data node.

hope I didn't forget anything else 😉

[Gregory]

Thank you that was very informative! It certainly does save a lot of time to use your toolkit if events are going to be heavily used in the interprocess communication.

When I want to create a new DQMH project from template, is the Application.lvlib >> Main.vi intended to be the front panel of my application? If not, what is the recommended way to get up and running with a new project the quickest?

[Blokk]

---

@Gregory wrote:

Thank you that was very informative! It certainly does save a lot of time to use your toolkit if events are going to be heavily used in the interprocess communication.

When I want to create a new DQMH project from template, is the Application.lvlib >> Main.vi intended to be the front panel of my application? If not, what is the recommended way to get up and running with a new project the quickest?

---

I join for asking about the DQMH "getting started" 🙂 When seeing a nice template like this, I always feel I would love to see a simple "case study" how to implement it in real world scenario (like from NI the "Cont. acquire and logging" based on the QMH template).

Fabiola, would you consider to create a template usage example, where you show how 3-4 parallel modules interact? I would imagine for example a DAQ+control system, where we would have 3 main modules (and maybe some others???). DAQ could be simulated DAQmx device, the other HW just a dummy subVI with some simulation.

1. DAQ module
2. Control module (for example to control a mass flow controller (MFC) by user + option for auto control based on data from DAQ module) + here optionally show an example, how to proceed if we want to add more MFCs to our system? Use Clonable module? And how?
3. Graph + Data logging module

About the naming of the "User Events", I totally agree 🙂 Very misleading name, the "Custom Events" just would make more sense 🙂

[drjdpowell]

---

@Blokk wrote:

I join for asking about the DQMH "getting started" 🙂 When seeing a nice template like this, I always feel I would love to see a simple "case study" how to implement it in real world scenario (like from NI the "Cont. acquire and logging" based on the QMH template).

---

I actually redid "Cont. acquire and logging" using my Messenger Library framework and added it as a project template.  It was relatively quick to do as I could reuse the subVIs from NI's version.   Also, no need to decide what to impliment as I just copied NI.  It also means one can compare different options, as you can see the same application writen in different ways.  So perhaps Fab should consider redoing "Cont. acquire and logging" as DQMH modules.

[drjdpowell]

---

@Blokk wrote:

About the naming of the "User Events", I totally agree 🙂 Very misleading name, the "Custom Events" just would make more sense 🙂

---

To the C++ programs who wrote the Event system, we're the "Users", hence the name.

[Blokk]

---

@drjdpowell wrote:

---

@Blokk wrote:

About the naming of the "User Events", I totally agree 🙂 Very misleading name, the "Custom Events" just would make more sense 🙂

---

To the C++ programs who wrote the Event system, we're the "Users", hence the name.

---

Ah, I see now why... 🙂 But for me the end-user is the user, who interacts with the GUI... So a programmatically induced event cannot be "User" 😄

[FabiolaDelaCueva]

---

@Gregory wrote:

Thank you that was very informative! It certainly does save a lot of time to use your toolkit if events are going to be heavily used in the interprocess communication.

When I want to create a new DQMH project from template, is the Application.lvlib >> Main.vi intended to be the front panel of my application? If not, what is the recommended way to get up and running with a new project the quickest?

---

Yes, Application.lvlib:Main.vi is the front panel of your application. If you check out the project created, you will see that there is a build specification already included to create an exe and the start up VI is this Application.lvlib:Main.vi.

We used a simple state machine for the Application.lvlib:Main.vi to show that the code calling the DQMH public API can be done using any pattern, it does not have to be another DQMH itself. 

[FabiolaDelaCueva]

---

Blokk wrote:

I join for asking about the DQMH "getting started" 🙂 When seeing a nice template like this, I always feel I would love to see a simple "case study" how to implement it in real world scenario (like from NI the "Cont. acquire and logging" based on the QMH template).

Fabiola, would you consider to create a template usage example, where you show how 3-4 parallel modules interact? I would imagine for example a DAQ+control system, where we would have 3 main modules (and maybe some others???). DAQ could be simulated DAQmx device, the other HW just a dummy subVI with some simulation.

1. DAQ module
2. Control module (for example to control a mass flow controller (MFC) by user + option for auto control based on data from DAQ module) + here optionally show an example, how to proceed if we want to add more MFCs to our system? Use Clonable module? And how?
3. Graph + Data logging module

About the naming of the "User Events", I totally agree 🙂 Very misleading name, the "Custom Events" just would make more sense 🙂

---

Sure!

For NI Week 2015, a customer of ours and I presented on an application we made using DQMH:

bit.ly/fabniweek2015_2

We recently recorded the presentation again, since the recording did not work at NI week, and there is a video in the link above.

If you are short of time, jump to minute 29:51 where I explain the three DQMH modules created for this application: a GUI, a Control Module and a Logging Module

minute 32:39 shows the build specification that comes with the DQMH Project created from Project Template (this demo is also available as a stand alone video on the same page).

minute 34:52 shows creating the modules described above (GUI, Control and Logging).  This demo is also available as a stand alone vide on the same page.

[FabiolaDelaCueva]

---

@drjdpowell wrote:

---

@Blokk wrote:

I join for asking about the DQMH "getting started" 🙂 When seeing a nice template like this, I always feel I would love to see a simple "case study" how to implement it in real world scenario (like from NI the "Cont. acquire and logging" based on the QMH template).

---

I actually redid "Cont. acquire and logging" using my Messenger Library framework and added it as a project template.  It was relatively quick to do as I could reuse the subVIs from NI's version.   Also, no need to decide what to impliment as I just copied NI.  It also means one can compare different options, as you can see the same application writen in different ways.  So perhaps Fab should consider redoing "Cont. acquire and logging" as DQMH modules.

---

Thanks for the suggestion. We are working on releasing a couple of new features for the DQMH toolkit. Once that is done, we will look into doing this sample project.