02-04-2013 01:33 PM - edited 02-04-2013 01:34 PM
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:
Error Handling |
Event Handler |
Below is a diagram of the inter-process communication.
Queue User Event Notifier Messages have a thin line Data flow has a bold line |
Acquire |
Process (Plug-In) |
Log |
Display (SubPanel) |
Coordinate |
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).
2.1.
2.2.
2.3.
2.3.1.
2.3.1.1.
2.3.1.2.
2.3.1.3. Error Handling talks to the Event Handler using User Events. Error Handling located in all processes.
Fires an Exit program if receiving an error.
2.3.1.4. Event Handler talks to the Coordinate using a Queue.
Configure logging.
Start logging.
Stop logging.
Change display.
Change processing type.
Exit program.
2.3.1.5. Coordinate talks to Acquire using a Queue.
Initialize.
Run. (Begin task)
Stop. (Stop running task and clear task)
Exit process.
2.3.1.6. Coordinate talks to Log using a Queue.
Initialize.
Run. (Begin data logging)
Stop. (Close file)
Exit process.
2.3.1.7. 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.
2.3.1.8. Coordinate talks to Process using a Queue.
Choose algorithm. (Fire process in menu ring).
Exit process.
2.3.1.9. Acquire talks to Process using a Buried Queue.
Pass data.
2.3.1.10. Process talks to Log using a Buried Queue.
Pass data.
2.3.1.11. Process talks to Display using a Buried Notifier.
Pass data.
02-05-2013 10:54 AM
Bump.
Is there anything I could add to make this less confusing? Sorry, MS Word was acting up.
02-05-2013 05:03 PM
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?
02-05-2013 06:40 PM
Will do in the A.M. Thanks.
02-06-2013 06:29 AM
The Error Handling code is located within each submodule and fires via an Event Structure.
02-06-2013 05:49 PM
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.
02-06-2013 06:53 PM
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.