LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sampling rate 1000, read rate 1000, still have missed samples every 5 minutes

I have inherited a program and exchanged the old data acquisition card for a NI6211.

After some troubleshooting, I've managed to make it run as it should except for one remark;

Every five minutes or so (2-10 minutes) i miss a batch of samples.

 

As the program is extensive, I will try to describe it rather then to post it here. It includes in- and output on the digital channels (one of wich is frequency measurement) and analog input/output. My error is with the analog input.

 

In one VI i create the analog virtual channels and the sample rate of continuous 1000. The task for the analog input channels is saved, commited via Control Task.vi, started and sent as an output. The output enters a loop, and reads 50 samples as soon as AvailSamplesPerChannel >= 50 (it checks every 10ms). If the samples in the buffer ever come over 100samples (also checked by AvailSamplesPerChannel), the program reads 50 samples without using them as a means of flushing a part of the buffer. At that point it writes a message to the user that samples have been flushed. This setup would (and i believe it didn't with the old card) not leave any samples in the buffer as the program will read 50 samples as soon as they were availible at a rate equal to input.

 

I have also rerouted the program past the "check for 50 samples every 10ms" and the error maintains.

 

Now, if this would have been a issue that the internal clocks of the computer and the DAQ were off i believe i would see these missed samples more frequently, or at least more periodicly. Indeed, one of my test computers was an old laptop where this was an issue and samples were flushed every odd second.

 

I am using Windows XP SP2 and Labview 2012 SP1. The CPU usage is at 50% even during flushed samples according to the task manager.

 

While i cannot attach the complete program, i have attached a few screenshots:

Outside loop:

a) Creation of channels

Inside loop:

b) Samples read

c) Samples flushed

0 Kudos
Message 1 of 5
(2,400 Views)

I can also add that the computer doesn't run any other programs except labview, and has no other USB devices attached.

0 Kudos
Message 2 of 5
(2,393 Views)

My first thought is that you may have a race condition with the Antal samp. local variables. The loop which waits may be using a different value than the Analog Read.  

 

It seems unnecessarily complicated. The DAQmx Read will wait for the specified number of samples. So just set the Number of Samples to Read to 50 and get rid of the wait loop.

 

Lynn

Message 3 of 5
(2,382 Views)

Why don't you tell the driver (while continously sampling) to read 50 samples? The read/fetch vi will wait until the requested no. of samples is in the buffer or timeout.

You can check for samples available bevore and in case of >50S read all (read -1 😉 ) and only use the recent 50 + error message.

If you can't read and process the samples fast enougth, you can use the vi analyser to find the bottleneck. (and reprogram to a producer consumer architecture 😉

 

EDIT: Lynn you beat me ... again 😄

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


Message 4 of 5
(2,354 Views)

Thanks guys, as you said the whole piece of code that waited for samples was unnessecary. I just cut it out, rerouted a bit and voilá. I'm guessing that the old card/drivers somehow needed it. DAQmx solved it fine and the card/program performs well now!

0 Kudos
Message 5 of 5
(2,305 Views)