Counter Resetting when Monitoring Pulse Generation

[SurfaceSurfer]

Hello,

I've run into a problem with my pulse counter or pulse train resetting when I run the attached VI. The VI doesn't actually stop, rather it appears that the counters "data" (from Counter DBL 1Samp) resets to zero...maybe, not sure, maybe the problem is with the pulse train?!?!?

I have attached the VI as well as a JPG image of the VI if anyone wants to take a gander.

What I'm atttempting to do is generate a continuous pulse sequence and to count the number generated pulses. We are looking to have this running continuously for several days at a time.

So far the VI works fine for short durations (<1hr) or as long as the counted # of "Revolutions", derived from counter "data", is below 41941 (counter data gives ~4,292,410,329 counts). Once you hit this value (takes ~50 mins with the current settings) I've found that either the counter resets or there is an interruption in the pulse train. The interruption of the pulse train is more important to us as we are using the pulses to drive a motor. 

As of yet I haven't been able to figure out which one is the problem. I tried looking into buffer problems but when I tried to use DAQmx READ "AvailSamplPerChan" an error comes up saying that the output is non-buffered or something to that effect.

Anyway, we'd like to have the continuous pulse train and the # of pulses generated (pulse count) to run for several days so if there is an easier way to do this or you know how to fix the current VI I'd aprpeciate any help you can give.

We're using the USB-6259 and Labview 8.0.

best
SS

[SurfaceSurfer]

Woops I meant to post this in the Labview forum as it seems more appropriate.

Sorry for the duplicate posts....

best

SS

[Kevin_Price]

What you're seeing is almost certainly just a "wrap-around" or "rollover" effect as your edge counts get to the maximum possible 32-bit integer number.  The internal count register will simply wrap around back to 0 again whenever this happens.  There are workarounds, but since I don't have LV near my network PC, I can only give a verbal description. 

There's a DAQmx Property node (I *think* it's a DAQmx Channel property node) you can query that tells you whether this has occurred.  The terminology to look for is something like "TC reached?" where TC stands for "terminal count".  If you get a True output, you'll know that you've crossed that barrier sometime since your last query.  (Note: subsequent queries will return False until the *next* time the counter does a wrap-around.)  Each time you get a True, you can increment a software count to track the number of wrap-arounds.

You can then multiply this # of wrap-arounds by 2^32 and add it to the instantaneous count value to get a total cumulative count.  It's probably safe to do the addition using floating-point DBL's, but a pure integer method would be even better if you've got a version of LabVIEW that supports 64-bit integers.  You can perform a U32 DAQmx Read to get a 32-bit integer count and also track the # of wrap-arounds as a 32-bit count.  Then you can combine them with a low-level numeric manipulation function named something similar to "Join Numbers", which combines the two 32-bit values as a low and high segment of a 64-bit integer.

-Kevin P.

[SurfaceSurfer]

Kevin,

thanks for the info and the method of getting around it. I think I know how to implement your suggestion.

thanks again

SS