LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Coincidental AO Pulse & Buffered AI

Hi,
Here is what I am attempting to do. I need to capture a waveform of some data comming from our UUT, using an analog trigger on the same data. However I also need to send a pulse to the UUT to tell it to begin generating data. This pulse needs to be sent after we have started aquiring data, so we don't miss any of the data. I would like to do both of these tasks using NI PXI-6071E MIO card. The order in which I currently have my code implemented is as follows:

AI Config
AI Start

AO Write One Update
AO Waveform Gen
AO Write One Update

AI Read
AI Clear

What happens when I run this is that the AI setup works fine, the pulse is sent fine, and the UUT begins outputting data, but when I call AI Read, it does not retur
n any data and eventually times out (assuming that it must have never triggered).

If I replace the AO code with code to make my DC Supply send a pulse, then everythings works as expected. However, the duration of the pulse is critical, and the DC Supply is not precise enough for our task.

I also tried replacing the MIO AO code with code that uses the NI PXI-6704 Analog Output. Like the DC Supply this won't be adequate for the job because it can't send a waveform, just single points with software timing. Interestingly though, this code showed the same problem as the MIO AO code - AI setup worked fine, pulse sent fine, UUT sent data fine, but AI Read never got any data. This is surprising to be because I was think that the problem was related to trying to get the MIO to do two things at once.

When using both AI and AO simultaniously, is there a particular order in which the vi's have to be called? (like don't call a AO config after you have started an AI acquisition, don't call
AO/AI clear until both tasks are done, etc)? Is there any other reason you can think of that would be causing an conflict, particularly, why would using another AOUT card affect the MIO at all?

thanks,
jackson
0 Kudos
Message 1 of 5
(2,917 Views)
Hi jackson.

I'm interested as to why you performed the AO Write one update. The AO waveform generator VI should be the only VI you need to output a waveform on the analog output. You input a waveform array (an array of output levels), and then an input to tell it how fast to update the output (10 points at 1000 points/sec would be 1/100th of a second output).

This should work, and it shouldn't change your analog input settings.

Is there any way you can post your VI here?

I'd love to take a look at it.

Thanks,

Mark
0 Kudos
Message 2 of 5
(2,917 Views)
Thanks for responding.

Here is what I was doing with the analog out pulse.
The user is providing a base level and a pulse level, and a pulse width. On my first stab, because I wanted to minimize the time spent in the VI, I used AO Write One Update to setup the base value, then AO Waveform Gen to generate a waveform whose update rate was the inverse of the pulse width, and contained two values - the pulse level followed by the base level. Lastly, because the base value could be anything, I sent an AO Write One Update with value 0 (after opening the relay between the MIO and the UUT channel), to put the output in a known state.

When I looked at this pulse on a bench oscilliscope it looked fine. However the MIO was not triggering on it. Following
along your hint, I removed the first AO Write One Update, and changed the waveform to (base, pulse, base). Now the MIO is properly triggering on the output, and the test is working. Perhaps the problem was that AO Config was being called between the AO Single Update and the AO Write.

So I can capture the pulse now, but am unsatisfied with how much time is spent in AO Wait (inside AO Waveform Gen). I would like the software to procede to the next task as soon as possible after the pulse has finished. Is there any vi I that I can call that will block until the pulse is done, or an interupt I can set up to tell me when it has completed? This may be documented somewhere - I will look into this some more this afternoon, and post if I find a solution.
0 Kudos
Message 3 of 5
(2,917 Views)
The AO Wait VI is there to basically pause until the pulse is done, then call AO clear to clear the AO buffer. Unfortunately, this also ties up the DAQ thread, and can cause problems.

Therefore, to get around this, there's a few ways. If you know your pulse is very short, you can save the taskID associated with your analog output, and just call the AI clear when it's convenient in your code. Of course, this means copying some of the code in AO Waveform Gen to get rid of the AO Wait and AO Clear VIs. That way, you can clear it without putting in a wait statement.

The AO Start VI doesn't take any time to run; it just tells the DAQ board, "start sending out the output values in your buffer at XXXX update rate". Then it finishes. The
refore, you can *immediately* start running other code.

I do this all over in my code -- with analog inputs and analog outputs. With analog inputs, you can use a VI in the Data Acquisition -> Calibration and Configuration -> DAQ Occurrence Config.vi, which will set up an occurrence (like an interrupt) at a certain time (like the buffer is full, or after XX scans, etc). Therefore, you can call AI Read when the interrupt occurs, which is much more efficient.

Hope that made sense.

Mark
0 Kudos
Message 4 of 5
(2,917 Views)
Thanks,
I got all the timing issues worked out now.

For future reference, I think I narrowed down the reason that the code was not originally working to the fact that the MIO AI would not trigger if I sent the pulse too quickly after calling AI Start. If I sent a waveform that was 10 ms low, 150 ms high, 10 ms low it would never catch it (even though my external scope saw it fine), but if I sent another waveform that was 50 ms low, 150 ms high, 50 ms low it would trigger on the rising edge just fine.
0 Kudos
Message 5 of 5
(2,917 Views)