USB NIDAQ- 6001 Analog output fails for out put longer than 15ms

[parityviolation]

My NIDAQ Analog output fails for output longer than 15ms.

That is, if I queue a ramp from 5V to 0V the analog output will start the ramp and it will execute it flawlessly if the ramp occurs in less than 15ms. However any longerat a time after 15ms, typically 1-5ms, the ramp will be truncated. When the ramp stops the analog out channel will maintain the voltage at the time of the ramp stopping. 

If I change the sampling rate the number of samples before the analogout changes but the duration of 15ms is pretty consisent.

I have tried 

a) this will two different NIDAQ 6001 devices so it doesn't seem to be a specific device

and

b) on both channels ao0 and ao1

I am running the NIDAQ in session based control through Matlab. I have tried both Matlab 2018a and 2015a. There is no difference.

code below

s = daq.createSession('ni');

s.Rate = 1000;
addAnalogOutputChannel(s, 'Dev2', 'ao0', 'Voltage');

The video shows repeated runs of the code below note how the ramp does not end at zero. Note also how it terminates at different voltages, ie. times.

outputVector = [zeros(10,1); linspace(5,0,30)';  zeros(10,1)];

 queueOutputData(s , outputVector)
startBackground(s); 

anyone can help debug this ?

[Kevin_Price]

I don't know anything about the Matlab API into DAQmx functionality.  Here's what this problem sounds like to me:

- you create an output task and write your ramp data to it

- you start the task (which makes the ramp start generating).  (This can happen during the write, the LabVIEW API provides such an auto-start option).

- you *don't* wait for the ramp generation to finish

- you immediately stop and/or clear the task (which will make the ramp stop generating)

Be sure you allow enough time for the ramp to be fully generated before you stop or clear the task.  Typically this would be done with a finite sampling task where you can then (likely) call a DAQmx API function that will wait until the task is done, i.e., all the finite samples have been generated.

-Kevin P

[parityviolation]

Thanks Kevin, for the suggestion. If that is happening then something is stopping the task at a variable delay of more than 15ms after the "startBackground(s)" command is executed. I certainly am not executing any code.

Is there any way to look for this stop or clear on NI measuremend and automation?

[Kevin_Price]

I found this discussion, which somewhat suggests that you *should* keep executing some code after launching the task with startBackground(s).  Specifically, much of the sample code follows that launch with a while loop that waits on "s.IsDone()".

In LabVIEW, if the last thing my code did was start the task and then there was no more code to execute, the task would get stopped and cleaned up automatically.  I thought this was a function of the LabVIEW environment, but perhaps something similar is going on for you.

-Kevin P