Slow fetch - PXI 5122

[Azazel]

Hello all,

I am using LV 8.2, XP, PXI-5122.

I am trying to set up an aqcuisition and have noticed that the fetch process is extremely slow and was wondering if anyone has experienced this same issue. Some background... I am sampling (n=1700) a triggered signal (43kHz)  512 times (consider this a frame of data) at a sampling rate of 100 MHz.  The acquisition is very fast (expected time to acquire 1 frame = 0.012s) and I believe this PXI-5122 is acquiring properly, but it is taking over 0.350s to fetch this data for calcualtion in the method as displayed in the vi I attached.  This very slow fetch speed is limiting my applicaiton and can any one tell me of a faster way to fetch the data for calculation, or have I made a mistake in the way with which I fetch the data once acquired.  I wrote this vi based on the "Multi Record Fetch More Than Available Memory" vi in the shipping examples.

Thanks,

Azazel

[Matthew_W]

Hi Azazel,

I took a look at your VI and ran it with a NI-5124 card. The VI is running slowly because there is a massive array being copied around the while loop on every iteration. This is not seen with the shipping
example, I did verify that.

Here is the solution to what you are seeing:
  Implement a producer/consumer design pattern.

This will decouple your acquisition loop from the processing loop, you will not see this performance issue when you are done with this transition.

The producer/consumer design pattern can be found this way:
  1. Run Labview
  2. Click File->New->From Template->Design Patterns->Producer/Consumer Design Pattern (data)
  3. Your data acquisition (from the example) will go in the Producer loop.
  4. The processing (array subset, initialize array,etc) will happen in the Consumer loop.

Have a great evening,

MatthewW
Applications Engineer
National Instruments

[Azazel]

Hello Matthew,

I have implemented a producer/consumer algorithm splitting up my acquisition and calculation.  There was an improvement but fetching the data it is still really slow at approx. 100ms (theoretical should be 1.2ms).  I have attached a .jpeg of my current setup for the producer loop.  I have also removed the data from being copied at each itteration of the while loop and currently I am fetching 512 records of length 1700.  Have I set up the queue up correctly?  Any ideas on why this is still 100x slower than it should be?

Thanks for your help,

Azazal

Message Edited by Azazel on 08-29-2007 11:03 AM

[Matthew_W]

Hi Azazel,

 I don't see anything immediately wrong with your producer loop. You mention the fetch takes approximately 100mS when it should theoretically take 1.2mS. Where does this come from?

 The calculations I made are the following (assuming the trigger is a 43khz squarewave on the TRIG input, data to one of the Analog Inputs)
 
  1. Trigger frequency = 43khz, 23.256uS between rising edge of triggers.
  2. 512 Records @ 1700 Samples/Record
  3. Sample Rate = 100 MS/s
  4. Time to acquire 1700 samples = 1700 Samples / 100M Samples / sec = 17uS
  5. As time to acquire 1700 samples is 17uS and time between triggers is 23.256uS then total time for the Scope to acquire 512 Records = 512 * 23.256uS = 11.907mS
 
 The time to Fetch these samples from the scope is dependent on the bus moving the data. In this case it's a PXI bus, here is a link to a Developer Zone article on the PXI Bus.
  A realistic number to expect is approximately 100MB/s across the PXI bus.

 The total data acquired is 512 record * 1700 samples/record * 2 bytes / sample (in my example) = 1.7408MB.
 Time to transfer this data = Data Size / Bus Speed = 1.7408MB / 100MB / s = 17.408mS

I was curious so I went ahead and built a example that performs similiarly with one small change, I'm acquiring from a single channel
 and returning a 1d array of doubles. Why are you fetching as a 2d array? Is there more than 1 channel of acquisition in your case?

Please post back if you have anymore questions, thanks!

MatthewW
Applications Engineer
National Instruments

 
 

Message Edited by Matthew W on 08-30-2007 05:03 PM