Why can't I get to a suitable sampling speed

[Dhomfray]

I am using one of the examples from the 'find examples' which I include. My question is very simple I have a USB 6015 which says quite clearly 200KS/s now lets say thats for 1 channel and I use 16 channels then for each channel I should be able to get 12.5KS/s. When I try to take all 16 channels at 10KS/s it gives me the following error

Error -200010 occurred at DAQmx Read (Analog 2D I32 NChan NSamp).vi:1

Possible reason(s):

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, alter the data transfer method (from interrupts to DMA), use a product with more onboard memory, or reduce the number of programs your computer is executing concurrently.

Task Name: _unnamedTask<0>

If I try 1 channel at 10KS/s it works OK and for 16 channels 5KS/s seems OK. So my question I suppose is, am I doing something dumb or is there a way to collect data faster, is this what I should expect and if it is what the monkeys does NI bother sticking a sampling rate that only the divine can acheive

[Dhomfray]

Having viewed a few of the unaswered USB Error -200010 occurred  issues, it appears that the problem is due to the actual transfer of the data between the DAQ and the PC via the usb bus so by the time the daq device sends an interrupt to the PC and begins to send data there is already more data acquired to be sent.  Not sure how I can resolve this I use my USB daq card as a way of testing my code before implementing it I bought a 200KS/s because I thought I must be able to run at 100KS/s (6030E), obviously I was mistaken.

I have just purchased a USB 6251 and I am waiting for it at the moment this is supposed to be 1.25MS/s, is this correct or will I still only get 5KS/s like the other usb device if it has the same bus problems I can only conclude  it will do the same. WIll NI reclassify there USB devices accordingly I ahev already spent 1.5k on cards that can only do 5KS/S. I probably can get the same speed form the bloody parallel port 

Message Edited by mr_nice on 05-21-2007 07:35 AM

[TroyK]

I've got a couple of 9221 USB DAQs and can easily get 800KS/s out of them. I did get a similar error when I tried to sample at that rate on a USB1/USB1.1 speed port. It was connected to a USB2.0 PCI card but the USB2.0 PCI driver hadn't installed properly and I was only getting USB1 speeds. I tested it by transferring a 100MB file off a USB flash drive. If it takes more than about 10 seconds then your port probably isn't giving you 480Mb/s.

Once I got the driver installed properly it worked fine.

PS. haven't had a chance to look at your vi yet, just going off the top of my head.

Message Edited by Troy Kujawski on 05-22-2007 12:02 AM

[Dhomfray]

Thaks Troy you are quite correct althogh I still can't get to 10KS/s when I took the USB device from my hub and removed all other devices then it sped up a little but not to the level I thought it would. I will see if there is a USB 2 sniffer available. I had thought of this, I just immediately assumed that NI could add a priority thread to the USB bus in order to make sure it had the bus when required

[TroyK]

OK, after looking at your vi the first thing you need to do is take out the 100ms timer. It will only cause problems, the loop speed will already be controlled by waiting for the amount of samples you requested.
The second thing you should probably do is place your front panel indicator and file write functions in a separate loop. Use enqueue/dequeue functions in a producer-consumer architecture.  This will prevent front panel updates and file access times from slowing down your data acquisition. If the USB DAQ is putting out data faster than you are taking it then the device buffers will gradually fill up and you will get your memory error again.

[Dhomfray]

Thanks Troy thought I would post my findings and my new application.

I read the two links below to understand this queueing system and have rebuilt the vi that I previously posted using the enqueue/dequeue functions in a producer-consumer architecture, and now it works at 12kS/s. Can someone please have a look to see if this is the correct way to make a vi with this queue functionality it seems to work lovely just not entirely sure if its correct.

http://zone.ni.com/devzone/cda/tut/p/id/5897
http://zone.ni.com/devzone/cda/tut/p/id/3023

[TroyK]

Yep, that looks good to me. Well done.

[Dhomfray]

Ref: http://forums.ni.com/ni/board/message?board.id=170&message.id=246667

Thanks for all your help Troy I really appreciate it. Ok I am trying to make one last step now where I am trying to include two DAQ cards and acquire data. This is part of the another post that I want to make sure I include with this in order for people who are making the same LabVIEW journey as me to make it easier for them (I am also changing the message subject clightly to reflect this).

The VI I have included I beleive this is the most efficient method to aquire data as fast as possible without starting to have buffer overruns, I woudl appreciate any comments. I realise that I am not using write to binary but after having about ten posts I have never had the issue of how to append to binary answered (If my loops collects 1000 samples at 32 channels for 10 loops my ASCII collects 32x10000 but I only ever collect 32x1000 with binaray) therefore I have to stick with just writing ASCII files, if anyone ever wants to modify this VI so that I can push my data to binary and read back from it again I would be most grateful.

In this VI I have not used the getQueueStatus.vi because I am not sure exactly what it is for, I mean I understand that it must get the queue status but I am unsure how that is relevant in this application, any comments is it needed and if so where should it go and why.

Message Edited by mr_nice on 05-23-2007 06:18 AM

[TheWay]

Hi there,

The reason why you only get 32x1000 samples using binary arrays is probably because you are not correctly creating the header for the binary file.  I'm assuming you just replaced your Write Text File VI with the Write Binary File VI and wired a true boolean constant to the Prepend Array input.  What this would do is write the size of the data for the first iteration (32x1000) of your while loop as the header for the binary file.  Every subsequent iteration of the loop will just append data to the binary file and not change the header (because the File Position is set to 'end'). 

What you need to do is create the binary header ahead of time based on your channels, sample rate, etc.  A good example of this from NI Example Finder is the Cont Acq&Graph Voltage-To File(Binary).vi, particularly, the Create Header.vi.  You will also have to modify your reading of the binary file (eg. Graph Acquired Binary Data.vi).

I hope that helps.

Way

[TroyK]

Having 2 DAQmxRead tasks in 1 while loop should work ok if the sample rate and number of samples requested are the same. If either are different, you will have problems. One of the devices will get a memory full error like you experienced before.

I would suggest to use TDMS storage files instead of using binary files.  They are designed to store waveform data and be appended to.
First, get your DAQmxReads to give you a 1D array of waveforms out instead of a 2D array of numerics. 
Give the channels names so the TDMS streaming knows where to append the data too...


Probably just as easy for me to make the changes in your vi as it is to type it out...

Here you go... I simulated it... it seemed to work... created a 12.7MB tdms file.