Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

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!!

0 Kudos
Message 1 of 6
(617 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 6
(567 Views)

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

0 Kudos
Message 3 of 6
(540 Views)
Solution
Accepted by topic author Massimo44

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 4 of 6
(480 Views)

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

0 Kudos
Message 5 of 6
(466 Views)

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

0 Kudos
Message 6 of 6
(434 Views)