Counter read has high processor usage

[Patrick C]

I am encountering an odd issue with NI DAQmx and a PCI 6254 card.  The card's counter 0 is configured to perform a linear encoder measurement using 2 pulse counting. Channel A is routed to the 10 MHz timebase and Channel B is grounded.  The Z channel is enabled and set to a PFI line that reads an external signal to function as a reset of the count register.  The counter is read at the same timebase as the analog input clock.  For example, AI timebase is 40 kHz and the number of samples to read is 20,000.  That will return a U32 array of 20,000 counter values, twice a second. 
So here is the interesting part.  If the AI timebase is 40 kHz, the system shows about 20% CPU utilization, perfectly reasonable for what I am doing.  At 41 kHz, the CPU utilization jumps to 50% and at 42 kHz the CPU is maxed out at 100% utilization.  Why would increasing the clock speed 5% increase the CPU load 500%?  Profiling the VI shows almost all of the processor time in the Read Counter VI but only 2.2 kb of memory usage.  Is there some issue with sampling the counter registers at faster than 40 kHz?
Everything is run in Labview 8 and using NiDAQmx 8.0.0f0.  The read mode of the counter hasn't been changed from "Sleep."
Any help would be appreciated.  Thanks,

Patrick

[Travis G.]

Hello Patrick,

I'm having a hard time replicating this on my machine.  I've got all the same hardware and software on my computer, so if you could attach an example program that shows this, with instructions on how to reproduce this behavior, it should help us get to the bottom of this.

Regards,
Travis Gorkin
Applications Engineering
National Instruments
www.ni.com/support

[Patrick C]

Here is a sample of the code that is causing the problem.  The issue also seems completely independent of how many AI channels are acquired.  Thanks for looking at this.

Patrick

[Thaison_V]

Hi Patrick,

The VI you have attached calls Reconfigure Counter.vi and Phasor Config.vi, which aren't included.  I tried to follow your code, but it is a bit difficult to figure out what you intend to do in each part without those subVIs and comments in the code.  Is it possible for you to include those or comments as well?

Thaison V

[Kevin_Price]

I'd be interested in having a look too, but I would need you to do "Save with Options..." back to LV 7.1 because I don't have 8.0.  Saving to a LLB library will be the most convenient way to then post a single file here.

-Kevin P.

[Patrick C]

My apologies for not including the subVI's.  I have attached both the 8.0 and 7.1 versions of the code.  However, saving the code for 7.1 generated several warnings about being unable to save toolkit VIs for previous versions so I am not sure how the 7.1 code will perform.
Please note that the top level VI should be Counter Test.vi inside the LLB.

Thanks again for your help.

Patrick

[Patrick C]

Oops, looks like I posted the 8.0 code twice.  Here is the 7.1 code.

[Thaison_V]

Hi Patrick,

This seems more of a CPU/execution speed issue more than a driver or hardware issue.  You mentioned you haven't changed the read mode from sleep, so you may already be aware of this, but this KnowledgeBase article documents the behavior of each of the modes.  The last sentence in the "Sleep" description seems to be what is happening in your case: "However, it should be noted that if data is arriving or space is being made available fast enough such that the NI-DAQmx process does not have to wait for data, then the process will never be put to sleep and no reduction of CPU usage will occur."

For you, the threshold for the buffer to fill and be ready to read without dominating the CPU seems to be at 40 kHz.  At 42 kHz, the data is filling your buffer and being made available so fast that the DAQmx Read VI is executing as soon as it is called, so there is not time for the CPU to sleep.  On my PC (3.4 GHz P4, 1 GB ram), my threshold seems to be around 72 kHz while running your VI.  I also tested this with a few of the internally timed DAQmx acquisition shipping examples, and each one had a different threshold as well.  Sometimes increasing your "samples to read" size helps a bit since it will take more time for your buffer to fill, thus giving your CPU a chance to sleep.  This is all somewhat PC/task dependent, and each machine may have a different point where the CPU usage spikes up.

Thaison V