07-27-2016 08:11 PM
I have a sequence of output voltages that I need to update every 1/60th of a second. Each sequence must stay synchronized to an external trigger and be driven by an external clock. The program is in c++.
These are my steps to setup the task:
1) DAQmxCreateAOVoltageChan
2) DAQmxSetWriteAttribute : DAQmx_Val_DoNotAllowRegen
3) DAQmxCfgSampClkTiming: DAQmx_Val_FiniteSamp (And set the external clock signal)
4) DAQmxCfgDigEdgeStartTrig: The rising edge of my external trigger
5) DAQmxSetTrigAttribute: DAQmx_StartTrig_Retriggerable
If I write samples too slow I get the following message:
"The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated."
I understand this message and this is the behavior I want.
My question is: What happens if I write the new samples to fast, i.e. before the previous ones have been displayed on the output channel? Will this give me an error or does the software allow me to overwrite samples in my output buffer?
Solved! Go to Solution.
07-27-2016 08:15 PM
Or does the previous write block program execution until it finishes, essentially not allowing me to overwrite my own samples in the analog output buffer?
07-28-2016 06:58 PM
Hey juliebert,
I looked into this a bit and wasn't able to find too much about it. My expectation is that it will not let you overwrite samples, as DAQmx will expect that you put those samples onto the buffer with the intention of reading them off. Therefore if they haven't been read off and get overwritten, it would take that as an indication that things aren't working as intended and throw an error. I'm just trying to find some information to confirm if that is the case now. I'll let you know what I find.
07-28-2016 07:19 PM
Thanks for checking. I couldn't find any information on this either, which is why I've posted to the forum.
I've launched a cpp thread that is looping and writing to the analog output each time through the loop. I'm keeping up with the output generation becuase I'm not getting an underflow error, but since I'm not sychronizing my Write commands with the hardware trigger (I'm just writing as fast as I can) I don't know if my loop is going too fast and overwriting the buffer. I would really like to know what exactly happens when I call the Write command multiple times given the configuration outlined in my first post.
07-29-2016 09:25 AM
The DAQmx driver has enough smarts built in to prevent you from overwriting values in the buffer that haven't yet been D/A converted to the output pins. When you make a call to Write values that would naturally "want to" overwrite those values, the function call will block and not return until enough samples have been D/A converted to make room for the new ones you're writing to the buffer.
In short, the driver does what it can to make sure that every sample you Write into the task's buffer will get D/A converted exactly once. It will throw errors if you don't allow regeneration and the task wraps around to "want to" D/A convert an old value for a 2nd time. If you try to write values to the buffer before the task is ready (this is your actual situation), the request to write will just kinda wait until room frees up for the new values or until the timeout expires.
-Kevin P
07-29-2016 01:47 PM
Thanks Kevin. Exactly what I wanted to know.
Is there some way for the Write command to signal when it's ready for the next set of data instead of just calling it again early and forcing it to wait?
07-29-2016 02:40 PM
I'll echo what others have said here. DAQmx will not let you write samples to the buffer until there is enough empty space to do so - hence the timeout input on the DAQmx Write function.
There are a couple ways to go about writing only when the buffer is ready for the next set of data:
P.S. - if you're using the C API, use the DAQmxRegisterEveryNSamplesEvent function to register this callback.