cDAQ sample rate

[pktl2k]

Hello everyone,

I'm using a cDAQ 9174 with a 9401 module to output a finite sequence at a specific rate to trigger some devices. However, the actual sample rate seems to differ from the expected rate.

I made some measurements using the attached vi to compare the expected with the actual effective sample rate.

Expected	Actual	Actual-Expected
1	1,19624	0,19624
5	5,92426	0,92426
10	11,7485	1,7485
20	22,9828	2,9828
30	33,7812	3,7812
40	43,8152	3,8152
50	54,1208	4,1208
60	62,8937	2,8937
70	71,8916	1,8916
80	80,5822	0,5822
90	88,9891	-1,0109
100	96,6605	-3,3395
120	112,182	-7,818
140	125,938	-14,062
160	139,997	-20,003
180	158,569	-21,431
200	171,392	-28,608

There should be an increasing overhead since I'm stopping and restarting the task after each iteration. But as you can see, below ~90 Hz, the actual effective sample rate is even higher than expected! What's happening here?

[crossrulz]

You are adding to the "sample rate" when you add in the starting and stopping of the task.  Plus you are using software timing to get that number.  What you really should be doing is looking at the actual signal with an oscilloscope and determining the sample rate based on that.

[pktl2k]

Thanks, I'm aware of the overhead. This leads to lower than expected "effective" sample rates.

But how can the "effective" sample rate be higher than expected?

It should not be possible for the sequence ,[start, wait until complete and stop task], to complete earlier than expected.

Starting/stopping, transmission to/from cDAQ, software delays all add to the time a sequence takes to complete. There is nothing to make it faster (well, apparently there is...?).

[Kevin_Price]

What's the real goal here?  Are you trying to maximize your "effective samples/sec"?

Rather than mucking about with better methods for *defining* and *measuring* such a parameter, l first want to know whether the real goal is to *maximize* it.  If so, please describe more about the system and the reasoning behind the approach you've taken thus far.  You're adding overhead with several of the DAQmx functions you put inside your loops, so let's figure out whether they serve a necessary purpose there or not.

-Kevin P

[pktl2k]

I need to trigger 3 devices, one after the other at a specific rate using 3 channels of the 9401. To do that, I load the appropriate sequence in the cDAQ, tell it to run at the desired rate and let it do it's thing.

When the sequence is complete, I just need to repeat it. I don't need to worry too much about delays in between sequences.

Using the "DAQmx Wait Until Done.vi", I assumed, that the sequence is complete when the cDAQ says so. Now, I'm not so sure because it appears to complete earlier than expected. At least for low sample rates.

[TSE_Expert]

Hello pktl2k,

I would skip the standard answers like software overhead, software time measurement etc.

Because you're completely right: you won't get those measured rates just because of some 10-100 ms sofware delays, and even higher effective rates...

I think you should carefully check your calculation first of all:

1. If i>=10*Rate[S/s], your stop if true condition will become true, your code exits from the while loop.

So: i_final will be the smallest integer above 10*Rate, i.e. ceil(10*Rate).

2. Then you increment it. ceil(10*Rate)+1

3. And divide it with the measured time difference: [ceil(10*Rate)+1]/Delta_T

4. Finally you multiply it by the number of samples  generated in one burst: 

[ceil(10*Rate)+1]/Delta_T*Nsamples

5. You expect it to be a good approximation of the parameter Rate:

[ceil(10*Rate)+1]/Delta_T*Nsamples?~?Rate

My question is: Why?

Best Regards,

NI TSE

[pktl2k]

---

5. You expect it to be a good approximation of the parameter Rate:

[ceil(10*Rate)+1]/Delta_T*Nsamples?~?Rate

Not so convincing, if you write it that way...

I changed my measurement code to fix the calculation (hopefully).

Still, the result is about the same. Below 90 to 100 Hz expected sample rate, the effective sample rate is higher than expected. My conclusion is, that "DAQmx Wait Until Done.vi" is not always actually waiting (?) and I need to consider this in my application.

On the other hand, I'm just assuming, that the cDAQ is generating samples with the specified rate. Unfortunately, I don't have access to an oscilloscope at the moment, so I can't measure it. It seems, the "SampClk.Rate" property doesn't give me an actual measured rate.

[TSE_Expert]

Hi pktl2k,

it didn't convince me graphically either...

About DAQmx Wait Until Done (VI):

"Waits for the measurement or generation to complete. Use this VI to ensure that the specified operation is complete before you stop the task."

So this shall not be the issue. Please show me, how you fixed your calcs.

Best Regards,

NI TSE

[pktl2k]

---

Please show me, how you fixed your calcs.

I already did. See the snippet in my previous post.

Now I calculate the rate of iterations from the mean time between start and stop task. Multiplying with the number of samples in the sequence gives me the "effective" sample rate.

So now it's just: Eff.Rate = N_Samples / mean(Delta_T)

[TSE_Expert]

Hello pktl2k,

DAQmx Wait Until Done.vi blocks execution until the generation or acquisition is complete.
For finite operations, the VI completes only when the final sample is generated or acquired or an error occurs:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P99XSAS

I don't see manual error handling in your code. Apply Simple Error Handler VI for example.

Have you checked for errors? Is automatic error Handling in your LabVIEW enabled?

Another question: how could be [ceil(10*Rate)+1]/Delta_T*Nsamples and N_Samples / mean(Delta_T)

roughly the same? It would mean: [ceil(10*Rate)+1] is roughly unity.

Hope this helps,

NI TSE