Error -200284 every 49.7 days on reading analog input with C API in DAQmxBase

[CBest]

Hi All,

I have a control program using the C API of DAQmxBase for controlling hardware through the NI USB-6008, which one of its jobs is to read analog signals continuously (configured as DAQmx_Val_ContSamps in the AI task).  I have multiple systems running the same program on each.  The program encounters the error -200284 every 49.7 days on DAQmxBaseReadAnalogF64, and then I need to force restarting the program for it to get back to work.  The most suspicious thing is that all systems encounter the error at the same time, regardless their running time and system clock (both the time from 'date' and 'hwclock').

According to some discussions, it seems to be related to the max value of the 32 bits unsigned integer, used as a counter or ticks in microseconds in the driver.  Unfortunately, all these discussions are for the VI in the LabVIEW.  In my case, it's in C with Linux, which I can't find any discussions on the issue under this environment.  I don't know if the same usage of counter or ticks exists in the DAQmxBaseReadAnalogF64.

I also have another system running the same program, same environment but with DAQmx 8.02 and NI PCI-6221.  I've never had this problem on this system.

Here are the details on my system:

System information:
 . OpenSuSE 11.1 with DAQmxBase 3.3 / OpenSuSE 11.3 with DAQmxBase 3.5
 . Intel Desktop Board D525MW or similar with ATOM processor
 . 1 GB RAM
 . NI USB-6008

Symptons:

 . Error -200284 every 49.7 days on DAQmxBaseReadAnalogF64.
 . Regardless when the program starts and the value of system clock (both the time from 'date' and 'hwclock').  For example, the program on one system starts at 1:00:00 today, and the program on another system starts at 2:00:00 today.  They both fail at 12:00:00 (just an imaginary time), at the same "absolute time."
 . Regardless the OS version and the DAQmxBase version.
 . Regardless when the OS is booted.
 . No memory leak observed (constant value for the %MEM in the 'top' command).

Code sample:

/* Called once on initialization */
void create_task() {
    DAQmxBaseCreateTask("", taskHandle);
    DAQmxBaseCreateAIVoltageChan(...);
    DAQmxBaseCfgSampClkTiming(..., DAQmx_Val_ContSamps, ...);
    DAQmxBaseCfgInputBuffer(taskHandle, 200000);
}

/* Called every 10 seconds */
int read_analog_signals() {
    DAQmxBaseStartTask(...);
    DAQmxBaseReadAnalogF64(...);
    DAQmxBaseStopTask(...);
}

If anybody could provide any insight to it, I would be really appreciated.  It's embarrassing to have a program crashing every 50 days...

Thank you very much,

Daniel

[Steven_K.]

Hi Daniel,

Could you clarify the timing aspect if the issue you are seeing? Are the two systems starting their DAQ program at the same time, but the system clocks are different? When the error occurs, were the programs running for the same length of time (49.7 Days)? Is it possible that an external event is causing them to stop at the same time?

[CBest]

Hello Steven,

The two systems are not starting at the same time, and the system clocks are different because some of the programs are deployed to the computers in different countries in different time zones, and the clocks have minor drift.  When the error occurs, the programs were not running for the same length of time, but definitely less than 49.7 days.  I can see this trend from my logs for the past half year.  I can't say that it's exactly 49.7 days but it's close.

For each iteration, the program basically reads all the values from the analog input and necessary digital input, calculates some values, and then sends output to the necessary analog output and/or digital output.  I don't have any configuration for the external event (from my understanding of the C API).  I only use the basic I/O functions.

I've filled out the parameters in all my function calls.  Hope that it would be helpful:

/* Called once on initialization */
void create_task() {
    DAQmxBaseCreateTask ("", &taskHandle);
    DAQmxBaseCreateAIVoltageChan (taskHandle, "Dev1/ai0:7", "", DAQmx_Val_RSE, -10.0, 10.0, DAQmx_Val_Volts, NULL);
    DAQmxBaseCfgSampClkTiming (taskHandle, "OnboardClock", 500.0, DAQmx_Val_Rising, DAQmx_Val_ContSamps, 1000);
    DAQmxBaseCfgInputBuffer(taskHandle,200000);
}

/* Called every 10 seconds */
int read_analog_signals() {
    DAQmxBaseStartTask (taskHandle);
    DAQmxBaseReadAnalogF64 (taskHandle, 8000, 40.0, DAQmx_Val_GroupByScanNumber, buffer, 8000, &points_read, NULL);
    DAQmxBaseStopTask (taskHandle);
}

Daniel

[Steven_K.]

Would you be able to use IOTrace to capture the last couple hours before and including the error?

http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9

We want to understand the underlying VISA API calls that are occuring when the error happens. happens. We are going to try to reproduce the issue on our end as well, but obviously the latency for the error to occur is quite large. Also what is the state of the system after the error occurs? Does lsdaq still work?

[CBest]

For the IOTrace, I think it's an utility in Windows.  When I connect the DAQs running on Linux to a Windows machine, I need to update the firmware on the DAQs.  Is it fine for me to do so?  Since I'm going to run the utility on one of the DAQs which fails in my running system, I just wonder if any bad thing will happen to the trace results after replacing the firmware.  I mostly work with the DAQs under Linux and am not familiar with them under Windows.  If it's fine, I'll go doing it.

For the state of the system after the error occurs, I think it's stable, at least my program resumes right away after restarting from the crash, without any call to lsdaq.  I've never tried to call lsdaq after the crash, but from my experience, lsdaq should work under this state.

Daniel

[BriceS]

According to this KnowledgeBase article, I/O Trace is available to use in Linux: http://digital.ni.com/public.nsf/allkb/DA87370E9FDB8516862571D5006D0587

Regards,

Brice S.

Applications Engineer

National Instruments

www.ni.com/support

[CBest]

Okay, I installed the NI-488.2 v2.9, and found the NI I/O Trace in the start menu and under /usr/local/natinst/niiotrace.  I started the program and was able to capture the activities from the NI-6008 and stored them through file logging.  According to the help page, I believe that I should store the log in .nitrace format for debugging purpose.

The date the error occurred last time was August 7.  The estimated date of the next error is September 25.  I'll run the trace program around that date and will be back if the error still happens, with the io trace log if I capture it successfully.  I'll also run the trace program on different machines.

[Steven_K.]

Hi CBest,

There was a similar bug that was fixed in VISA 5.2. DAQmx Base relies on VISA work, so I would encourage you to try using NI-DAQmx Base 3.6, which includes this version of VISA. Please keep us posted on your progress.

Thanks,

[CBest]

Hello Steven,

The error occurred again yesterday (Sep 25) around 7:34pm CST on all systems, including the one running DAQmxBase 3.6.  Attached are the niiotrace files acquired from two systems:

system1.zip: OpenSuSE 11.1, DAQmxBase 3.3, NI-488.2-2.9.0f0
system2.zip: OpenSuSE 12.1, DAQmxBase 3.6, NI-488.2-2.9.1f0

File timestamps have been preserved.  Let me know if more files are needed.

Best regards,
Daniel

[CBest]

Files from system2.