usb 6009 not keeping up with samples

[Pinky2011]

Hi, I am new to Labview, so I know this probably about to sound like a novice issue, but I am trying to do some simple voltage reading using a USB 6009 card and am having some problems.

What I would like to do is read voltages from two AI channels, one sample at a time (eventually I would like the code to do something as soon as a voltage crosses a threshold, which is why I am reading samples one at a time, but I am not there yet, right now I am just writing the data to a chart). I have a multichannel task, and I am reading a 1 point sample each iteration of a while loop.  I have attached the code for you to see what I am doing.  2AI_Dev2 denotes a task created using the first two AI channels on the DAQ (differential recording, -10 to 10 V each channel). 

The problem is that the while loop rapidly falls behind the data acquisition.  What I would like to do is sample the data at 100 Hz and have the loop execute every 10 ms (basically getting each sample as it becomes available), but the while loop will not keep up.  Within the first second of acquistion, the data buffer shows 3-4 samples are available, and the number grows constantly as the program runs, reaching a few hundred after a minute.

I can not figure this out.  I do have a few more pieces of information that may be of help to you.

1.  The program has been built into an executable.  It runs fine on my development machine (Win 7, 3.2 GHz i5,8 GB of ram).  The computer I am trying to run the executable on is an XP machine (XP SP2, 3.0 GHz P4, 2 GB of ram).

2.  Both computers have DAQmx 9.3 installed

3.  I have read about other processes slowing down loop execution, so I reformatted the XP drive, reinstalled XP, and the NI driver bundle (DAQmx, MAX, etc).  I turned off the firewall, windows updates (this computer is to be used as a data acqusition machine and will not be on any network), no antivirus is installed.  Basically, I got the machine to the point where there is XP, NI software, and my program and that is it.  Still the problem occurs.

4.  I cut out both charts (I eventually put one back in, so you see I am only indexing one element from the array following each buffer read).  That did not fix the issue.

5.  I tried the DAQ device on all USB ports, I took the keyboard and mouse off, found some old PS/2 keyboard and mouse and put them on, so nothing is on the USB ports but the device (yes, it is USB 2.0) .  Still no fix.

Do I need a faster machine?  I would think that given my slow sampling rate (100 Hz), even this old machine could easily keep up, but it doesn't.  It runs fine on my other machine, though. 

Could it be a problem with the executable?  I only have one VI in the build.  I have built other VI's that work, so I think I am doing that correctly (well, and it runs fine on the other computer).

Sorry for such a long post, but I wanted you to have as much information as possible (and to know that I have tried a number of things before comming to you and I have run out of options).

Thank you in advance for your help

[John_P1]

Hi Pinky2011,

The USB implementation in Windows 7 is quite a bit different than XP.  USB Transfers in general are prone to latency and non-determinism--if you ever have latency over 10 ms in your code then you will start falling behind.  Due to the wait function inside the loop, the loop will never run faster than every 10 ms, so there is no way for the task to catch back up once it has fallen behind.

You have two options, depending on if you care about the samples being exactly 10 ms apart or not:

If the spacing of the data is important and must be an exact 10 ms:

I'd suggest taking out the wait function inside your loop.  The DAQmx Read call will block until a sample becomes available.  So, under normal circumstances the loop should run every 10 ms (regulated by the rate that the hardware is sampling data).  If your OS decides to allocate resources elsewhere and misses the 10 ms window, the loop will simply run quicker on the next iteration(s) until it has caught up with the data that was previously buffered.  The samples are still taken every 10 ms based on the hardware clock, but they might be returned a bit more sporadically due to bus latency.

If the spacing of the sampled data is not important, but you just want to process the most recent value on the input:

I'd suggest removing the hardware timing altogether.  If you do this, the call to DAQmx Read will initiate the data transfer immediately and you will get whatever value is currently on the line.  You can keep your software-timed 10 ms delay if you'd like, but removing it would result in the loop running as quickly as possible.  You're still limited by the rate data can be transferred so the loop would only run once every few ms.  Removing both the hardware timing and the loop delay would give you the fastest loop rates with the most current data possible.  Of course, the timing between samples would be non-uniform in this case.

Try running something like this to check what sort of loop rates you are getting.  I'd expect the loop time to (on average) be below 10 ms:

Best Regards,

[Pinky2011]

I favored the first of your suggestions.  I took out the timed loop.  I works perfectly!  I never thought about just letting the Read.vi determine the execution of the loop by waiting for the next sample to become available.  Great idea.

I had no idea USB was so different from Win 7 to XP.  I was going crazy trying to figure this out.

Thanks so much!