After meeting the same blocking issue these days with a PXIe-6548 HSDIO board, I wanted to update this thread with new information.
After standing there for more than 5 years with no corrective action, the old CAR # 37929 mentioned above by DJ_L has been closed by NI as "rejected" in 2013, with only mention of the workaround stated above : reduce rate of records - acquire less records of larger size.
It surely is one possible workaround, but it can prove to be very unpractical, if not totally impossible in some circumstances. In our case, we have to acquire small asynchronous bursts of serial communications, each only 12 to 16 bits long but at high clock frequency (100 to 200 MHz). Either we design the task so that it creates one record for each burst - but then we reach the limit of only a few thousands of records transferable to the PC per second, at least 5 times too low four our test. Or we perform continuous acquisition between the bursts, but this starves the system with a huge stream of useless data - and brute force is not the solution I would expect from this class of advanced devices.
We indeed probably found a workaround, with a continuous acquisition controlled by a Pause Trigger. But this makes the software part more complicated (sort the individual bursts of data out of the continuous flow), and, more problematic I think, implies generating and routing an additional signal to a PFI, by external, physical wiring. So we have to explain to the customer that his test PCB he just designed must be modified, and that this mod is required because the 12000 $ HSDIO device cannot transfer 25000 times 12 bits each second to the PC. That's not even 50 kB/s... What does HS in HSDIO stand for, again ? We surely have trouble next time we advise him to invest into top-end PXI instruments...
It is a pity that a board of that price range and performance level is limited to transferring 3000 to 4000 records of a few samples each per second only because of the DMA transfer strategy. Note that on NI-Scope devices a multi-record fetch is obviously much more efficient and thus probably optimized for single DMA access for multiple records. Now I have no idea about the technical insights - maybe nothing better can be done for hardware reasons ?
Anyway. A new CAR # 577552 has been filed some days ago for the same issue - let's hope a better fix can be proposed by NI this time. And if not, it would be great to at least update the device specifications to clearly state this rather low limit of records transfer rate, so that people designing test systems can be aware of it before spending 12000 $ for the device - which cannot even be simulated.
Did you ever find a more efficient way to transfer the data via Multiple Records Fetch? I am using a PXIe 5162, with a 1071 chassis and a 8381 controller. I am transferring (5000wfms*100pts +448)*2bytes = 1MB of data, with a trigger rep-rate of 20KHz (50us) in 0.55 seconds. The total acquisition time is 5000wfms/20,000 Hz = 0.25 seconds.
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.
Computer system is a Windows 7, 8GB RAM, 2.0GHz Interl Xeon E5 Processor. Labview 2017.
So there is no new information for the CAR report that Vincent mentioned at this time.
What type of trigger are you implementing? Edge, Digital, Immediate, Hysteresis, Software?
My understanding is that the 8318 is a Remote Control Module, so which cable are you using to connect the chassis to the 8381 controller?
Also for your setup, is it just the PXIe 5162 in slot 2 and the 8318 in the chassis and nothing else? Or are there other cards that are present?
Thank you for your reply.
The trigger is a rising edge, using a sync output from a function generator with a rep-rate of 20kHz. Having checked this two different ways, the scope is triggering exactly, acquiring real-time (5000 waveforms), without missing any triggers.
Yes, the 8381 controller is connected with a MXI-cable (3 meters) that was included with the 8381.
For my setup, the chassis is the 1071, the 8381 controller is in stot 1 and the PXIe-5162 is in slot 4. There are no other cards in the chassis.
At this point, I am leaning towards a data transfer issue to the PC bus, or perhaps the windows operating system is not real-time.