Fetch too slow for real time in PXIe 5162 High Speed Digitizer

[marco_inzunza]

Hello there,

I am having a problem with aquisition/fetch time in Labview NI Scope. I am using a PXIe 5162, with a 1071 chassis and a 8381 controller. I am transferring (5000wfms*100pts +448)*2bytes = 1MB of data in 0.55 seconds, triggering with a rep-rate of 20KHz (50us).

The total acquisition time was measured at National Instuments for 5000wfms/20,000 Hz = 0.25000333 seconds. They measured this with a clock counting card and measured the clock counts between the PFI0->Start Trigger and PFI1->End of Acquisition Event of the scope. 

Using the ni Scope Stream To Memory Maximum Transfer Rate Single Channel.vi, I have measured the max transfer speed of about 700MBs/second. I am bottle necking somewhere, and I do think it has to do with the PXIe Bus and transfer speed of computer. 

My computer system is a Windows 7, 8GB RAM, 2.0GHz Intel Xeon E5 Processor. Labview 2017. National Instruments tested the attached VI and found an acquisition/Fetching time of 0.45 seconds. I tested this again on a separate computer, which has 16GB RAM and a 3.6GHz Intel i7, and actually saw my time increase to 0.73 seconds. I am not sure what is causing this time to vary like this, but I want to acquire/fetch my data as fast as possible for my application.   

Has anyone figured out how to optimize the fetch commands? I would imaging this device to be able to stream 1MB of data in less than 0.3 seconds, which is what it is taking now. 

Thanks so much for your help, 

[majoris]

I've never used NI-Scope but thought your problem was interesting. I highly doubt it is a memory issue. In fact, it seems like many of these cards have lots of memory reserved for records:

Onboard memory sizes: 64 MB or 2 GB

Minimum record length: 1 sample

Number of pretrigger samples: Zero up to full record length

Number of posttrigger samples: Zero up to full record length

Maximum number of records in onboard memory

64 MB - 65,536

2 GB 100,000

Allocated onboard memory per record: [(Record length + 448 samples) × 2 bytes/sample], rounded up to an integer multiple of 128 bytes (minimum 512 bytes)

So all this stuff should be storable in onboard memory even if you don't have the 2GB version.

Something from the manual:

• If the second trigger arrives before the first record completes, it will not be accepted. Only one trigger can be accepted in any one record in the NI-SCOPE driver.
• If the second trigger arrives after the first record completes, but before the dead time has elapsed, it will not be accepted.
• If the second trigger arrives after the first record completes and after the dead time has elapsed, but before the minimum pre-reference trigger sampling for the subsequent record is complete, it will not be accepted.
• If the second trigger arrives after the first record completes, the dead time has elapsed, and the minimum pre-reference trigger sampling is finished, the trigger will be accepted

So the question is could you be missing triggers? This to me seems more likely.

[marco_inzunza]

Hi Majoris,

Trigger Dead Time = 700ns for this device. The device is being triggered by a TTL at 20kHz (every 50us). The device should be able to rearm itself, and sample a new waveform every 50us. 

I highly doubt we are missing triggers, as I've run the niScope EX Timestamps.vi, where the average time between triggers is exactly 50us. Also, as mentioned in the post, NI has measured the clock-counts between the Start Acquisition and the End of Acquisition Event. 

[majoris]

Ok. I had trouble understanding your issue before (I think you made a couple typos in your original post). So your issue is not in acquisition at all, just in data transfer. Sorry I couldn't help. I'm sure you've already seen these forum posts about multirecord optimization and fetch forever with NiScope.

https://forums.ni.com/t5/High-Speed-Digitizers/Fetching-many-records-all-at-once-is-no-faster-than-f...

https://forums.ni.com/t5/High-Speed-Digitizers/Limitless-number-of-records-and-Software-Event-Interr...