LabVIEW
pipeline daqmx read task in a while loop
Hi guys,
My task is to output recorded sounds after certain signal processing, i.e. a real-time task. This is a routine task and many people are working on it. It is not difficult to make a Labview program for these tasks. However, the really challenging part is how to achieve a mimimum delay between ai and ao task. The NI engeener suggested me to go for Producer/Consumer design. After searching online, I found a really nice example called " DAQmx Generate Acquired Data with Queues" (https://decibel.ni.com/content/docs/DOC-7202).
Using queues, I am able to reach a minimum ai-ao delay of about 5 ms, which is 4-5 times faster than seqential programming without using queues. This is because my machine is 4-cored processor and with PXIe bus conections. However, my project requires a even smaller ai-ao delay, which should be about 2 ms.
After reading more about multicore programming, I found another example illustrating the idea of combining queues and pipeline (http://www.ni.com/white-paper/5899/en/). In Figure 10, the second while loop use pipeline to improve the efficiency of signal processing. This might be helpful if the DSP part is computingly heavy, which is not my current situation. Since 5 ms of delay is fairly short already, my best guess that this 5 ms delay is caused by the data producer while loop. Particularly, the daqmx read function. Thus, I am wondering whether it is possible to apply the pipeline idea for the daqmx read task. Obviously, simply combining mulitple daqmx read causes errors.
I have snapshot my program so experts can have a better understanding of my problem. I also hope you guys can have ideas on how to reduce the ai-ao delay further. I would very much appreciate it.
... and when you post a picture (but not a LabVIEW Snippet) of a large VI, you'll get scolded by the Resident "Attach Code" Nag (that would be me).
Please attach the VI (or, if multiple VIs, zip them together in a compressed folder and attach the Zip file), itself. Large VIs are difficult/impossible to see when reduced to fit the Forum. Also, we can't see the not-shown cases of Case statements, can't look for wiring mistakes (by jiggling the wires), can't edit the code, and can't try executing the code.
With actual code, we can poke, prod, test, and maybe be helpful quickly (we need to be quick, given what we are being paid to do this -- if you actually hired us, we could then afford to take our time and work slowly 
).
Having Beaten my Dead Horse, let me ask some questions about what I could see, and about your task. You want to synchronize an AI and an AO task. First question -- does the AO task involve data from the AI task, or are the data streams independent? What is the sampling rate for each Task? What is the buffer size for each task?
I assume you realize that if you are, say, taking 100 points at a time at 1 KHz, you will get data 10 times/second. If you want to "play back" the input data through an AO device, this "injects" an obligatory 100 msec delay between input and output (unless, of course, you use the special "Future-predicting Circuit" that NI has been secretly developing for this purpose).
Look forward to being able to examine/test your VI, and having a better understanding of your question.
Bob Schor
