Which design pattern to use for simple measurement application

[Wuhtzu]

Hi everyone

As the topic says I am hoping to get some help to choose a design pattern for a realtively simple measurement applicaiton.

This is what the application should be doing:

#1: At launch the app will determine if a USB-9211A card is found and if so, determine which device number it is

#2: Some sort of array should then be presented with all the available channels (ch1..ch4) and the user should be able to choose units, thermocouple type and if the channel should be enabled/sampled

#3: Upon pressing a button [Run using selected settings] (or the like) measurement tasks should be setup using the values (choises made by the user) from #2 and the task should be started (measurement started). The temperature values should be displayed on a graph but not stored anywhere except for graphically on the graph.

#4: Upon pressing another button [Start logging] a dialog should ask the user to select a filename and then it shuld start writing temperatures to this file

#5: A [Stop Logging] button should stop the logging

#6: A [Stop] button should stop the whole application.

Even though it would change much I guess, it is no requirement that the "setup channel" array disappears when [Run using selected settings] is pressed. Also to change the settings (type of thermocouples or the like) it is expected that the user restart the application.

I know how to do everything (#1 to #6) by it self in a standalone VI but I do not know which design pattern to use to tie them all together. So that is to say I know how to react to a button press, I know how to write to a file ect. The only thing I do not know is how to unify all this in a single application.

Any ideas?

It should be something asynchroneus in order to respond to the userinterface events. So an "User Interface Event Handler" will not be good since the measurement loop (read from task) will cause other events (like pressing [Start logging]) not to be processed (since the measurement loop runs forever until [Stop] is pressed). "Producer/Consumer Design Pattern (Events)" could be another candidate. I could enqueue events (like button actions) and act upon them in the consumerloop. But again the [Run using selected settings] button should start a continious loop of sampling (for displaying temperatures on the graph, but not logging them just yet). So this would clog up the queue I guess...

Thank you for your ideas!

Best regards

Wuhtzu

[josborne]

I'd probably use a queued state machine. 

And no need for a separate measurement loop.  You can just add a timeout to your User Interface Event Handler so that every X milliseconds you empty your DAQ buffer, etc.

[johnsold]

Whutzu,

The way I see your requirements they seem to have two groups of user interface controls, setup and running.  The setup controls are read when the user completes the setup (at [Run using selected settings]). The others ([Run...], [Start logging], [Stop logging], and [Stop]) require immediate response but do not occur very often. You have a DAQ task (probably slow because it is temperature), a display requirement and a logging (file) requirement.

Asjosborne said you can probably use a single loop.  If you expect that the requirements will change in the future, I might go with a more capable Producer/Consumer (Events) design pattern.  If the DAQ requirement calls for speed, precise timing, or large quantities of data, then I might consider a third loop dedicated to DAQ.

You need to decide on what data structures you need. Do you need separate buffers for display and logging? What is the maximum amount of data to be displayed at any one time? Do you need to be able go go back and display older data? Are all data points displayed and logged when logging is enabled? How may points do you write to file each time?  There are many ways to handle this, but iti is hard to give advice without more information about your application.

Lynn

[Wuhtzu]

Hi Josborne and johnsold

Thank you for your advice. Your ideas about about something like a queued statemachine (maybe with events) doesn't sound bad.

I have however made a quick and dirty implementation disregarding most of my requirements. It uses hardcoded channels, thermocouple types, sample rate etc. It Starts logging as soon as the application is started and when the application is stopped it prompts the user to save the data to a log.

I did this because I realized my original requirements called for a relatively complex designpattern. Something like a queued event handler with some additional loops. So when I get some more time I will be checking this Labview 2012 sample project out:

Continuous Measurement and Logging (Sample project)

http://www.ni.com/white-paper/14116/en

It looks very interesting.

Thanks again

Wuhtzu