It sounds like you're going to need to deal with the more general case of this problem.
If you are generating multiple signals that can have different phase, amplitude, and frequency and then need them all to change "smoothly" to some other set of waveforms that may start from a point that's discontinuous from where you left off, well, you'll have some work to do.
I suggest something like what I outlined back in msg #6. I think there's no way around some kind of rate-limiting or blending algorithm when you need to support the ability to transition "smoothly" from one arbitrary voltage where you left off to another arbitrary voltage where you start back in.
(Note: most common DAQ devices I've worked with *do* support the possibility of changing AO sample rate on the fly. The clock is configured during your call to DAQmx Timing and that rate will stay in effect unless you change it *explicitly* with a call to a DAQmx Timing *property node* to set the SampleClock.Rate property. Writing new waveforms with different "dt" values will *not* automatically change the actual sample clock rate.
However, changing the sample rate isn't going to solve everything for you. There's no straightfoward way to *synchronize* this sample clock rate change with progress in the buffer, so that the old rate is used for all old data and the new rate begins with the first sample of new data. And if this isn't perfectly synchronized, you'll still get discontinuities.)
There might possibly be a fairly advanced technique you could try, but it's definitely less straightforward. You would need a DAQ device that supports buffered counter output, such as an X-series board or other device based around the STC3 timing chip. Then you'd need to drive your AO generation from the output of such a counter task. And you'd need to feed the counter task with the same # of frequency elements as the # of samples you feed to AO.
I've never tried running a continuous buffered counter output task while occasionally writing new frequency data to it. I think it'll be supported but can't say for sure. If so, and if you do things exacatly right, this method ought to sync the sample rate change with the progress in the buffer.
However, it still isn't clear to me from the info you've given that this sync alone will be enough to maintain "smoothness". That will also depend on whether you impose some special constraints on the data you feed to the AO task to make sure the data makes a smooth transition from old data to new.
All in all, I think some kind of rate-limiting approach will be easier.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
