Why does continous data acquisition (with Daqmx) do 100% of CPU usage under VB.Net whaterver the number of channels or frequency used ?

[Mansblo]

With a PCI6024E under VB.net, continous data acquisition (with Daqmx) take 100% of cpu to run without any bloody display like CWGraph 7.0. I tried with NI's samples for VB.net, and it's the same. I notice that Measurement & automation test panel take no cpu to run continous data acquisition. What is the tips?

[nd]

Hi Mansblo,
This is expected behaviour... Please see the following
KB
Basically the CPU yeilds to any process that needs to use the CPU, so it should not affect the other processes.If no one else requests resources, DAQmx goes ahead and uses them all.

[Mansblo]

Sure, it was perhaps a good way to implement such things 20 years ago, when OS were not really "multi-threads" and hardware interruptions not so accessible !!
"Taking all ressources" is for me something absolutly stupid. One thing is certain, you will never know if your application is getting too many ressources unless your acquisitions failled!

But the more supprising is that in the "measurement & automation" test panel (in daqmx section), continous data acquisitions doesn't take all ressources !!! Is this feature only due to Daqmx .Net API?

[nd]

Its not due to the .NET API. The knowledgebase is for all DAQmx based APIs in general...So you should see the same behaviour in labVIEW or in CVI or C++(other APIs that use DAQmx). In fact i believe that the KB i linked to was initially a labVIEW KB...

I haven't tried this in the test panels yet, but i will let you know what i find out..

From your reply above, you mentioned that "One thing is certain, you will never know if your application is getting too many resources unless your acquisitions failled! " , does that mean that you are getting an exception of some sort and not getting a message? or getting one too late ? or not getting one at all ?

Best Regards,
NandanD

[Mansblo]

The problem is, that we build applications that do other things, beside data acquisition... (database, regulation...). These are industrial applications that need to run flawlessly. If we consume too much CPU power, then DaqMX acquisitions fail, and that cannot be permitted.

Right now, we cannot be sure of where we stand in terms of CPU power, and cannot be sure of the reserve we still have. Usually, when developping, we are able to determine if some parts need optimizations just by looking at the CPU graphchart. Now, we just see a 100% consumed CPU power.

I hope you see what I mean and why it is a problem for us.

Best regards,

[brents]

Internally, the NI-DAQmx Read VI utilizes CPU idle time to maximize sample retrieval performance. Even so, NI-DAQmx is preemptible and yields to Windows quickly if samples are not yet available to be read. Although the processor load shows 100% when a DAQ example is running, that example will give up the CPU to another thread.

It is true that this makes it difficult to evaluate your program�s performance characteristics from a CPU load monitor. We intend to offer more options in the future, and will take your feedback into account during design. Balancing CPU efficiency against high speed throughput and single sample responsiveness is a challenge. For instance, sleeping can increase processor efficiency, but at the expense of responsiveness. This is, in fact,
what the MAX test panel does.