usb-5132 slow

[petrov]

Hi everybody,

our application requires collecting short signal waveforms (about a few thousand points at 50 MHz sampling rate) with repetition rate at least 20 Hz. We were happy before with Labview 7.1/NI Scope 3.4/ USB-5132/ Low end Dell laptop combination. The experimental setup allowed us easily collect data at about 100 Hz repetition rate.

Our data acquisition program is based on standard example program "niScope EX Configured Acquisition" from "C:\Program Files\National Instruments\LabVIEW X.X\examples\instr\niScope NI provides with every "NIscope" software.

We bought "Labview 2010 Developer Suite", which we  installed on newest "Dell Precision M 4500" laptop. But we found USB-5132 now allows us collect data waveforms only at about 10 Hz repetition rate - 10 times slower then with old labview 7.1!

I tested the data acquisition speed with standard  "niScope EX Configured Acquisition" program I mentioned above with the trigger set to "immediate" and found the same difference: the sample from NI Labview 7.1 works about 10 times faster compared to new Labview 2010 when the same usb-5132 digitizer is used.

Like I already mentioned, we need at list 20 Hz repetition rate, better more, and we would like to keep easy-to-use USB-5132 digitizer. Can we make it work faster with new Labview?

Thanks,

Yuriy.

[Kyle_A.]

Hi Yuriy,

Have you looked at how your CPU usage is on each machine?  Are they both on the same OS, same RAM, is the processor speed different and such?  It seems the two variables we have here are not only the LabVIEW install but the machine changed too.  Are there any programs running concurrently with LabVIEW when you are executing the code, or any programs in the background that could cause the immediate trigger to be slower?  Are you running the code in the development environment or in an executable? 

Also, it seems like your code has changed slightly from a modified example to basic example.  Any reason you chose not to test your original application in 2010 and used just the basic example? 

[petrov]

Hi Kyle,

Cpu usage is about 10% on new/labview 2010 mashine and about 20 % on old/labview7 machine.

memory usage is little confusing to me how to read, but task manager shows 583 MB PF usage for old machine and physical memory usage 1.2 GB (out of 4 GB) on the new one.

 I do not have any background programs running. I am running my code in the development  enviroment on both machines.

           Mashines are different. New one has Intel i5 core processor and 4 GB of RAM, Windows7 software and Labview 2010. The old one has Pentium 4, 521 Mb of RAM, Windows XP and Labview7. And this old one works fast, at 100 Hz of repetition rate!

I am testing the basic program now because it is the part of my original program, and the one which slows the original program down.

Thank you,

Yuriy.

[Kyle_A.]

Hey Yuriy,

I have a few more basics to get out of the way here.  Are you running this straight into your laptop or through a USB hub?  Is the USB port 2.0?  I see you were using SCOPE 3.4 on the old system, what version of NI-SCOPE are you using on the new system? 

[petrov]

Hi Kyle,

Accordind to new (Windows7) laptop specs it has :

three USB 2.0-compliant connectors
one eSATA/USB 2.0-compliant connector.

I plug the digitizer directly into one of these.

I use NI-scope 3.6.2 on the new system.

Thank you,

Yuriy.

[Kyle_A.]

Hi Yuriy,

I'm still looking into your issue, but one thought I had was whether you were committing your resources to your scope using niScope Commit.  Did your original or sample program use this function to commit resources into hardware at all?  If you are not doing that, it may help improve the functionality of the code, though I do not know to what extent it will help.

[petrov]

Hi Kyle,

Thank you for the reply.

I just tried to incorporate "niScope Commit" into the program ("ni Scope EX Configured Acquisition", comes with the Labview in [NIScope/Examples ]folder), but in both cases my repetition rate was the same 13 Hz. And I have about 90 Hz  with the same program when using Labview 7.1 /NI-Scope 3.4 package, on much slower old laptop. Is it possible they use some intentional delay when implementing data transfer via USB port? I found it is  "read cluster" VI itself that takes most of the program time, even when record lengh is set to 250 points.

Thank You,

Yuriy.

[dansch]

Hello Yuriy,

My apologies for not seeing this post a few days ago when you originally posted, but Kyle recently brought it to my attention (I usually monitor the High-Speed Digitizers board but don't always catch posts on the LabVIEW board).

I have done some benchmarking with various versions of the NI-SCOPE driver and a USB digitizer. Unfortunately, it appears that there is an issue in NI-SCOPE 3.6 and later which is causing the fetch (read) rates to be drastically decreased with the USB digitizers. We are implementing a solution to correct this problem and get the fetch rates back to their previous performance values. NI-SCOPE 3.8 will address this problem, though that version will most likely not be ready for release until late Q1 2011. In the mean time, the best option is to downgrade to NI-SCOPE 3.5.2 or earlier if it is possible for the specific LabVIEW version in use. If this downgrade is not possible, please contact National Instruments support by phone or email with your specific details and we will work with you to determine the best solution.

We apologize for any inconvenience this has caused and we appreciate your help in informing us of this issue. Please let me know if there is anything else I can do to help out!

Regards,