Needs clarification about DaqStream.WriteRegenerationMode

[pierrechatelier]

Hello,
I am using the .NET DAQMX API.
I am currently able to generate analog samples, but I need clarification about DaqStream.WriteRegenerationMode (which is set to AllowRegeneration, by default and in my project).

When I want to output a periodic waveform, I precompute a buffer of samples, start the task, and use analogMultiChannelWriter.Write() in a loop, waiting the duration of a waveform cycle between each iteration. It works.
If the buffer is small enough, I can set AOChannel.UseOnlyOnBoardMemory to true, write *once* to analogMultiChannelWriter before starting the task, then start the task, then put my thread to sleep, and it works : regeneration occurs automatically.

What I don't understand is when AOChannel.UseOnlyOnBoardMemory is false, it does not behave the same. If I start the task, write *once* to analogMultiChannelWriter, and put my thread to sleep, the cycle is emitted only once. Is there something special to tell the system to re-emit the same buffer without calling analogMultiChannelWriter.Write() again ? Do I still have to handle the wait of one cycle myself in a loop ?

[Jun']

    Hello Pierre,

Were you able to use your AO as you intended?

I've found some documentation about it; Although base don LabVIEW the concept remains DAQmx :

Optimize the Speed of My Changing Analog Output Task in LabVIEW
Analog Output Regeneration Modes in DAQ

I hope it helps,

M-Junior

[pierrechatelier]

No, I still didn't get any documentation explaining why I *have* to call Write() explictely while I expect the regeneration to do that automatically.

[pierrechatelier · Accepted solution]

I think I have found the solution :

it works, not when I put my thread to sleep (with a sleep or some mutex), but when I block my thread by calling task->WaitUntilDone()

In that case, the regeneration occurs.

I have also discovered (it is not stated clearly in the doc) that WaituntilDone() won't be interrupted by a task->Stop() (in another thread of course), but by a task->Control(Abort)