DAQmx delay in reading?!!

[ballbouncing]

Eric,

Thank you very much as it was a really helpful note.

I think according to the note I am filling my hardware buffer, which is 4096 in USB 6221 BNC, with 100KHz. So this number, sampling rate, is far beyond my buffer size. On the other side my loop execution rate is also in the order of 1-2 msec. I used the timedloop as well with 1-2 msec samplin rates.

So then where are the missing data? why the actual outcome is the delayed version of the input. 

I have two options:

1- how is the buffer filled? Is it filled by the latest just acquired data. In that sense it should be overwritten 25 times in my application. 

100,000 =(almost) 25*4096.

2- How is the reading from the buffer? Is it from the top or bottom? I mean does the read.vi fetch, in the software, the latest acquired data or the first one, i.e. oldest one?

3- Is the sampling from the sensor uniform? More precisely I mean does the ADC sample 100KHz uniformly therough every sec. So that I have one sample at every 1/100,000 = 10us sec.

Thank you very much for your attention.

[Beutlich]

To answer your questions in order:

1- The Analog Input uses a FIFO buffer, which is described in the M Series User Manual (you can see it on the block diagram on 4-1 and it is described on 4-10 in more detail).

2 - Your original code and the example you also tested, the Meas Angular Position-Buffered-Cont-Ext Clk.vi, will perform differently on the DAQmx Read.vi because of the parameters passed to it. Both of them are collecting more than one sample, in fact the read waiting until it can read a chunk of data at once.

            - In your original code, the number of samples per channel is set to -1, which has the DAQmx read all of the available samples when the action is performed.

            - For the example you tested, the number of samples per channel is wired to a control, which defaults to 1000, so the DAQmx Read.vi will wait until it is able to read 1000 samples at once. 

3 - The sampling is uniform, so when you specify the rate on the DAQmx Timing.vi to 100,000, you will have 100,000 samples per second evenly spaced, or a sample for every 10 usec period. In your original code, these values are arriving in an array and you index the first value only, thus ignoring the remaining data points.

I was thinking earlier that this was a finite acquisition, but I noticed now that this is continuous. The samples per channel on the Timing.vi performs different actions between finite and continuous. For finite acquisition, this will define how many samples to read, so the Read VI will wait until all of those samples are available. Since you have configured continuous acquisition in both codes that you tested, the samples per channel parameter only sets the buffer size, so it just needs to be adequately sized ( 1/10 of the rate is good, as described in the DAQmx Timing and Sample Rates mentioned earlier). In this case, you want to write the value number of samples per channel to affect how long you wait to gather enough samples. If you are just expecting one value back from the DAQmx Read.vi, you could change the vi to a Sinlge Sample (click on the text box right below the DAQmx Read.vi to change this). Alternatively, you could adjust the Read to read fewer samples.

[ballbouncing]

Dear Eric,

I just found that there are two buffers. One on the USB board and the other one on my computer. while the first one is FIFO 2 samples, the second one is adjustable by input buffer.vi. 

But now I am wondering how is this buffer filled. Is it filled by the latest trials or it ignores the latest ones until I read the early samples.

More specifically in my application I have 100 KHz sampling rate. So if choose the buffer size as 1000, it should be filled 10 times in 1 sec. is it like that? 

beacause on the other hand I am reading from this buffer and if the rate of reading doesn't match the rate of acquisition ....

In other words my buffer on the card is FIFO. How is the buffer inside my computer? 

1-FIFO: first in first out

2-FILO: first in last out

3.FIXX: first in might be overwritten and never out 🙂

[T-REX$]

Hi Eric,

The in-ram buffer is indeed FIFO. What exactly are you specifying as the sample rate and the samples to read? Since you are using continuous sampling, these are the most important values (as Eric stated). A rate of 100k with 1000 samples to read would take about 1/100 of a second to acquire.

[ballbouncing]

Hi TJ,

I have set

timing vi

sample clock source: 100kHz Timebase

Rate: 100kHz

Samples per channel: 1000

read vi:

number of samples per channel: 100

regardless of these values the delay persists.

[ballbouncing]

I would alaso like to share the following benchmark.vi.

This shows that there is around 20 msec delay between the execution of two loops.

Thanks.

[T-REX$]

Hi Ballbouncing,

The vi that you uploaded (BB 4.29 benchmark) does not measure the delay between reads, as I believe you are trying to do. If you run this VI in highlight execution mode, you will see that the "delay" indicator is filled before your while loop executes even once. What you are measuring here is the time that it takes to create a virtual channel and then start the task. Try timing just the DAQmx Read function.

[ballbouncing]

Based on you classification, the virtual channel just makes a path for data transfer and the loop will erad them on a timely basis.

I measured the loop time execution, it's even less than a milisecond. This means that the loop is running pretty faster than my expectation.

Then where the delay is coming from? this is a very simple vi. the actual outcome is 50 msec ahead of the presented data on the monitor.

Then where are my samples??

Thanks 

Amir

[T-REX$]

Hi Amir,

Try adding a "Wait until Next ms multiple" function inside your while loop, with the input tied to a constant of 5. I suspect that loop is just running too fast, and so you can't update your graph often enough.

[ballbouncing]

I have added 5, 10 and 20 (msec) timer delay. the delay is still there.