11-01-2023 10:53 AM
Hi everyone,
I am currently working on an application which uses the DAQmx C API. The goal of the project is to continuously stream data out of the analog out channels.
I am able to write a finite set of buffered data without any issues (both in the finite and continuous/repeated modes). However, the desired behavior is as follows; during a buffered write the next set of data is being computed, before the buffered write completes I'd like to "queue" up the next set of buffered data, such that it plays out of the analog out channel without any discontinuities. Essentially streaming continuously varying data out of the analog channels without having an interruption in the output waveform. With the trade off being the buffer size, and how fast the next buffer is able to be computed.
I have read through all the DAQmx C API documentation, and the closest I can find is the "unbuffered/DAQmx_Val_HWTimedSinglePoint" mode. However, this results in far slower sampling rates (as well as significant jitter introduced by the software controlled nature of that mode).
Just looking for any tips or guidance on the best way to accomplish this (or if this is even possible with this hardware).
Thanks!
Solved! Go to Solution.
11-01-2023 11:31 AM
HWTSP mode is for control-related applications and is not for streaming,
What you need is first setting to Non-Regeneration Mode
int32 __CFUNC DAQmxSetWriteRegenMode(TaskHandle taskHandle, int32 data);
Then just keep writing new data using any write function.
11-01-2023 12:18 PM
Appreciate the response!
I was not aware of the Non-Regeneration Mode, thanks for pointing that out.
So, is the below correct for setting up timing for using this mode, or do I need to use DAQmx_Val_ContSamps instead of finite?
DAQmxCfgSampClkTiming(task, "", samplingRate, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, numberOfSamplesPerChannel);
Then, after configuring timing, I'm assuming the next step is to write the initial buffer using the below code snippet BEFORE starting the task?
DAQmxWriteAnalogF64(task, numberOfSamplesPerChannel, 0, 10.0, DAQmx_Val_GroupByScanNumber, data, NULL, NULL);
Then it sounds like I can just use the above function call to write the next section of data.
But do I need to start/stop the task in between writes? I believe I tried this and without stopping the task I was not able to write new data properly. This was without Non-Regeneration Mode, so maybe this changes the behavior?
Thanks again for the help.
11-01-2023 02:41 PM
do I need to use DAQmx_Val_ContSamps instead of finite?
It depends if you want the program to stop automatically after a finite number of samples or until the user stops it.
I'm assuming the next step is to write the initial buffer using the below code snippet BEFORE starting the task?
That's correct. And you can keep writing new data to the buffer. Make sure you use the correct combination of sampling rate and number of samples per write to prevent buffer underflow. See Understanding and Avoiding NI-DAQmx Overwrite and Overflow Errors. The actual possible sample rate and number mainly depend on the bus type of your module. For instance, PCIe or PXIe is able to stream data at much faster rate than USB or Ethernet device.
But do I need to start/stop the task in between writes
No, you don't have to.
11-03-2023 10:03 AM
Tested your recommendations and all is working great. Appreciate the help!