Elapsed Time VI Not resetting at specified time

[aniforatos]

Hi. I am using the USB-6215 counter. In labview I have an elapsed time express VI that should reset my while loop after my specified time has elapsed. However, if the counter is waiting for counts to come in, my elapsed time lags and will actually go over my specified time before resetting the while loop.

I hope there is some way around this because timing is very important for my project.

[Kevin_Price]

You've coded yourself a conflict of interest.  On the one hand, you are requesting a specific # of samples from your counter task every iteration.  It's unclear whether that will take a predictable amount of time because the sample clock is an external signal.  Once you request that # samples, the call to DAQmx Read will not return until either that # is available or you've reached the timeout (unwired, thus defaults to 10 sec).

On the other hand, it sounds like you want to terminate the loop immediately as soon as a certain total amount of time has been spent iterating through these reads.

Further, due to the nature of dataflow, the elapsed time is likely to be checked as soon as a loop iteration starts.  You may reach the target elapsed time before the DAQmx Read returns data to you, but you won't find that out until the next iteration.  And then you'll wait *again* for DAQmx Read to return.

You need to consider what matters most and code in such a way that it has priority.  Help us help you by giving us a more complete description of what you intend this code to do.  I suspect some of it isn't doing what you probably want.  (For example, the data from the DAQmx Reads is not accumulating over all the inner loop's iterations.  When the inner loop terminates, you only get the last iteration's data coming out.  Right-clicking the square blue tunnel gives you the option to pick Tunnel Mode-->Concatenating so that *all* iterations worth of data come out.)

-Kevin P

[aniforatos]

Hi Kevin,

Thanks for the reply!

I am creating this program in order to measure the half life of a radioactive source. To do this, I have my data accumulating continuously  and at  the specified time interval I want that data to be sent into an array. Then I subtract value "n-1" from "n" in that array to get the count at every time interval.

Once I have accumulated a total number of counts I then plot this number of counts vs a linear spacing of the time it took to take all of that data in MATLAB.

So the counter is actually counting for example, 2.3 seconds every iteration as opposed to 2.0.

I have attached a plot of what my data SHOULD look like.

[Kevin_Price]

After another look at your posted code, I think your counter config is already really close.  You don't really need the Elapsed Time construct, you can handle all your time-related stuff from the counter task alone.

If you want to tally up your counts in 2-second bins, you should just define a 0.5 Hz Sample Clock on PFI0.  Then you've got hardware defining those 2-second intervals *far* more accurately and repeatably than you'd ever achieve in software with the Elapsed Time method.  Every single counter sample you read would be the cumulative count up the end of a particular 2-second bin.  The finite difference you mentioned would produce the graph you want.

If PFI0 is an external signal with a known and constant rate, you can pretty much do the same thing by reading 2.000 seconds worth of samples every iteration.  The last value will be the cumulative counts at the end of the interval.

Couple subtleties: it's tricky to make sure that the very first sample is meaningful.  Without some careful triggering and other shared hardware timing, it will normally measure the number of counts over a random-ish interval from whenever you start the counting task until the next sample clock edge.  It may be a fraction of an interval or multiple intervals, all depending on the degree to which all your hardware, signals, and software are synced.    Also, there's a way to configure the counter for a kind of "period measurement" where you get those finite differences back directly from the task.  It's a little less straightforward to configure and you shouldn't need to worry about it unless your total cumulative counts get too big for a 32-bit integer.

-Kevin P