Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Finite buffered counting using 6602

I used two counters to generate finite pulses and gated to the counter's gate signal. I am generating 10 finite pulses to get 10 readings. I get the reading fine when there is a source present. I have situation random edges, which may not happen i a gated time period. So i need to get the previous counter value if there is no edge measured. for eg. I got 3 edges on the first gated time period and then there is no source i should get the value 3 ie previously saved value. But i am not getting like this. I get some times 4 or sometimes 5 reading instead of 10 reading. I need to get the results all the time with 10 reading ie( 3,4,7,8,8,10,13,18,18,18). so that i can take the difference. But i am getting the reading 3,4,7,8,10,13,18.
0 Kudos
Message 1 of 5
(4,231 Views)
On the counter that you are using to take readings, you should enable "synchronous counting" (if using traditional NI-DAQ) for DAQmx this property is called "duplicate count prevention". Then yhou should see the correct counts even if you have no source edges between gates.

Hope this helps!
gus....
0 Kudos
Message 2 of 5
(4,231 Views)
I know that "synchronous counting" is recommended for cases where there might not be any source edges between successive gate edges. But I wouldn't have expected the behavior described by bestin. I'd thought that some value would be buffered on each gate edge, but that the value itself can potentially be wrong if the counter isn't set up for "synchronous counting." I'd also thought it was most likely troublesome for buffered periods rather than buffered event (edge) counting.

So, in an effort to understand "synchronous counting" mode better, I'd like to describe a sequence and figure out what values should be buffered.

2 source edges
1st gate edge
1 source edge
2nd gate edge
0 source edges
3rd gate edge
2 source edge
s
4th gate edge
read all buffered data

Case A: buffered event (edge) counting, "synchronous counting" ON. I'd expect a buffer that looks like (2,3,3,5).

Case B: buffered event counting, "synchronous counting" OFF. I'd expect a buffer that looks like (2,3,?,5) where ? is likely but not guaranteed to be 3. (If it isn't 3, what could it be? And would the next value also be wrong?)
Or would this indeed result in bestin's symptoms and produce (2,3,5)?

Case C: buffered period measurement, "synchronous counting" ON. I'd expect a buffer that looks like (2,1,0,2).

Case 😧 buffered period measurement, "synchronous counting" OFF. I'd expect a buffer that looks like (2,1,?,2) where ? may be either 1 (wrong) or 0 (correct). (Could it be anything else?). Even if it were wrong, I'd still expect the next value to be correct.
Or, should I expect a DAQ error instead?

-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 3 of 5
(4,231 Views)
I think you understood my problem and i believe that buffered period measurement could solve that situation with synchronous counting on.

Thanks for your replay and i am going to test that today.

bestin
0 Kudos
Message 4 of 5
(4,231 Views)
Now I'm not positive, but I'm pretty sure this would be the behavior.

A: correct
B: 2,3,5 (hw would not recognize the gate if no source edges occurred)
C: correct, but I think you would get a "no source between two gates" error.
😧 Once again the gate wouldn't be recognized, so you'd get 2,1,2

The behavior of synchronous counting has always been difficult to understand, and I think that has to do with the fact that when it is described you have to keep in mind the behavior of STC counters in relation to TIO counters. Synchronous counting is really a part of a two part fix for some undesirable behavior on the STC when no source edges occur. The other part of the fix was made to the counter itself, which results in no GATE edges being recogniz
ed when there are no SOURCE edges between two gates when synchronous counting is off. Synchronous counting tends to be more of a problem for people with buffered event counting applications rather than buffered period because most of the time people will use an internal timebase as the SOURCE for buffered period measurement, but will often use an external signal for the SOURCE in a buffered event counting scenario.

I hope this doesn't confuse the issue any more, but if it does feel free to respond and I'll try to explain it a different way.

Hope this helps!
gus....
0 Kudos
Message 5 of 5
(4,231 Views)