LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

First sample out of sync while running synchronous input/ouput using DAQmx

Solved!
Go to solution

Hi,

 

I am using one of the example vis "Multi-Function-Synch AI-AO.vi" to run a synchronous Analog Input (AI)- Analog Output(AO) operation on one of my test devices. I find that the first sample of the waveform I read from my AI is before my AO starts its operation.

 

Let's say I am sending a waveform of 10 samples to my AO which is a square wave with a frequency set in such a way that, I expect the first 5 samples to be positive, and the last 5 to be negative. Instead, what I see is that the first sample being read on my analog input is always the state of AO before I run the program. For example, the AO is outputting 0V. If now I start my program to output a square wave of 1V, I read the first sample as 0V on my AI, and the samples 2 to 6 as 1V, and samples 7 to 10 as -1V. I do not know why it doesn't start from 1V.

 

I suspect I am doing something that is a very common mistake. I am attaching my vi, just in case. It has already the output saved from my previous measurement.

0 Kudos
Message 1 of 7
(2,562 Views)

you are sampling 100hz signal with sample rate of 100hz. sampling freq > 2fmax.

Increase sample rate.

bp
0 Kudos
Message 2 of 7
(2,521 Views)

Naidhili wrote: I find that the first sample of the waveform I read from my AI is before my AO starts its operation.

This is expected.  After all, it takes time for a signal to output from the ADC and then get to the AI channel.  By the time the ADC is done, the AI channel has already taken the sample.  So what you are seeing is correct.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 7
(2,511 Views)
Solution
Accepted by topic author Naidhili

Agreed, it's behaving as expected, but you *can* configure differently and get the behavior you want.

 

1. If AO and AI are using the same sample rate, I would strongly advocate that you simply share a sample clock between the tasks.  There will then be no need for triggering and some of the additional timing subtleties *that* can introduce.

   Designate one as the master task, share its sample clock over to the other task, and be sure the master task is started last.

 

2. If you want your 1st AI sample to show the system response to the 1st AO sample, you need to give your system time to respond.  You can do this by setting the AO task to sample on the leading edge of the sample clock (probably rising) and the AI task to sample on the trailing edge (probably falling).

 

3. You can get more control over this offset timing by setting up a non-square pulsetrain that acts as sample clock to both tasks.  It should be started after both AO and AI.  You can then define the pulse duty cycle to put more time between the AO's leading edge and the AI's trailing edge for a given sample rate.

 

Here are a couple different threads I've been in that discuss this more.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 4 of 7
(2,504 Views)
@crossrulz wrote:

Naidhili wrote: I find that the first sample of the waveform I read from my AI is before my AO starts its operation.

This is expected.  After all, it takes time for a signal to output from the ADC and then get to the AI channel.  By the time the ADC is done, the AI channel has already taken the sample.  So what you are seeing is correct.



I thought the time for the physical signal to reach AI should be in ns though so I didn't expect a lag in the first place. And strangely enough, no matter what sampling rate I use, the lag is always of a single sample. 

0 Kudos
Message 5 of 7
(2,492 Views)

@bharathp10 wrote:

you are sampling 100hz signal with sample rate of 100hz. sampling freq > 2fmax.

Increase sample rate.


I don't see how that is a problem.  After all, I am only interesting in discrete samples and not the frequency information of the whole waveform. I can actually sample exactly my output waveform except that there is an offset of 1 sample.

Message 6 of 7
(2,489 Views)

@Naidhili wrote:
@crossrulz wrote:

Naidhili wrote: I find that the first sample of the waveform I read from my AI is before my AO starts its operation.

This is expected.  After all, it takes time for a signal to output from the ADC and then get to the AI channel.  By the time the ADC is done, the AI channel has already taken the sample.  So what you are seeing is correct.



I thought the time for the physical signal to reach AI should be in ns though so I didn't expect a lag in the first place. And strangely enough, no matter what sampling rate I use, the lag is always of a single sample. 


For the sake of discussion, I wanted to correct myself and say that this lag could be more than a single sample in case you are sampling at very high rates (500K)

0 Kudos
Message 7 of 7
(2,475 Views)