DAQmx writing task slow down my program by having multiple writing on the same array

[ZZ991]

Dear all, 

I'm using a PCIe6363 board to control a pair of galvo scanner to make a customize scan. I'm using the attach VI to control the galvo and a third analog output. I assign the initial values for the waveforms and synchronize them using the external clk and the trigger I provide to the board, and start a writing task. Then inside the loop I update the values for two of my outputs as the loop runs. My problem is that the output signal that I get is not what I am supposed to get, I should be a stair with 1.6 seconds duration but what I get is a stair with 2.1 seconds duration. If I remove the first writing task after the trigger DAQmx the duration of my waveform is correct but my waveforms are not synchronize anymore. I believe the issue is because I am writing on the same array/buffer multiple times inside the program. Any idea how I can fix the issue or increase the buffer size to be able to read and write from it in a more efficient way. 

[Kevin_Price]

Here's how you can help us to help you.  Branch each of the 2D arrays you write to a different graph on the front panel.  After running, goto the "Edit" menu and select "Make Current Values Default".  Then "Save For Previous Version..." back to maybe LV 2018 and post the resulting vi.  (A regular save is fine if using LV 2018 or earlier).   That will give us some realistic settings and data to look at.

Note that your AO channels are part of the same task, so if the output isn't "in sync" (however you're defining that), it's because the data you fed to the task wasn't kept in sync.

DAQmx can probably manage your attempts to write the full buffer contents repeatedly in a loop.  It'll know to replace the data gradually so that older data isn't overwritten until after it gets sent down to your AO DAQ device.  But I haven't stress-tested this capability so if you find yourself getting buffer-related errors, you may want to resort to writing and replacing only 1/2 or 1/3 buffer at a time.

-Kevin P

[ZZ991]

Thank you Kevin. Attached you can find my VI. I appreciate your help with it. Please notice that my clock is external coming from a 16KHz source, and my Triger is coming from a 240 Hz external source. 

[Kevin_Price]

Solution Summary:

    Instead of writing 64 samples at a time representing only 4 msec worth, try writing more like 25*64=1600 samples at a time representing 100 msec worth.   It'd be even better if you can predefine the entire 1.6 second AO pattern, write it once, and configure the task for Finite Sampling.

Explanation:

    The buffer size is set by the # samples you write to the task *before* starting it.  For you, that's been 64 samples.  By default, DAQmx will enable *regeneration* when you do Continuous Sampling.  That treats the buffer as though it's circular, so after delivering the last sample in the buffer it'll start over again from the first.

    Your code needs to be in the process of replacing the early contents of the buffer before the driver arrives at this "wraparound point".  If something slows your code such that you miss an opportunity, DAQmx simply regenerates the prior buffer contents again.

    Roughly speaking, the ratio (1.6 sec) / (2.1 sec) tells you how often your code succeeded in meeting your 4 msec deadline.  You'll greatly improve that success ratio if you write more data less often, extending your deadline out to something more like 100 msec.  You can also help yourself by not writing to your graph display in the loop.

-Kevin P