DAQmx ANSI C application error -200018

[carlosjbb]

I am running experiments with the modified example ContGen-IntClk.c to generate 60 Hz analog sine waves on 9 channels. I am using three 9263 DAQ modules and cDAQ-9174 chassis. The program runs fine with the equipment under test detecting the module's output signals. After sometime, minutes to hours,  the programs stops with the error -200018. I have tried changing the sampling rate  and number of samples using the formula:

# of samples = (sampling rate) * (sine wave period)

without success. I tried onboard memory and the signal stayed up for more than two days until stopped.  However, onboard memory does not allow making changes to the signal which I must do as part of my test. I suspect we have a communication glitch between the PC running the program and the chassis.

I am looking for some insight as to what I can change in the attached C program to make it more robust to communications glitches.  

[ShamWOW!!]

Hello,

You are correct in that using the onboard memory will not allow you to change the signal on the fly. But when you receive the error -200018, it usually has to do with the transfer mechanism between your computer and the cDAQ output, and specifically this error occurs when the device requests memory as its onboard FIFO needs refilling, but the data is not yet available on your computer.

This is why the error happens sometimes, from minutes to hours. If there is anything at all that might be using up CP, stopping other applications may help with your performance. 

The following forum goes into this some more, and implementing the change in data transfer may make the system more reliable.

https://forums.ni.com/t5/Multifunction-DAQ/poor-analog-output-performance-error-200018/td-p/1525156

Essentially, onboard is going to give you reliability without allowing you to change your signal. Using the computer's buffer will rely on the computer's speed for reliability when transferring signal data from the computer to the cDAQ. It's a tradeoff in this case.

[carlosjbb]

Thanks for the post. After reading the post I realized that our sampling rate of the 60Hz might be too high. I ran some experiments  and found a sampling rate that acurately simulated the target signals but it would only run for a short time. I added some buffering based on a sample NI program "ContGen-IntClk.c" buffering one second worth of data.  The program has been running for 2+ days without any errors. In my program I am using function DAQmxRegisterEveryNSamplesEvent that call a function after writing nsamples. Is there a recommended approach for how much data to buffer e.g 0.5 sec or 1.0 sec?