Showing results for 
Search instead for 
Did you mean: 

Using QDMH for Continuous Operations?

After just attending the Advanced Architectures course, I learned about the Queue-Driven Message Handler (which is not the same as the Queued Message Handler...).  I am designing the architecture for a new program I'm working on, and, while I would like to incorporate this architecture into my current program, it just doesn't seem to play nicely with continuous measurement and data logging.


My process needs to acquire data, process that data (using a plug-in architecture), and pass that data to logging and display.  The QDMH seems to thrive for spawning asynchronous VI's that run continually or for doing periodic checks on other processes, but I am seeing that it is lacking for a continuous applicaiton that needs to pass data through a stream (acquire-process-log/display).  I am still learning about assembling more advanced programs. 


I have pasted part of my design document below (sorry, but for some reason the figure won't post correctly.  I can try to post a different way if that is necessary for help.)  Any thoughts would be great.  Thanks in advance.




1.1.1.  There are five processes for this software.  They are:

  • ·       Coordinate actions of other processes
  • ·       Acquire the data from the instrumentation
  • ·       Process the data
  • ·       Log data to disk
  • ·       Display the data on the front panel

Error Handling

Event Handler

Below is a diagram of the inter-process communication.


User Event


Messages have a thin line

Data flow has a bold line




























1.1.2.  This paragraph discusses the communications needed between processes.

A Queue/Notifier is a standard Queue/Notifier passed by wire.

A Buried Queue/Notifier is a Queue/Notifier that is fired in one location and read in another location (without direct wire passing).

  1. 1.         
  2. 2.         




2.3.1.           Error Handling talks to the Event Handler using User Events.  Error Handling located in all processes.

Fires an Exit program if receiving an error.        Event Handler talks to the Coordinate using a Queue.

Configure logging.

Start logging.

Stop logging.

Change display.

Change processing type.

Exit program.        Coordinate talks to Acquire using a Queue.


Run.  (Begin task)

Stop.  (Stop running task and clear task)

Exit process.        Coordinate talks to Log using a Queue.


Run.  (Begin data logging)

Stop.  (Close file)

Exit process.        Coordinate talks to Display using a Queue.

Choose figure.  (Choose proper plot/table to display based on user selection)

Run figure.

Stop figure.

Exit process.        Coordinate talks to Process using a Queue.

Choose algorithm.  (Fire process in menu ring).

Exit process.        Acquire talks to Process using a Buried Queue.

Pass data.    Process talks to Log using a Buried Queue.

Pass data.    Process talks to Display using a Buried Notifier.

Pass data.


Nathan - Certified LabVIEW Developer
0 Kudos
Message 1 of 7



Is there anything I could add to make this less confusing?  Sorry, MS Word was acting up.


Nathan - Certified LabVIEW Developer
0 Kudos
Message 2 of 7

Hi Nathan,


It looks like you tried to post a flow diagram of some sort; I'm having difficulty interpreting what steps/parts of the architecture you have questions about.  If it's possible, could you post a screengrab of the diagram as you see it in Word?


0 Kudos
Message 3 of 7

Will do in the A.M.  Thanks.


Nathan - Certified LabVIEW Developer
0 Kudos
Message 4 of 7

Diagram.gif  The Error Handling code is located within each submodule and fires via an Event Structure.


Nathan - Certified LabVIEW Developer
0 Kudos
Message 5 of 7

While I'm not completely sure of your application, your architecture seems pretty reasonable.  The only suggestion I can think of is just to be aware of the coupling between the acquire, process, log, and display processes.  Maybe make sure that the process is robust enough to handle one of the acquire/log/display steps aborting or becoming unresponsive.

Message 6 of 7

Thanks for the help.  Yeah, I hate having to couple those systems, but it's hard in a continuous measurement/processing/logging application to avoid those kinds of coupling.  I'll try to make sure my error handling routine is robust like you say.


Nathan - Certified LabVIEW Developer
0 Kudos
Message 7 of 7