LabVIEW
Measuring time between digital pulses
Solved!
Hello,
For a non-critical timing application I need to measure the timing interval between consecutive TTL pulses, ranging in the order of 0.5s to a couple of seconds, with a low accuracy of +/- 10 to 50ms. The interval to be measured ranges from the rising edge of the first pulse to the rising edge of the next one, and so forth.
I have multiple input lines which I need to process. Because it's a low cost non-critical set-up I don't want to use digital counters for each line, so I'm working with a USB6008 DAQ and have connected the TTL input lines to the digital inputs of the device. Software timing will be sufficient.
I have found a nice example VI on the discussions forums which pretty much does the same, only it uses user input in stead of the DAQ Assistant. The VI works by counting the time the program spends in a while loop. I have replaced the user input with the DAQ Assistant output (one channel) in the hopes it will still work.
When I execute the program in the 'run once' mode, it appears to work just fine. However, in 'run continuously' it only measures a very small interval, probably just the time between two samples. I think it got something to do with using a while loop in combination with the DAQ Assistant. Anyone got any suggestions how to solve this problem?
Thanks!
Ok...first of all, you should never use the "run continuously" button. I wish that NI would eliminate it, but I am told that it is occasionally useful for debugging. If you want your program to run over and over again, use a while loop with a "stop" button.
If I am reading your code correctly, you capture your initial time, then collect DAQ data. When one of the channels is "T", you stop your loop and capture the end time. (By the way, why are you converting your array to a cluster? Why not just index the appropriate channel out of the array directly?)
Since you want to capture the time between consecutive pulses, you need to know when a transition has occurred...i.e. when your digital line has transitioned from F (no pulse) to T (pulse is starting). That will give you your rising edge. Right now all you're doing is looking for a T value -- so you have no way of knowing whether you're looking at the previous pulse still, or a new pulse. You're also burning 100% of your CPU with the way you have your program set up.
You need a small loop delay so that your VI doesn't hog 100% of your CPU time. Since you can live with a precision of 50msec, that's what I suggest you use.
See attached picture to give you an idea of how to set this up. It will probably need some refining, but it should point you in the right direction.
Hope this helps.
