Counter Problem at low sampling rate

Question

What I am trying to do is to count the input from the camera and generate the number of pulses depending on the delay and interval. At the rate of 33ms the program works perfectly but if the sampling rate is 150ms it generates 2 pulses at a time. Is there a better solution to my problem ? Am I doing anything wrong ? Is it a problem with the loop timing or acquisition timing? I have attached the program. What puzzles me is that it doesnt work if the rate is lower! Please HELP.
Thanks 
p.s. I am very new to LabView so please excuse my ignorance.
Attachments:
CoolSnap.vi ‏142 KB

Answer 1

Hello sha33,
Thank you for getting back to me with more information. After looking through your code once more, I believe I have found the issue. Since this application is timed entirely in software, it is based on how quickly your operating system can run the program, and thus cycle through loop iterations. Since you have no Timing VIs in the program, this loop is running as fast as possible. Now, in the 33 ms case, you are getting a TTL edge a lot faster, so the DAQ assistant is updating its count faster as well. Lets say hypothetically that your loop is iterating at 60 ms. This means that every time you run through the loop your DAQ assistant will read the updated count value, and since you are counting every 33 ms, your count value will have updated.
Now let's look at your 150 ms TTL signal. This is significantly longer than the 33 ms signal in the previous case. Lets say hypothetically your loop is running on average at 60 ms again. This time, your edge will come in and the counter will increment, generating a pulse with the second DAQ assistant accordingly. Now your loop will run through again 60 ms later but your next edge on the 150 ms signal is still around 80-90 ms away. This means that your DAQ assistant will return the same count value as the last iteration, and once again a pulse will be generated.
Obviously the numbers I used for the loop iteration timing are hypothetical and entirely dependent on the operating system and its resources (i.e. it will run slower with an MP3 or Movie playing in the background). My suggestion would be to use a timing VI such as Wait Until Next ms Multiple to clock your loops more consistently. The goal would be to make sure that your loop is repeating faster than your counter is updating. Alternatively, you could account for the possibility of no counter input in your overall application to prevent a false positive.
Let me know if I can clarify any of the above information, or if you have any additional questions related to this issue.
Regards,
Chris Behnke
Sr. RF Engineer
High Frequency Measurements