DAQmx continuous acquisition with Timed Loop

[Inpriser]

Hello,
I have a problem with 100% CPU usage during DAQmx continuous acquisition. The subject is similar than what observed another member in the .NET section : http://forums.ni.com/ni/board/message?board.id=232&message.id=426

Actually, I perform a continuous voltage acquistion using a PXI 6254 DAQ card. I have plenty of other modules running in parallel and I MUST check CPU usage of my application to make sure all operations can be performed correctly. We also have other apps running on this PC and we cannot tolerate a constant high CPU load.

I read continuously 1000 samples at 10kHz on my channel, so every 100ms I get these data and need to send them to other VIs. Unfornutaley, CPU usage is 100% when I use a While loop with a DAQmx read VI, to get these data cyclically, even if I place a "Wait" VI inside the loop.

I know that people said on this forum (see link above to other topic) that this behavior was - normal - ...
Nevertheless, I managed to do something work quite well using a new functionality offered with LabView 7.1 : the Timed Loop. When using the DAQmx Read inside this loop it take almost no resource, but I have to associate a DAQmx Create Timing Source VI with the Sample Clock signal as parameter. I still have an error when I run the task, but afterwards it continues to run correctly.
In fact, I already did this kind of work in traditional NI DAQ using an "Occurrence"... but the PXI 6254 (M series) seems to work only with DAQmx...

Does anyone have gone through this ?
Is the Timed Loop a possibility offered by NI to overcome the 100% CPU usage in DAQmx ?

[Stuart_G]

Abosultely...the timed loop is great for this. I have attatched an example that shows how to use the timed loop to reduce the CPU usage. Also, on the DAQ team we are working on some stuff so that you don't see the apparent 100% CPU usage. I say apparent because even though task manager says 100% we will yield to other processes if they need it. Stay tuned for future versions.

StuartG

[Inpriser]

Thanks Stuart,
I also had a look on this Timing Source using Digital Edge Counter. It would be great to include it in the "Search examples" assistant included with LabView to illustrate this possibility, because I really did not found any measurement VI example that does not take 100% CPU load...
For my application, it is the solution I will use.

I actually found another thing very interesting to improve "DAQmx Read" VI : before using this VI, connect a "VI Read Property" node and select the "Available sample per channel" property.
Using this value with a the "DAQmx Read" VI inside a For Loop, it takes almost no resource at all !
I understood that the CPU load used by DAQmx corresponded to the the time the DAQmx Read VI was waiting for data being available.

I modified your example accordingly. This method could be useful if one wants to use "traditional" loop instead of Timed Loop. What is also interesting is that we do not need in this case a counter on the DAQ board.

[Stuart_G]

Just getting back to reading this. To answer your first question about the example finder this was a bug where the timed loop stuff wasn't showing up properly. I have fixed this. Are there any particular search words you would prefer?? I took a quick look at the VI you attatched. I'm not sure exactly why you are doing this (it was a little confusing for me). If you wire a -1 to the #samples to read it reads all available and then returns. I think this will do the same thing as what your VI was trying to do. It will also reduce the CPU load as your method is doing.

Stuart

[Inpriser]

Hello Stuart,
What I actually want to do is to read cyclically my 10kHz measurements. So every 100ms, 1000 samples should be available for each channel.
If one starts the acquisition and immediately asks for 1000 samples, I understood that the "DAQmx Read" will take 100% CPU until these samples are effectively available.
What I simply do inside the loop is to make sure I have AT LEAST 1000 samples available : if there are less than 1000 samples, I do not read them (For Loop set to 0), if there are between 1000 and 1999 samples I read them once, 2000 and 2999 twice and so on...
With such a method I am sure not to be stucked in the "DAQmx Read". In my program I actually expect to use only blocks of exactly 1000 samples to process (cyclically), that is why I do not want to use "-1" in "Sample to Read".
What is also interesting with that is when another program sometimes takes all resources on the machine. In that case our LabView program might be "late" for reading measurements, but the For Loop will read them by blocks of 1000.

What I would suggest for DAQmx examples included with LabView is to give some "performance improvements" as I found by using the "Samples Available" property. This could be done by giving VIs using such tips and showing almost no CPU usage.
Almost all examples given actually do not care about CPU usage, but I think a lot of programmers do.

I currently have a similar problem of CPU usage for analog generation with DAQmx (I created a topic related to independant analog generation)... and here to, I discovered that "hidden" DAQmx properties should help me to tune it.

Thanks for your support.