Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Measuring period of a pulse

Oops, forgot to include the modified vi in the last post. Sorry, here you go.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 11 of 14
(1,363 Views)
Kevin,

Thanks for the advice, but the available points still continues to increment on each call.

I have attached another version of my test program which puts a limit on the number of times it will loop, and includes a couple of array outputs to record the values of "available points" and "points read" as it loops. I ran the program with a 16.67 Hz square wave applied to the gate, and a timeout of 1 second. (The reason for that frequency is that I'm trying to develop this to measure the shaft speed of a hydroelectric turbine that has a maximum speed of 1000 RPM.)

Two image files are attached which show the final screen after 7 and 9 loops, respectively. In the 7 loop image,
you will see how the available points grows by the number of points read in through the last loop. The error cluster is still empty because through the last loop, "read buffer" was only told to get 8 readings (which at this frequency should take about half a second) and did not timeout.

In the 9 loop image, the "read buffer" function has been asked to get more than the 16-17 readings it will get in 1 second, so a 10800 timeout error was generated. Note that this does not stop the loop because it is just a warning and "status" does not go true. "Availble points" still increments by the number read.

Thank you very much for all the advice you've given me on this, but I'm writing it off as a quirk of the system I'm working with.

Robert D.
0 Kudos
Message 12 of 14
(1,363 Views)
I found a system to try it out and got the same behavior you're describing. The 'available points' attribute doesn't seem to get reset when data is read. My test was with NI-DAQ 7.2 -- what version are you using? (BTW, the same behavior resulted from both LV 6.1 and 7.0).
I suspect this is a bug in NI-DAQ because I've made numerous apps in the past where it behaved properly. I am not certain which version of NI-DAQ I can vouch for, but it was probably ~6.9.x

Now for the good news -- there's a workaround! This goes back to the method used before the "Get Attribute" routine existed, and is analogous to the method one can use with analog acquisition.
Replace the
query for 'available points' with a call to 'Read Buffer', but tell it to read 0 points. Then the 'backlog' output will tell you the # of available points, and you can pass that # into the second "real" call to 'Read Buffer'.

I didn't try converting, but I suspect that it would also work properly if you used the DAQmx interface to the hardware.

Attached is a library with 2 top-level vi's. The only difference is that one calls 'Get Attribute' asking for 'available points' while the other calls 'Read Buffer' with '# to read' == 0.
Does anyone out there have a system with an older NI-DAQ to test these out? I'll wait a couple days for responses before filing a (suspected) bug report.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 13 of 14
(1,363 Views)
Perfect! The workaround works for me.

I'm using NI-DAQ 6.9.3 because I'm trying to maintain compatibility with a SCXI-1200 while I'm transitioning away from it, and NI-DAQ 7.x doesn't support it.

Thanks again for the help.
0 Kudos
Message 14 of 14
(1,363 Views)