DAQmx Read seems to skip counter Period measurement

[dBoura]

I'm doing buffered period measurement with a 6602.  I start the task, then I would like to have the DAQmx Read task take place in a while loop so that I can update indicators with period measurements as they are coming in.  My issue is that it seems like every Read task causes one period measurement to be skipped.  For example, I can set up a function generator to output a burst of 101 cycles.  If I set my Read task to read 100 samples (via wiring 100 to the "number of samples per channel" input), it will complete as expected and output an array of 100 periods.  If I set the Read task to only read 1 sample, however, it will only execute 50 times.  Likewise, if I set the Read task to read 10 samples, it will only execute 90 times.  

I've been trying to use the AvailSampPerChan and TotalSampPerChanAquired properties to troubleshoot and see how many periods are actually in the buffer, but those properties always show 0.  I also am not able to use the Read (it just times out) in any other combination of RelativeTo and Offset property values besides CurrentReadPos and 0 respectively.  What am I doing wrong?

Thanks,

David

[Kevin_Price]

It could help to post the code.  It'd further help to back-save by a few versions -- I for one can't open anything later than LV 2016.

I've used all the properties you mentioned a decent amount in continuous sampling tasks without similar symptoms.  So I start by wondering if some of these things might be a side-effect of doing finite acquisition.  I don't do a lot of finite acquisition and am less sure what kind of behavior to expect from those properties.

I can think of various possible coding issues that can account for some of the things you observe, but it's random guessing without some code to look at.  One example: are you using a query "DAQmx Is Task Done" to terminate the loop?  It's very possible for a finite task itself to be complete even if you haven't yet retrieved all the measurements from the task buffer with calls to DAQmx Read.  The task considers itself complete when its done putting samples *into* the task buffer, regardless of how many samples you've read *out of* the task buffer.  Your attempts to query the # samples related properties was a good instinct and I'm surprised they didn't give you useful info (unless you query them after stopping the task).

-Kevin P

[dBoura]

Here is my VI (for Labview 2016).  I have a continuous task running, and I'd like to read some set of data from the buffer every 10 seconds or so but, like I said before, it seems like every time Read executes it skips a measurement.  Another clue that leads me to believe this is this:  everything I have read says that, when doing buffered period measurements, you have to discard the first measurement because it is simply the time between when the task was started and when the first edge is detected.  I never get this first garbage data point, though.  No matter how long of time elapses between the starting of the task and the first edge coming into the counter, I get a correct period measurement.  It's like the Read is throwing out that first measurement automatically.

David

[Kevin_Price · Accepted solution]

I don't think you're actually doing *buffered* period measurements.  I can't say for 100% sure because your choice of "Programmed I/O" is a mode I never choose.  I suspect you shouldn't be using it either.

Further, there's no call to DAQmx Timing.  Any buffered measurement task I've ever programmed in DAQmx included a call to DAQmx Timing to set up a buffer and define sampling.   For a period measurement task, you should use the "Implicit" sampling option.

I'm a bit surprised your attempt to do an "N sample" read doesn't throw an error.  Does it ever return more than 1 sample?  I'm expecting it doesn't because I don't think your task is configured to be able to do any buffering of samples.

Once you successfully configure for buffered sampling (using DAQmx Timing), then yes, the 1st period measurement will be the garbage value you've read about.  (Note that while this is true for your 6602 board, the newer generation of counters actually now suppress this 1st garbage value.  Unfortunately, there are scenarios where the value can actually be meaningful, and I'm not a particular fan of the behavior change.)

-Kevin P

[dBoura]

You were right--I wasn't actually doing buffered measurements like I thought I was.  I missed the statement in the manual that buffered measurements are not supported by "Programmed I/O" mode.  I switched to "DMA", and also added a DAQmx Timing block set to "Implicit", and now my Read works as expected.

Thanks for the push in the right direction.

David