NI 9264 Analog Output Iteration duration doubled

[JICR]

Hello!

running the code below I expect the loop duration (T) to be around 1000ms, 2500 Samples/s at 2500 Samples per waveform. Although the duration is pretty much exactly 2000ms, I tried other samplig rates suchs 250S/s, 25kS/s and the duration is always twice as expected.

Also I notice the output amplitude will update about 5 cycles after I changed the amplitude value... Somehow it buffers the waveforms but I don't necessarily want that.

There must be something I don't know about DAQmx, what can I do to avoid the delays? Ideally I wish I could update the output amplitude on the next iteration.

Also I hope the loop duration to be ~1000ms

I'm using the NI 9264 card on a cDAQ-9178 chassis.

 

[GerdW]

Hi JICR,

---

@JICR wrote:

Also I notice the output amplitude will update about 5 cycles after I changed the amplitude value... Somehow it buffers the waveforms but I don't necessarily want that. 

---

Did you look for relevant example VIs in the example finder? Something like "Voltage (non-regeneration) - Continuous Output"?

[Kevin_Price]

To reduce *latency*, you need to consider both buffers between your app data and the real world.

1. The first buffer is the task buffer on your PC.  For your continuous sampling task, the size is set by the # samples you feed it on your first call to DAQmx Write.  (I am not sure I recall what the normal behavior is if you wire a value to the '# samples' input of DAQmx Timing.vi before your first call to DAQmx Write.)

2. The second buffer is the device's on-board FIFO.  You get to have *some* control over that using a DAQmx Channel property node known as the "Data Transfer Request Condition."   If you set it for "onboard memory empty", you'll get less latency and more risk of a buffer underflow.   With cDAQ, you may also need to explore nearby properties for USB Transfer.

-Kevin P