LabVIEW
Measuring elapsed time
Hi John,
I'm going to build external comparators for the two input channels. However, I have a few questions about how to implement the actual code. I'll keep my questions to 1D for now (i.e. a 1 analog output driving the transmitter, 1 digital input from the comparator attached to the receiver).
- When you say Export the Analog Output Start Trigger, do you mean use LV to have the CI "see" the start trigger as the first rising edge? If you mean physically connecting the output to an OR gate (via a comparator), that could introduce physical problems: the OR gate could go HIGH two or more times (since we plan on generating several cycles of the 40kHz wave in each pulse). The CI would then measure the time between two rising edges caused by the output alone, instead of measuring the time elapsed between sending and receiving each signal. How can we get around this?
- A similar issue: we need to have the CI Period VI ignore anything past the first rising edge from the receiver's comparator (until a new 40kHz wave packet is sent out). What VI are needed for this?
- Below is the code so far (again, for 1D). I set the AO to generate only 6 samples (just under 1 period of a 40kHz wave) to avoid the problem #1 above, though I'll need to test it tomorrow to see if the receiver can still pick up a signal. Also, we aim to have this code (well, its improved version) run at about 100Hz. Can that be accomplished with a simple timed loop, or should we take another route? Please let me know if you see any additional faulty code.
Hi Patrick,
You picked a tricky application to get started with. It's a bit hard to explain in words so here's a VI Snippet showing how you could configure your program if you want to use the counters:
I think this should work for one channel. Adding another channel would involve creating another parallel thread for the 2nd counter task.
I don't have a convenient way to convert to 7.1 at the moment, but I did save the VI back to LabVIEW 8.0 and attached it to this post. Now that I notice that you're on LV 7.1, I should probably mention that X Series boards are only supported in DAQmx 9.0 and later which doesn't have support for LV 7.1.
To answer your questions:
1. The CI should be connected to the output of the OR gate (Start Trigger + Comparator Output).
-AO will be re-start every time you need to generate a pulse. This gives a single pulse of AO Start Trigger at the very beginning of each pulse output.
-The result of the comparitor will oscillate with your signal and will give multiple edges once the signal is received.
We start the counter right before the AO task so it is armed and ready when the start trigger comes (the first edge the counter sees).
2. The Implicit Timing function above ensures that we read back the first sample. When configuring Implicit Timing, we actually latch a sample into a buffer on each edge of the input signal. The very first sample read back from the buffer will be the first period of the waveform. We can ignore the 2nd sample (2 samples is the minimum amount allowed for Finite tasks). When the counter task is restarted this gives us a fresh buffer for the start of the next acquisition.
3. I would use the code posted above. I was able to keep the SW loop running on my 6070E at ~100 Hz (it was the closest I had immediately available that is similar to your 16E-4).
Anyway, I hope this gets you started on the right track. If you have any questions about it please post back--this application isn't exactly straightforward (especially if you're new to our hardware). If you need the VI in 7.1 I can probably find a system to downconvert it.
Best Regards,
Hey Patrick,
My mistake... the program requires a slight change. You need to modify the portion that performs the read. Change the read to a multi-sample instance, and index out the 2nd element of the array rather than the first:
The problem can be explained from the following diagram showing how the buffered period measurement works:
The E Series board (and most M Series boards) do not automatically discard the first sample. This sample represents the time between when the counter is armed to when the first pulse is received. The ~4ms you are seeing is likely the time it takes to start the AO task. I guess I've gotten used to working with our newer X Series boards which discard this extra sample in the hardware.
You'll still have some added latency from the transmitter/receiver and comparitor, but hopefully that should be relatively constant and can be calibrated out. You're absolutely correct about the receiver as a start trigger generating too many pulses--the DAQ hardware would require a single pulse.
Try making the above change and let's see what the results are.
Best Regards,
Hi Patrick,
Another way to get around error -200079 is to use Interrupts instead of DMA on your counter task. You can change this with the following channel property node (before the task is committed):
Error -200284 is a timeout error which means that the device is not receiving enough pulses (the read will wait until the desired number of samples are available or the timeout is reached).
It sounds like error -200079 is coming from the AO thread, while -200284 is coming from the counter input thread (if the AO is not operating, then no pulses will be received and the counter read function will timeout).
I'm a bit stumped that you get better results when looking at the 3rd sample. If it works consistently then I guess there isn't a problem, but you might want to scope the output of the OR gate to see what the DAQ card is actually receiving, perhaps you are getting ringing needs to be filtered out.
