Any solution to PDA error code 200361?

[Chew Toy]

I've seen a few postings regarding this error and I am struggling with it myself. In my case, I'd like to acquire analog input from 16 channels at a minimum of 128 S/sec (ideally up to 1024 S/sec). Right now if I try to run it at anything above 75 S/sec, I get this error after it runs for just about 6 minutes. If I go below 75 S/sec, I get the error at 12 minutes.

[Brett_B.]

Chew Toy,

That error, -200361, is a buffer overflow error. You need to pull more data from the device buffer each time you read from it...OR...put less data in the buffer over time. Since you have an established rate...I suggest you increase the "samples to read" value in your program. By default i think it is set to 100. This is merely a starting point and should be adjusted given the needs of your acquisition.

-Brett

[Chew Toy]

Brett,
Thanks for your reply. I played around with your answer but haven't had any luck. If I change the "samples to read" value it does seem to have some effect, but I generally see improvement only if I reduce it, not increase it. Also, if I increase the sampling rate, I get the error pretty quickly. Consequently, I get my best results at 100 Hz and 50 samples to read per cycle.

FYI, one thing I didn't mention in my last posting was that I'm using a 6036E DAQ card (PCMCIA).

I'm also attaching my most recent VIs. The first one goes on the pocket pc. It reads the DAQ card, saves the data to a file on an SD-memory card and transmits the data to a wireless-enabled laptop. The second VI runs on the laptop. It receives the data
and displays it. Both are adapted from examples that came with LabView.

Finally, I've modified the DAQmx Base task list to include a task for 16 bipolar RSE channels. In the task, the scan rate is 100 Hz, the number of scans = 0, and the convert rate is 100,000. I know it says you only need 16 x 100 (# channels x scan rate), but the example in LabView was set much higher and this does seem to help.

[gaving]

Hey Chew (that's an awesome name),

I want to suggest something. When I look at the PocketPC code I notice that inside the while loop with your DAQmxbase Read is file AND TCP communications. That is a lot to have when you want the reading of data to be somewhat deterministic. My suggestion is to attempt to move the read to a simultaneously running while loop that has a wait. You will be able to get your samples on a more consistent basis. To get the data from the one while loop to the other, I suggest using queues. These are located under ALL FUNCTIONS//ADVANCED//SYNCHRONIZATION//QUEUE OPERATIONS. This will allow you to put the data in the queue when you get it from the read loop. Then, when the other loop is ready to do file I/O and
TCP on the data, it can dequeue the next element on the queue and do what it wants to with it.
Good luck,
-gaving

[Chew Toy]

Gaving,
Thanks for the tip. I worked in the Queue operation and that's helped a little. Unfortunately, the VI still quickly produces the buffer overflow error when run at 150 or 200 Hz. When I run it at 100 Hz it lasts much, much longer. It runs for about 50 minutes, before giving me a new error code (30155002). Any idea what this one is? I've also attached the current version of the VI in case it helps.

Is there any hope for getting above 100 Hz per channel (at 16 channels)? You mentioned previously that we might be limited to 250 Hz per channel. This would be marginally acceptable, if we could make this happen.

Thanks again,

Chew Toy

[Salvador_Santolucito]

Hi Chew,

Your best options will be to play around with the buffer sizes and attempt to make your code as efficient as possible. The problem isn't that the board can't acquire the data fast enough, its just that the PDA cannot handle all of the data coming in. The queues idea is good.

[Tony Seal]

Hi Chew
I've read the suggestions and all are valid I'm sure but just to let you know I've been experiencing similiar problems too.

I found using the 6062 a much more flexible solution. I know this isn't ideal as it means a change in hardware but the 8K buffer really helps and I've been able to achieve much better sampling rates with 16 channels. In fact you should be able to get 16 channels at 1KS/S depending what other processing is going on.

After making some experiments reading about 80% of the buffer at a time seems to work well so I've been reading 400 scans of 16 channels at a time without timeouts. I've also found reading in RAW mode helps a lot too rather than scaling the results.

I hope this helps

Tony

[Chew Toy]

Thanks Tony, that sounds like a useful lead. FYI, with a bit more experimenting myself, I've been able to achieve a 200 Hz sampling rate per channel while collecting data from 16 channels. The configuration typically holds for about 54 minutes then gives me the same buffer overflow error. Perhaps trying the 6062 DAQcard will put me over the top.

-Chew Toy

[Chew Toy]

I've recently tried the 6062E DAQCard and found it improves my VIs performance, but I still see the same error/crash at between 55-60 minutes. I can, however, run it at 256 samples/sec/channel.

[Chew Toy]

Just an update...
I'm still having trouble with this problem. I can now get the PocketPC to collect data for ~90 minutes by setting it to collect 512 samples per channel (over 2 seconds) instead of 256 samples per channel (over 1 second). When its set at 256 samples, it crashes at ~45 minutes.
I also recently went into the 'DAQ MxBase Read (Analog 2D DBL NChan NSamp).vi' and changed every DBL input/output/constant/etc. to SGL hoping that this would lessen the processing burden and improve performance. After doing this, performance improved from ~90 minutes to ~93 minutes.

Has anybody else had greater success yet?