Error -200284 when using AO and AI at high sampling rate

[Massimo44]

Hi,

I am using an USB-6363 DAQ generating AO samples at about 2 MS/s. At the same time I am doing a continuous acquisition (1 channel) whose timing is synchronized to the AO timing. Since I am using the C# .NET interface to DAQmx, this is done by passing the (previously defined) AO channel as a source when calling the ConfigureSampleClock method for the AI channel. I have been using this code for more than a year running for several days at the time with no issues, but the sampling rates were limited to few hundreds of kHz at most. Now I am using sampling rates close to the USB-6363's limit and I keep getting this error. The error can occur from few hours after the program has started to up to one entire day. From the exception's message (in the attached file), it seems that AO stopped working and the AI process goes into a timeout as the external clock is no longer supplied. Looking at the signal on an oscilloscope, I can see that the actual AO waveform stops about ten seconds before the exception occurs. I think the problem is not related to the length of the writing and reading buffers. At the beginning I was getting errors related to those, but I think I fixed them. Also, such high rates are quite taxing for the USB. If I try to read from a memory stick while the program is running, it will cause an exception whose message is related to the speed of the USB.  

Does anybody have any idea how to troubleshoot (and fix) this issue?

Thanks!!

[Kevin_Price]

You're probably right that the AO task errored out first, robbing the AI task of its sample clock.

I'd start by troubleshooting the AO part of the app.  Apparently, whatever error condition it experienced escaped your code's attention, so first make sure you notice and catch any such AO error to verify that it precedes the AI error.

Hopefully that error will provide a clue to whether your app isn't feeding data to the AO task fast enough, or whether the DAQmx driver and USB bus aren't feeding your device fast enough.  Do you keep writing new AO data to the task repeatedly as the app executes?  Or do you write once and let the task regenerate perpetually? 

-Kevin P

[Massimo44]

Hi Kevin,

Thanks for replying to my post.

For these extended runs, the AO samples are generated and written to the buffer only once. Until I stop the acquisition, no code affecting the AO task is executed. Probably that is why I do not get an exception from the AO task first.

Maybe I should insert some code to check the health of the AO task. Any suggestion about what DAQmx property/method could be used for this purpose?

Thanks,

Massimo

[Kevin_Price · Accepted solution]

Since your AO waveform is repetitive, is it short enough that you can configure the device to regenerate from the onboard FIFO alone?  The USB-6363 is spec'ed for 8191 total AO samples, shared among all channels.

I don't know the C# syntax, but DAQmx supports the ability to specify that an AO task should only use the onboard buffer for a regenerating task.  This would reduce the USB traffic considerably.  Otherwise the driver needs to constantly deliver data over USB from RAM to the device at a 2 MS/s average rate, potentially interfering with the USB traffic coming the other way for your AI task.

Another thing to investigate might be the USB power saving settings on the computer in question.  That comes up from time to time around here.

-Kevin P

[Massimo44]

Hi Kevin, Thanks for your reply.

Your suggestions sound good and I am trying them out. Even though the computer power profile is for high performance, the USB suspend was enabled. I think I disabled it (I could not do it from the power options because of restrictions put in place by the IT department). Let's see if it makes a difference.

Also, I set the channel property for using onboard FIFO (I just write a couple of hundred samples for the waveform). Using the .NET interface, this is done by setting the AOChannel property "UseOnlyOnBoardMemory" to true. 

For the record, I did try to catch when the AO task was stopping. Every couple of seconds I was reading the AO sampling frequency (in a low priority thread). I was hoping to catch an exception from the AO task before the one I receive from the AI one. It did not work. The program stopped because of the same error.

Let's see how long it is going to run after these changes.

Massimo

[Massimo44]

The program has been running for almost three days now, so I would say Kevin's suggestions did the trick!!