Error -200361: Onboard device memory overflow

[Seyos]

Dear LabVIEW community,

I am planing to measure three characteristic parameters of a BLDC electric motor with LabVIEW while a long-term application. The developed VI seems to work in general but struggles with error code -200361, which displays the following text as possible cause: "Onboard device memory overflow. Because of system and/or bus-bandwidth limitations, the driver could not read data from the device fast enough to keep up with the device throughput. Reduce your sample rate. If your data transfer method is interrupts, try using DMA or USB Bulk. You can also use a product with more onboard memory or reduce the number of programs your computer is executing concurrently."

What can I do without decreasing the sampling rate which is determined in my application to be 100000 S/s for each channel after the sampling theorem? I am using NI cDAQ 9178 with NI 9215 and NI 9220; a device with a bigger FIFO-buffer is unfortunately not available. The cDAQ is is connected to a USB 3.0 port of a Windows 7 computer (i5 processor, 8 GB RAM). Since I am not sure if the problem occurs because of system or bus-bandwidth limitations I already implemented a producer-consumer pattern, increased the DAQmx input buffer size and minimized the maximum number of simultaneous USB transfers used to stream data (which seemed to be a common bug under Windows 7), but none of that helps. Since I am pretty new to LabVIEW it is also a possibility that the VI is flawed so I attached the used V.

Thanks for your help,

Seyos

[Kevin_Price]

That particular error is probably not driven by your code.  It's coming from the driver, saying that the driver isn't able to keep up with the device's data rate.  (There's a related but different error that would be thrown if your application code wasn't keeping up with the driver.)

On the other hand, according to this article about cDAQ throughput, you should be well within your system's throughput capabilities.   I've not really done any high-ish speed data streaming from cDAQ and can't speak from experience, but it seems like you shouldn't have to be stuck with these errors.  The driver ought to be able to handle your data rate.

Once you clear up the driver-related error code -200361, it'll be worth a little cleanup in your app code as well.  Most specifically, I'd focus on:

- get rid of all the "dynamic data type" wires.  Configure your queues to handle waveforms directly.  Possibly have just 1 queue that takes the array of waveforms straight from the DAQmx Read function.

- do a more thorough job of separating the items that need to run every normal loop iteration (such as DAQmx Read) from the items that need to run only under special conditions (all the DAQmx calls that config, start, and stop the task).

- the default values for your controls suggest you're requesting 100000 samples at a time in your DAQmx Read call.  That's 1 full second worth.  You probably *don't* need to change this, 100000 should be sufficiently large already.

-Kevin P

[Artem.SPb]

Your buffer size exactly equal reading size. I not sure about buffer reallocation, but try set buffer size more than reading size. And you can remove config input buffer.

But you have more stranges in your app.

You are configuring yout task each iteration. It takes a lot of time and may be cause of your error.
Make all configuration OUT of loop.

You read all queues in one place, so you really need only one queue. Split data in second loop, not in DAQ loop.

[mcduff · Accepted solution]

---

@Artem.SPb wrote:

Your buffer size exactly equal reading size. I not sure about buffer reallocation, but try set buffer size more than reading size. And you can remove config input buffer.

---

In fact later the OP changes the buffer size explicitly.

---

You are configuring your task each iteration. It takes a lot of time and may be cause of your error.

---

There is a case structure in the VI the OP posted that shows only one first call is the task configured.

Here are some hints that may help you:

1. Make the number of points you want to download a multiple of the disk sector size. Assume your size is 512 bytes, then download 100,352 points instead of 100,000.
2. Make your buffer size at 8 times the amount of points you want to download, in this case 802816, much less than you are allocating now.

Something magic occurs in the DAQmx API when the number of points, buffer size, are multiples of the disk sector size.

mcduff

[Artem.SPb]

---

@mcduff wrote:

---

---

You are configuring your task each iteration. It takes a lot of time and may be cause of your error.

---

There is a case structure in the VI the OP posted that shows only one first call is the task configured.

---

Yes, but not all. Buffer configuration is out of case structure.

[Seyos]

---

@mcduff wrote:

Here are some hints that may help you:

1. Make the number of points you want to download a multiple of the disk sector size. Assume your size is 512 bytes, then download 100,352 points instead of 100,000.
2. Make your buffer size at 8 times the amount of points you want to download, in this case 802816, much less than you are allocating now.

Something magic occurs in the DAQmx API when the number of points, buffer size, are multiples of the disk sector size.

mcduff

Thank you very much, I adapted the number of samples and the DAQmx buffer size to the disc sector size now (which is indeed 512 bytes).

---

@Artem.SPb wrote:

---

@mcduff wrote:

---

---

You are configuring your task each iteration. It takes a lot of time and may be cause of your error.

---

There is a case structure in the VI the OP posted that shows only one first call is the task configured.

Yes, but not all. Buffer configuration is out of case structure.

You are right, thanks. I integrated all further initial configurations (buffer input size, limitation of outstanding transfer requests) into the existing case structure of the DAQmx timing VI.

@Artem.SPb wrote:

You read all queues in one place, so you really need only one queue. Split data in second loop, not in DAQ loop.

---

How can I properly split the data after dequeuing? If I am doing that conventionally I find all of my signals jumbled together in the first output of the Split Signals Express VI while the others remain empty.

Also is a limitation for the number of outstanding transfer requests even necessary for USB 3.0 data transfers since it does not apply to the EHCI standard? Or is it a general Windows 7 driver problem unattached to the host controller interface? Reading this I am not sure about it.

Anyway the code is running flawless for more than one hour now. Since the error occurred occasionally after hours/days, the effectiveness of these changings still have to prove themselves for the long-term application but I will inform you about anything new. So far: Thank you all for the fast and helpful answers!

Seyos

[Kevin_Price]

There's no need for those Dynamic Data wires.   Stick with the native waveforms that DAQmx gives you.  Then you "split" them by simple and well-defined operations like array indexing.

Dynamic Data is pretty much universally loathed by experienced LabVIEW'ers.  The contents are variable, opaque, and unquery-able -- not a very good combo for a data-centric language.

-Kevin P

[Seyos]

---

@Kevin_Price wrote:

There's no need for those Dynamic Data wires.   Stick with the native waveforms that DAQmx gives you.  Then you "split" them by simple and well-defined operations like array indexing.

Dynamic Data is pretty much universally loathed by experienced LabVIEW'ers.  The contents are variable, opaque, and unquery-able -- not a very good combo for a data-centric language.

-Kevin P

---

Okay, thanks for the hint. I will try to implement that.

Since the code is running flawless for nearly 4 days I assume the error is fixed now. Thank you all for your help!