LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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).

 

  1. 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?
  2. 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?
  3. 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.
I really appreciate all the help so far. (I've been reviewing the various LV help files and tutorials as much as possible, but I'm quite obviously still at the novice stage.)
 
Regards,
Patrick 

  1. Code.JPG

 

0 Kudos
Message 11 of 22
(1,612 Views)

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:

Sonar_Example.png

 

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,

John Passiak
0 Kudos
Message 12 of 22
(1,585 Views)

John,

 

Thank you tremendously for all the help you've given. You'll certainly have a prominent spot in the acknowledgement section of my report.

 

I rewrote the code you created using the picture you posted, since doing that helped me learn more about how these various VI's function. My lab partner and I tested it yesterday, but unfortunately it wouldn't work as intended. Our time measurement always hovered around 400 us, deviating by tens of us each time the while loop repeated. Moreover, the 400 us time was relatively consistent, regardless of the values we put in for the loop delay or pulse duration (we kept the sample rate, freq., and amplitude constant).

 

We checked the hardware (the OR gate, comparator, and the amp we also built for the receiver signal), and all seemed to be working. We'll double check them on Monday (and over the weekend look at this code some more), but any ideas on why this might be happening?

 

Thanks,

Patrick 

0 Kudos
Message 13 of 22
(1,565 Views)

Hi Patrick,

 

I suppose all of the components in your system have a propagation delay, although I'm not sure if 400 us is reasonable or not.  If you move the receiver further away from the transmitter does the delay increase?

 

I'd have to imagine the bulk of this delay is coming from either the receiver/transmitter or from the comparator itself.  The delay of the comparator would be easy enough to measure by scoping the input and output. 

 

 

In any regard, you might want to try to compensate for the system delay by setting up an additional receiver/comparator.  This receiver would be placed directly next to the transmitter so it measures when the signal is first on the output of the transmitter.  Instead of starting the counter task off of the AO Start Trigger, we could use the output of the comparator which is next to the transmitter.  If the circuitry is the same on each of the receiver stations then the delay should be comparable. 

 

There are certain variables (temperature, tolerances of components, etc.) that would make the delays inconsistent.  It would be advisable to calibrate your system at known reference points before performing any measurements.  To do this, pick a few distances over the entire range of your measurement and perform a linear fit to map measured delays to exact distances.

 

 

 

If you post your code I can take a look to double-check for any problems with the DAQ implementation.

 

 

Best Regards,

John Passiak
0 Kudos
Message 14 of 22
(1,543 Views)

Hi John,

 

We appear to be having a problem with the AO Start Trigger. We disconnected all the hardware and wiring, but we kept the AO Start Trigger output (PFI6) connected to the CI (PFI9). We then ran the program (copied exactly as you'd posted it earlier). Instead of stopping with an error, it consistently returned about 3.9ms with small deviations, on the order of 0.1ms. (This was the same problem noted in an earlier post, though I mistakenly wrote 400us.) Again, these times were independent of parameters such as pulse duration, sampling freq., etc.

 

We'll try this again on a different lab station tomorrow to make sure it's not a problem with that particular computer setup. Assuming we get the same results, do you have any ideas on what may be causing this, especially since (I think) the start trigger signal is supposed to be 1 digital pulse? I'll be going over the trigger and export signal sections of the help files tonight, but we're also happy to try other software setups.

 

Regarding your idea about using another receiver as the start trigger: we'd need a way to use only the first rising edge as the trigger, even though several will be generated with each pulse (we'll need to generate several cycles to get a readable pressure wave).

 

Incidentally, we also rechecked the hardware using a function generator and scope, and found a consistent phase shit corresponding to a delay of about 8us. We repeated this using the receiver as the input (driving the transmitter with a function generator), and got the same delay. Although we need to figure out this AO Start Trigger issue first, we also hooked up the entire apparatus. However, the measured times varied wildly, changing by orders of magnitude every few iterations.

 

Thanks,

Patrick 

 

 

0 Kudos
Message 15 of 22
(1,527 Views)

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:

2010-05-04_104427.png

 

The problem can be explained from the following diagram showing how the buffered period measurement works:

 

2010-05-04_104632.png

 

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,

John Passiak
0 Kudos
Message 16 of 22
(1,506 Views)

Hey John,

 

Mostly good news with these changes. After some hardware tweaks, we were able to get the apparatus working in 1D. We actually noticed better results when setting the DAQmx Timing VI to 3 samples, then indexing out the 3rd element of the array. When taking only 2 samples and indexing out the 2nd element, we'd get the correct result every other iteration (the other half was bad data).

 

Our problem now is working with CI1 in addition to CI0. Keeping the exact same hardware setup which we'd just run error-free using CI0, but sending the OR gate output to CI1 instead (and changing the counter to Dev1/ctr1 for the CI Period VI), we always got 1 of 2 errors: -200079 or -200284. There wasn't any discernible way to predict which of the 2 errors would show up; the errors came up regardless of the AO parameters (pulse duration, time between iterations, etc.); and the problem occurred at 2 different lab stations.

 

284 had occurred a few times before with CI0, but was always the result of a bad hardware connection -- so we don't know how it showed up here when the same setup had just worked with CI0.

 

279 really stumped us. There are 2 suggested solutions we came across, but one of them (use CI0) can't be used b/c we need both CI's. The other solution is to start/commit the AO task before starting the counter 1 DMA acquisition. To that end, we tried putting a 2-frame flat sequence structure outside the loop, with the DAQmx Control Task VI for AO (still set to commit) in the left pane and the Control Task VI for the CI (also set to commit) in the right pane, but that didn't fix it. 

 

Any guidance on how to fix these issues would be greatly appreciated.

 

Thanks again,

Patrick 

 

0 Kudos
Message 17 of 22
(1,482 Views)

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):

 

2010-05-07_120757.png

 

 

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.

John Passiak
0 Kudos
Message 18 of 22
(1,457 Views)

Hey John,

 

Sorry to make this the never ending thread...

 

When were unable to use Interrupts with either counter task: it always returned error -200141. (We placed the Channel Property Node between after the Timing VI and before the Control Task VI.)

 

However, when we set AO to use Interrupts (again putting the Property Node right after the Timing VI) and keep C0 on DMA, things work just fine. Changing this to use C1 gives us that same 2 errors as before: -200079 and -200284. 

 

KnowledgeBase describes error -200079 as starting/committing AO during C1 acquisition, so it would make sense that we keep getting the problem since our program must be set to start C1 before A0. But I'm not sure why this is a problem with C1 and not C0, which we can start before AO w/o any problems.

 

Please let me know if you have any additional thoughts.

 

Regards,

Patrick 

0 Kudos
Message 19 of 22
(1,441 Views)

Apologies, that last post contained a few mistakes (I'm writing this from within the lab, moving back and forth).

 

Here's the chief problem: Using our 2D program and setting C1 to use Interrupts, we did get rid of errors -200279 and -200284, but we now get error -200141. I'm looking for support articles on it now...

 

 

0 Kudos
Message 20 of 22
(1,434 Views)