DAQmxWriteAnalog64 is blocking, must counters be running?

[afmstm]

We are using NIDAQmx and the DAQmxWriteAnalog64 function.  The application is written in VB6 so uses the C interface to NIDAQ.

We understand that DAQmxWriteAnalog64 is a blocking function, and that multiple calls will generate error 200292 if later calls do not wait until earlier calls are completed.  The NI message for 200292 is “Some or all of the samples to write could not be written to the buffer yet. More space will free up as samples currently in the buffer are generated.”

We are using counters to control the output of the buffer.  We use the clock rate of the counters to set the frequency of the output buffer waveform.

The question is this: 

If the counters are stopped, and then the DAQmxWriteAnalog64 function called, can the DAQmxWriteAnalog64 function complete if there is space in the buffer, or is the function suspended/blocked until the counters are restarted, irrespective of the state of the buffer?  

This is a subtle point, let me restate it another way.  Is the following pair of statements true:

If room in the buffer is available, the function should complete whether or not the counters are running.

If not enough room in the buffer is available, then the function should not complete whether or not the counters are running, and it should raise error 200292.

Thanks.

[csparksfly · Accepted solution]

Hi afmstm,

I’m not entirely sure if I’m interpreting your setup correctly. From what I understand, you are using a counter output as a sample clock for your analog output, such that each time the counter output pulses, a new data value is output. If this is the case, then when the counter is stopped, your device will not output any more data. If there is room in the buffer, you can write additional data to the buffer, but that data will not be output unless the counter is running. Please let me know if I misinterpreted your question.

Christine

Applications Engineer

[afmstm]

Reading your reply, I think you have answered it.  Just to be clear, if the counter is NOT running, AND there is room in the buffer, then the call will succeed.  

I am chasing down a bug that is generating random 200292 errors at rare intervals.  The application does start and stop the counter.  It's non-deterministic, so I am having a hard time isolating and repeating the bug.  It appears to require a number of factors to happen before it occurs.

Thanks!