06-01-2010 03:17 AM
Hello everybody.
I'm quite a newbie in Labview (2009 on WindowsXP).
Here is what I want to do :
1) acquire Raw datas continously from DAQmx (typically one digital channel, 500 KS/s)
2) "decode" them on the fly, continously too, and store the datas on hard disk.
3) process the decoded data, like display them, compute for example sliding average, PSDs, PDFs, etc...
I want to have all those tasks to be done inside a program one could build, so it need a good GUI : user must just run the main VI and then select what to do (and not changing values, run the program, stop it and re run it with different values like I usually do).
My first attempt was to do nearly everything in the same VI, using a producer/consummer pattern with a queue to acquire (producer) and decode (consummer). The result is working but clearly it is a nightmare to read and add a functionality.
So I try to make a more readable program.
To do so, I use a lot of multiple subVIs, each one of them dedicated to do a generic task (initialize the GUI, Initialize the DAQ card, etc..) and a main subVI with the Producer/consummer loops inside.
There is a lot of parameters to give to subvis and I want the subVIs to refresh indicators from the main VI, I create references for each cluster or indicators, and pass a big cluster containing them to every subvis.
My question is what is the best way to do my tasks ? Is the design pattern I use last the good way ? Is there any better solutions ?
As you could use state machines, global variables, event structures, etc... It is not clear to me what would be the most effective and readable solutions.
For example, refresh a graph of a main VI from a sub VI using reference and writing inside the Value property node of the reference is a good thing ?
I didn't find any example of large program in labview and I have no idea about effiency of the choices I made at this time...
If someone has made something similar or have some clues to share I would greatly appreciate !!
Thank you for reading my poor english and help me !!
06-01-2010 04:39 AM
Hey YoannBB,
First of all I want to give you some usefull links for large application design like Large Application Development with NI LabVIEW and NI Community - Large LabVIEW Application Development . I hope you will find some hints and answers there too.
Out of your description you have a userinterface with extensive processing, a data acquisition, some data analysis and file I/O.
Now for main design pattern I agree with you in using a producer consumer design pattern.
I see at least three parallel task there, the first task would be the user interface, where you should use a Event Structure. This is also the producer loop and youl will need a queue to pass the commands to the other loops, let's call it command queue.
The next task would be the data acquisition. Out of your description I'm not sure if you need to change some configuration on the fly. If so you will need to integrate that in the command queue. You will also have a second queue there with your data filled from the daq, let's call this one data queue.
And the next task then collects the data from the data queue, does the analysis and the file I/O.
You might need to use a very efficient file I/O technique like binary or tdms. For tdms there are also plugins available to download for opening it directly in MS Excel.
Some things you need to think about to will also be how to initialize the application and how to do the error handling.
Please see this as some hints from my pesonal side. Other useres here my come up with their suggestions or additional stuff.
If you have any questions feel free to post back.
Thanks,
Christian
06-01-2010 05:47 AM
Producer/Consumer architecture is right choice as u have decoupling of process and parallel operation.. i have just small suggestion.. it is ok to have sub VI with generic task including like initilize, decode, compute/analyse, data store and finish.. then u call such these sub VIs on main VI designed with producer/consumer architecture .. using too much refrence is not gud as per memory is concern..