Using USB cDAQ-9172 with AI&AO, output callback is not performing correctly

[RDVincent]

I'm new to NI DAQmx programming, but I've recently downloaded the NI-DAQmx development package and adapted an example program to attempt to allow me to run simultaneous analog input & output at 2KHz using the 9263 and 9215 modules on a 9172 chassis.

I would like to be able to vary the output waveform at will in something approaching real time. Not knowing exactly how to start, I used DAQmxRegisterEveryNSamplesEvent() to use an output callback, as I hoped this would allow me to modify the waveform by rewriting the output buffer during the callback.

However, I find that with this setup, I get about half as many output events as input events, and therefore I cannot modify my output waveform in anything like real time. I have no clue why this would be. I query the task for the total number of samples generated, and I see that value increase about twice as fast as I would predict based on my output callback frequency.

If I'm doing something wrong, or if there is a better way to do this, can someone give me a hint? Otherwise, can anyone suggest a possible workaround? I have enclosed my example program.

[tnek]

Hi RDVincent,

Could you post your project by any chance? Another way of accomplishing the dynamic analog output is to use non-regeneration and write new data to the buffer each time it is emptied. If you want to take a look at this method, you can find some good discussion and an example program here.

Regards,
Kent
Applications Engineer

[RDVincent]

I'm not sure what you mean by my "project". I did post my source code, which I build with a simple batch file that looks like this:

cl -I "c:\Program Files\National Instruments\NI-DAQ\DAQmx ANSI C Dev\include" %1 "c:\Program Files\National Instruments\NI-DAQ\DAQmx ANSI C Dev\lib\msvc\NIDAQmx.lib"

So is there any obvious explanation for the behavior I'm seeing? Or am I just approaching this all wrong?

[tnek]

Hi RDVincent,

Sorry about that. I assumed that you were using LabWindows/CVI since there were CVI callbacks in your code. If you are using a command line project, these callbacks will not work. There are two ways to get around this problem. You could either run this code in LabWindows/CVI or you can remove them from your code. A good place to begin if you wanted to use ANSI C and DAQmx would be the ANSI C NI-DAQmx shipping examples. The location of these examples vary but you can use the article here to find them.

Regards,
Kent
Applications Engineer

[RDVincent]

Now I'm really confused. I am using the ANSI C NI-DAQmx documentation and examples, which is where I learned about these callbacks. In fact, the DAQmx ANSI C example I started from, ContAcq-IntClk.c, uses the input callback, but I added the use of the output callback. As I mentioned, the input callback seems to work just fine.

From the documentation I assumed that these features were intended to be accessible from any C program. If this is not the case, where are the examples and documentation that can be used in an arbitrary C program?

[tnek]

Hi RDVincent,

Sorry about the prior posts, you are correct in saying that they are in the provided ANSI C examples and that they will work for what you are trying to do. The CVIcallback is pretty much just a calling convention (see post here for more details).

I ran your code with a PCI-6251 and it seems to work fine. I will try to grab a cDAQ chassis with the modules you said and try it to see if I can replicate what you are seeing.

Regards,
Kent
Applications Engineer

[Brad_K]

Hi RDVincent,

I gave your program a try with a USB-6229 and saw the same thing as you did. I think that it is caused by regeneration of old samples.

Your program doesn't explicitly set the output buffer size, but writing CSOUT samples before starting the task should set the output buffer size to CSOUT samples. DAQmx shouldn't transfer more than half of the buffer at a time to avoid starving calls to DAQmxWrite(). Your OutEveryNCallback() function is writing CSOUT samples on each callback, but only half of the buffer can be written at a time. I suspect that the call to DAQmxWriteAnalogF64() always blocks, waiting for the other half of the buffer to be writable.

If I call DAQmxSetWriteRegenMode(outHandle, DAQmx_Val_DoNotAllowRegen) before starting the tasks, the output task is always 8000-9000 samples ahead of the input task, which makes sense given that the cDAQ-9172 has an 8191-sample analog output FIFO. In addition, with regeneration disabled, if the application doesn't write data quickly enough to keep the FIFO from becoming empty, the output task will report a FIFO underflow error. However, if you don't want your output to be delayed by 8191 samples, the FIFO may be problematic.

Brad

Message Edited by Brad K on 03-10-2008 08:06 PM