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:
Below is a diagram of the inter-process communication.
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).
18.104.22.168. Error Handling talks to the Event Handler using User Events. Error Handling located in all processes.
Fires an Exit program if receiving an error.
22.214.171.124. Event Handler talks to the Coordinate using a Queue.
Change processing type.
126.96.36.199. Coordinate talks to Acquire using a Queue.
Run. (Begin task)
Stop. (Stop running task and clear task)
188.8.131.52. Coordinate talks to Log using a Queue.
Run. (Begin data logging)
Stop. (Close file)
184.108.40.206. Coordinate talks to Display using a Queue.
Choose figure. (Choose proper plot/table to display based on user selection)
220.127.116.11. Coordinate talks to Process using a Queue.
Choose algorithm. (Fire process in menu ring).
18.104.22.168. Acquire talks to Process using a Buried Queue.
22.214.171.124. Process talks to Log using a Buried Queue.
126.96.36.199. Process talks to Display using a Buried Notifier.
Is there anything I could add to make this less confusing? Sorry, MS Word was acting up.
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?
Will do in the A.M. Thanks.
The Error Handling code is located within each submodule and fires via an Event Structure.
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.
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.