DAQmx initial read has flatline in waveform

[Deon]

Hi guys

I am struggling with an analog waveform write and read on CompactDAQ hardware. The first acquisition of the waveform has the first ~500 samples as flat DC values.

See waveform image and LabVIEW code below.

I've tried multiple DAQmx techniques and it doesn't matter whether it's a finite or continuous sample the first acquisition of the buffered data flat-lines for the first 400 - 800 samples, and is not dependent of the number of samples.

Can anyone help?

Many thanks, Deon

[santo_13]

What cDAQ modules do you use for AI and AO?

[Deon]

The cDAQ modules are specified on the LABVIEW diagram.

[Kevin_Price]

Your comment about starting the AI task before starting the AO task seems wrong.  Are you *sure* you get that error if all you do is swap the sequence of which DAQmx Start is called first?

As it stands, you have 2 or 3 notable contributors to what you're seeing.

1. The 9229 uses a Delta Sigma converter, which includes an inherent delay (according to its spec sheet) of a bit over 38.4 samples due to its internal digital and analog filtering.  So the first sample (captured at the instant of the first sample clock edge) represents the real-world voltage that was present at the wiring terminal ~38.4 sample periods ago.   A step change of the real world voltage won't show up at the converter output until ~38.4 sample periods after the step change happens.

   But at your sample rate of ~50 kHz, this aspect explains only ~0.77 millisec worth of what you see.

2. You've chosen to start your AI capture task *before* starting the AO task that generates the signal you want to capture.  It takes a little time to get the AO task fully into its active run state.  I don't know any hard figures on how long, but the ~15 msec you show doesn't seem shockingly large for a cDAQ system.  In other words, it's believable to me that this is the main culprit.

3. (Speculative, and an extension of #2 above).  The call to DAQmx Write puts the data into an application-accessible task buffer.  From there, it will be passed along to a "USB Transfer buffer" and then to the DAQ device's own hardware FIFO.  But that might not happen until after you call DAQmx Start for the task.  (I'm not certain about this, but even if true it probably would only account for a couple millisec or so.)

Recommendation:

- start the AO task before you even start configuring the AI task.  That will eliminate contributions from #'s 2 & 3 above.

- use knowledge of the inherent AI delay to ignore the first 38 or 39 samples.  You may need to experiment a bit to determine the better choice

-Kevin P

[Deon]

Thanks Kevin. A lot of good suggestions there.

Starting the AI task before the AO task is actually a hangover from when the VI was configured as Simultaneous sampling and the sync clock was ai/SampleClock. AI before AO became a requirement. I think this is also specified in the NI example.

I wasn't aware of the inherent delay in the 9229 but thought it must be something like that. Currently the delay is inconsistent at about 400 - 800 samples, but if I can make it consistent then I can use the DAQmx Read Offset property to correct.

I will go through your suggestions and see what I can fix and get back to you.

Thanks so much for taking the time to study my problem.

Best regards

Deon

[Deon]

Keven the error is returned only if you use the "DAQmx Is Task Done.vi" to check if the AO Task has completed.

With respect to your suggestion:

Recommendation:

- start the AO task before you even start configuring the AI task.

The situation becomes even worse:

It seems to capture the tail end of the waveform and then just noise.

And if you wait for the AO Task to complete, only noise data of less than 3mV is returned.

Stumped!!!

 

[Deon]

The best architecture is as I posted in the first code snippet, i.e. AI Start Task before AO Start Task.

But by changing the Read Samples from 5000 to 6000 I see that the full dataset of 5000 samples is acquired, but delayed by approximately 500 samples (this is not consistent however). See below:

Any ideas anyone?

[Deon · Accepted solution]

OK I think I have found the solution. The trick is to have Continuous Sampling for the AO Task and Finite Sampling just for the AI Task.

And then don't wait for the AO Task to complete but just stop it once the acquisition (AI Task) is finished. See below:

 

Full dataset is acquired:

Thank you Kevin Price for your suggestions. They got me on the right track .......

[Kevin_Price]

In the interest of clarity and making sure the right lessons are learned:

1. In your initial post, you configured the AO task to use the AI task's sample clock as its own.  That was the context for my suggestion to start the AO task first.

2. In msg #6 where you started AO first and "things got worse", you *ALSO* changed the timing configuration for the AO task to use the (always-present) onboard clock.  So output generation started *immediately* after calling DAQmx Start.

    If you had left AO configured to use the AI sample clock, the *task* would go into active mode when you call DAQmx Start, but no output generation would start until the AI Sample Clock became available -- i.e., later, *after* calling DAQmx Start for the AI task.

3. Your solution in msg #8 is probably not fully reliable.  AO and AI are not synced in hardware by sharing timing signals.  They're kinda sorta almost synced in software by making sure AI can't start until after AO starts.  (Though there's no guarantee how soon after AO that'll happen.)

I stand by my original suggestion where you would configure AO to use the AI sample clock (like in your original post), and then *also* make sure to start the AO task before starting the AI task (like in your subsequent posts).

As to Finite vs Continuous -- you'll still need to account for that 38-39 sample filter delay somehow.  If both tasks are finite, you probably need AI to capture an extra 38-39 samples more than the # generated by AO.

-Kevin P

[Deon]

Hi Kevin

Answers to your notes:

3. Your solution in msg #8 is probably not fully reliable.  AO and AI are not synced in hardware by sharing timing signals.  They're kinda sorta almost synced in software by making sure AI can't start until after AO starts.  (Though there's no guarantee how soon after AO that'll happen.)

This solution is more than adequate for my application as I just want the full 5000 samples of the sine wave to do ratiometric measurements on an LVDT. Only analog output waveforms are relevant.

I stand by my original suggestion where you would configure AO to use the AI sample clock (like in your original post), and then *also* make sure to start the AO task before starting the AI task (like in your subsequent posts).

This definitely does not work as only noise data is returned. The AO Task relies on the AI Sample Clock and if the AI Task has not yet started, no clock is available therefore no data is generated when the AO Task runs first.

Thanks Deon.