Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Difference of USB 6251 and PCI 6251 on analog input.

Hi, Happy New Year.

 

I wrote a code using labview  to get data from a ccd array. It works great on PCI 6251, however meets some problem on USB 6251; memory overflew and unexpected slow speed. It seems the difference between them two are not significant, so I can't find the reason, I wonder if anyone can help me with this. Besides, I am a new leaner of labview and Daq, please help me improve this code.

 

Here is some detailed information about my code, I also attached my code.

 

The ccd array need a clock(1MHz) and frame trigger, I use the two counters on 6251 to supply. At this case, the ccd array will sent out 640 data at 1 MHz when received each frame trigger signal. On the other hand, the ccd need to rest at least 20 us after each frame, so I make the frame trigger (counter 1) sent a high pulse and then sent 659 low pulse.

 

And next I read data using 1 channel analog input (continuous mode), the source of sample clock is counter 0 internal output (clock 1MHz), start trigger is counter 1 internal output (frame trigger), so that daq analog input and ccd array frame output is synchronized. I use a while loop to acquire 300 frames each time to compose a image(there is a fourier transform and other procedure, please ignore this).

 

To get a continuous image, I add another loop, which is triggered by external function generator. So, my code should get dynamic image at the same rate of external generator (maximum 4 Hz).

 

To make sure my code works proper, I add a measure time code to get running time of each big loop.

 

While, here comes the problem, this code works great on pci 6251, for example, when the external function generator is 4 Hz, then the measured loop time is 250ms. 500ms at 2Hz.

 

But when it runs on usb 6251, the measured loop time is 330ms at 4Hz. This should not caused by low speed of USB, because I slower the external function generator, for example 2Hz, the loop time is 700ms. Further lower the function generator also cannot solve this problem.

 

Besides, this usb 6251 will get a memory overflew problem after several minutes' running, while pci do not.

 

Please help me find the reason.

0 Kudos
Message 1 of 15
(8,721 Views)

Hi ustcmiaor,

 

it is interesting.

 

If you are getting overflow, it means you don't read data from board fast enough. It might be caused by couple of things. I would primarily focus on USB bus - first step could be to be sure no other devices are connected to your USB controller. USB is serial bus, which means if some other communication is ongoing on bus, it might decrease response, which will result in lower realistically achievable transfer rate from your USB device. You could experience this on PCI, but it is much more "deterministic" bus than USB.

 

 

regards,

Stefo 

Certified-LabVIEW-Developer_rgb.jpg

0 Kudos
Message 2 of 15
(8,688 Views)

Hi Stefo,

 

Thank you very much for your reply.

 

And yes, only this one USB device is connected to my notebook. Also, it should have nothing to do with the notebook's speed, because CPU and memory usage are both very low.

 

I am reading data 1M Sample per second, can USB support such a speed?

 

Best,

 

Miaor

0 Kudos
Message 3 of 15
(8,669 Views)

"As of 2004, the actual throughput of USB 2.0 high bandwidth attained with a hard drive tested on a Mac was about 18 MiB/s, 30% of the maximum theoretical bulk data transfer rate of 60 MiB/s (480 Mbit/s). On Windows, the highest speed observed was 33 MiB/s, or 60% of the theoretical max"

 

Taken from Wikie <http://en.wikipedia.org/wiki/Usb#USB_2.0_data_rates>

---------------------------------------------
Former Certified LabVIEW Developer (CLD)
0 Kudos
Message 4 of 15
(8,661 Views)

Hi, I made a mistake, what I have is a PXI 6251 (not a PCI 6251) and USB 6251, but I don't think this will make a difference...

0 Kudos
Message 5 of 15
(8,647 Views)

Since the data is 16 bit, or 2 byte, so I need to transfer data at 2MB/s. USB should be able to satisfy this.

 

But NI are using their technology called usb signal stream (http://zone.ni.com/devzone/cda/tut/p/id/4636), does this has something to do with my problem?

0 Kudos
Message 6 of 15
(8,645 Views)

it should be possible to handle the troughput. There is challange with bi-directional communication (measurement-generation) which increases latency. If latency is higher, you might fill buffer on the board in before you read them - buffer overflow.

Certified-LabVIEW-Developer_rgb.jpg

0 Kudos
Message 7 of 15
(8,614 Views)

ustcmiaor,

 

At first glance, I see no reason why this application should fail for the USB-6251.  I have a couple of suggestions which may or may not help.  First, I see no reason to configure your AI task as a continuous task.  Essentially you are going to read 299 * (add integrating time + 660) samples each iteration of the while loop (or each time you start/stop your task).  There's no need for AI to continue to acquire additional samples.  Given this, it might make sense to read all of these samples at one time, the do the splitting of data and FFT after these samples have been read (ie... put your read outside of the for loop, then just iterate over the already read data to break apart your data and perform your FFTs in the for loop).  I suspect that as a result of calling DAQmx Read frequently on small data blocks may be causing the device to use USB less efficiently.  Additionally, you are calling DAQmx Stop Task on your ctr1 task while your AI task continues to acquire data.  Perhaps you are overflowing after you read data, but before you can stop your AI task?  Switching to a finite configuration would eliminate this possibility.

 

Without having the hardware to test with, I'm not certain if these suggestions will fix the issue you are seeing or not, but they might be worth a try.

 

Hope that helps,

Dan

Message 8 of 15
(8,594 Views)

Hi Dan,

 

Thank you so much for your suggestions, and they are very helpful for me to improve my code. I have tried out your suggestions, and attached a new file, I hope I have understand your throughs correctly.

 

But it seems the two problems remains, and I do think your suggestions have speed up this code, but the actual loop time do not even decrease 1 ms... So there must be other reasons.

 

Anyway, thank you very much for your reply~

 

Best..

0 Kudos
Message 9 of 15
(8,579 Views)

Hi Stefo,

 

It might be the reason, but I hope not, otherwise I have to bring my desktop with my system......

 

Thank you so much for your suggestions~

 

Best.

0 Kudos
Message 10 of 15
(8,578 Views)