cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

QMH Message Management

QMH Message Management

When designing anything other than a quick proof of concept application, I try to stick to the QMH. Normally, there are four loops: One with an event structure for handling UI input, one main control loop for distributing messages & data, one for hardware control and one for programmatic UI updates. For ease of explanation, let's assume these loops are numbered in the order in which they were presented above (event structure loop = 1, main control = 2, H/W control = 3, UI update = 4).

 

Every user action first goes through loop 1 and is then passed to loop 2. From there it is distributed to 3 and/or 4. There are some instances where a user action goes 1-2-4 with nothing really happening at 2 except passing the data straight to 4. While I am tempted to send the data straight to 4 from 1, my gut's telling me to stick to the design pattern and always distribute through the main control loop. I guess the ultimate goal of this would be code readablity--a dependable data flow paradigm.

 

I'd like to know your thoughts on the issue. Would you pass straight the data straight to loop 4?

0 Kudos
Message 1 of 33
(2,117 Views)

Re: QMH Message Management

I would pass the data straight to 4. You're wasting CPU cycles dequeuing/re-enqueuing the data and adding complexity by having a case that doesn't really 'do' anything.

 

In applications like this (similar scale/complexity), I tend to create all of my queues during the application initialisation, bundle them together into a type-def and then pass that cluster into each loop. You can then address each loop from anywhere in the application.

 

Of course, if at some point you were to remove 4, or perhaps you had a 4-lite, then it might make sense to keep it in your control loop so it makes more sense where to change/add the additional enqueue.

 

Design patterns are just that - patterns - sometimes you'll need to add to them/modify them to suit your application. When glancing at the code, it should be obvious what architecture you're using (e.g. QMH).



Certified LabVIEW Architect (CLA), Certified LabVIEW Embedded Systems Developer (CLED) and Certified TestStand Developer (CTD)
MediaMongrels Ltd. - NI Alliance Partner | GDevCon :: 4-5th September 2018 :: Cambridge, UK
0 Kudos
Message 2 of 33
(2,087 Views)

Re: QMH Message Management

I disagree with Sam. In my discussions on the QMH I refer to loop 2 as the "marshalling" loop. Its primary job is to distribute messages to loops that need to hear them. Unless you are dealing with an extremely high throughput application where CPU cycles are critical, keeping all message marshalling centralized in one place really does improve the readability of your code, and helps prevent race conditions down the line, where there could be N different places that might be sending messages to a particular loop...things are a lot easier to understand and debug if there is one centralized location that distributes messages.

 

I discuss this topic in my 'Decisions Behind the Design of the Queued Message Handler' presentation, which you can view here.

DNatt, LV R&D
0 Kudos
Message 3 of 33
(2,074 Views)

Re: QMH Message Management

I think Darren and myself have expressed the two opposite ends of the spectrum!

 

There are many situations where I have done as Darren describes (I have a medium application where I have a centralised 'message broker' which sends setpoint update messages to various different hardware modules) but in other situations I do as I first alluded to - cut out the middle-man and send the message directly.

 

I hope Darren at least agrees that neither answer is 'wrong' and there are pros/cons to each - the main thing is to document what you do so that it helps you to understand it later.



Certified LabVIEW Architect (CLA), Certified LabVIEW Embedded Systems Developer (CLED) and Certified TestStand Developer (CTD)
MediaMongrels Ltd. - NI Alliance Partner | GDevCon :: 4-5th September 2018 :: Cambridge, UK
0 Kudos
Message 4 of 33
(2,049 Views)

Re: QMH Message Management


@Sam_Sharp wrote:

 

 

I hope Darren at least agrees that neither answer is 'wrong' ...


Hey, there are plenty of people who thing global variables are 'wrong', but I like them. Smiley Wink

 

So yes, abide by general rules when you can, but document your code when the exceptions come up. The general rules are there to keep you from shooting yourself in the foot. If you know what you're doing, sometimes the rules can be bent.

DNatt, LV R&D
0 Kudos
Message 5 of 33
(2,040 Views)

Re: QMH Message Management

Combine 1, 2, and 4 into one loop and you'll be readable, resistant to race conditions, AND eliminate a lot of message passing.  

0 Kudos
Message 6 of 33
(2,003 Views)

Re: QMH Message Management

I just use User Events instead of queues.  Then each loop registers for the events they care about and everybody will get their own copy of the message.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 7 of 33
(1,981 Views)

Re: QMH Message Management


@crossrulz wrote:

I just use User Events instead of queues.  Then each loop registers for the events they care about and everybody will get their own copy of the message.


Is there a thread where you discuss this in more detail?  I always wanted to learn how to do this...

 

Thanks!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 33
(1,970 Views)

Re: QMH Message Management


@billko wrote:

@crossrulz wrote:

I just use User Events instead of queues.  Then each loop registers for the events they care about and everybody will get their own copy of the message.


Is there a thread where you discuss this in more detail?  I always wanted to learn how to do this...


The Delacor QMH implements inter-process communication with user events. It's a robust framework that builds upon the NI QMH, so it should feel pretty familiar to QMH users.

 

DQMH Intro videos

DQMH download (free on the LabVIEW Tools Network)

DNatt, LV R&D
Message 9 of 33
(1,933 Views)

Re: QMH Message Management


@Darren wrote:

@billko wrote:

@crossrulz wrote:

I just use User Events instead of queues.  Then each loop registers for the events they care about and everybody will get their own copy of the message.


Is there a thread where you discuss this in more detail?  I always wanted to learn how to do this...


The Delacor QMH implements inter-process communication with user events. It's a robust framework that builds upon the NI QMH, so it should feel pretty familiar to QMH users.

 

DQMH Intro videos

DQMH download (free on the LabVIEW Tools Network)


I am familiar with QMH.  I can't wait to check out the vids and stuff.  I think I have some idea of how it works.  It will be very interesting to see how far off I am.  Smiley Wink

 

Thanks!  Kudo!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 33
(1,914 Views)