Is it possible to generate a finite number of output buffer iterations using DAQmx?

[Kevin_Price]

billings11,

Part 2 of 2 (Due to forum error with large-ish message)

Re: Timed Loops -- yeah, I think your output buffer would need to contain multiple waveform cycles. And I could imagine some noticeable CPU time inside the timed loop to write those tens of kilo-samples to the output buffer, though I don't think the algorithm gets much more complicated.  I don't think the FFT's would co-opt the CPU and slow down the timed loop, but the timed loop may starve the CPU enough that the FFT's themselves bog way down.  And I'm not sure how timed loop scheduling interacts with DAQ calls.  Like you said, all the processing required for this timed loop solution does feel like a big price to pay.  If I were you I I think I'd also waste 2 AI channels to measure my AO.

Other annoyances where NI's DAQ drivers fail to provide a reasonable symmetry from input to output:  First and foremost, why can't I take a TTL waveform I measure in semi-periods with a counter and then recreate it on another counter?  Why don't counters have any buffered output capability? This also becomes a gripe with timed DIO. One of the touted features is "change detection" and you can, with some pain, set up change detection with another board's counter capturing timestamps whenever a bit changes while the DIO buffer captures the DIO port at the change instant. Kinda cool, until you realize that without hw-timed counter output, you can't use that measurement data to reproduce this digital timing pattern as an output stimulus. By comparison, the board & driver put out by Viewpoint Systems (one of NI's Alliance Partners, no affiliation with me) has a completely symmetric driver for input and output that simply makes a ton of sense.

-Kevin P.

[Kevin_Price]

Part 3 of 2

Sorry about the oversized fonts.  While I kept snipping down the message to get under the 5000 char limit, I would copy and paste all text into MS Word.  True to form, MS Word must've decided it had a better idea what my text font should be.

Oddly, even after I nibbled my way down to something like 4520 characters, I still got the over-5000 error and finally had to split into 2 posts.

-Kevin P.

[billings11]

Guess what?  They finally fixed it!

Through an apps engineer I was able to prove that this is fixed with NI-DAQ 7.5.  I was running the attached vi on DAQ 7.3 and it the bug was evident.  The TotalSamplesGenerated property always gave me the exact same number before and after the DAQmx Stop.  But this was wrong because the samples were being generated for a couple of milliseconds between the property node and the time the task actually stopped.  That time was enough to cause too much discontinuity for my system.

I was forwarded 7.5 by the apps engineer and installed it.  I ran the exact same vi and now the property node gets updated properly even when the task has already stopped.  I checked the number I got against the actual output voltage of the AO and it appears to be correct.

I don't know if they have even started shipping 7.5 yet.  I know I got an M-series card last week and they shipped 7.4 with it.  I was still running 7.3, so the bug might have been fixed in 7.4 already, but I haven't tried it so I can't be sure.

Kevin thanks for your help.  I actually used your vi's in my discussions with the apps engineer.  I used your counter idea to compare the true number to the Total Samples Generated property to prove that the property was wrong.  If someone has 7.4 on their machine and is curious try running this vi with a nice high sample rate and see if there is a difference between the two TotalSamplesGenerated properties.  If there is a bug you won't see any difference between them.  I know on 7.3 you can see an obvious difference between the property and the counter value, but on 7.5 they were the same.