What is the Fastest producer consumer method. Queue, RT-FIFO, Event

[Ledang]

Hi,

I’m developing a system to produce tomogram image based on tomography principles to visualise in real-time concentration profile of water and gas. The system consists of 16 capacitance electrodes and impedance electrodes. During operation these sensors are activated alternately in such to avoid mutual inteference. My problem is to produce the tomogram image, I need to use algorithm and probably regularization methods to improve the sensitivity and quality of image being produced. Before this I developed a GUI (LabVIEW) and I found that the process of acquiring measurements and algorithm processing was time consuming. For your information all the acquire and processing had been done in serial manner (single VI). From my observation the problem comes from the algorithm processing.  If I want to implement parallel programming (i.e producer/worker) does this method would improve the processing time? Or should I considered a high-speed data acquisition card for this purpose? Should I use the C programming with LabVIEW as well? For your information I’m using 250kS/s NI-USB 6218.Hope you could give me some ideas on this.

Thank you

Fazlul

[DFGray]

Your question does not really relate much to this thread.  You will get a better response if you post a new topic.  For a quick answer to your questions:

1. A high speed data acquisition card may or may not help you.  It depends upon the response time of your sensors and the system under test.
2. Consider measuring your sensors in groups of two, four, or eight instead of one at a time to increase throughput.  Check your data and see how orthogonal the measurements are.  You should be able to do the orthogonal ones simultaneously.  Another thing to think about is that even if they are not orthogonal, the interference/cross talk may be useful in your tomographic analysis.
3. You definitely want your analysis and acquisition in separate threads.  In LabVIEW this means separate loops.  This can be in the same or different VIs.  Communicate between the loops with queues.  Also, if your analysis is parallelizable, you may want to check out one of the newer features of LabVIEW, which allows FOR loops to be parallelized based on the number of processors available.  See the FOR loop documentation for details.  This could give you a lot of speed.
4. Algorithmic efficiency is usually the key to success.  Find a good algorithm and the programming language should not make that much of a difference (factor of 2ish for programming language, factor of 10 to 100 or more for algorithm - I have implemented a factor of 100,000 by changing algorithms).
5. In my experience, it is much easier to do the data acquisition in LabVIEW than C.  Parallel processing is also easier in LabVIEW than in C.  However, you can sometimes get more processing efficiency in C than in LabVIEW due to better compiler optimization.  Unless there is a very good reason, I tend to stick with one programming language for any project.  Note that I am biased since I am an NI employee, although I used NI equipment for many years before joining.