PXI-5122: 100MHz acq for 4 seconds to disk

[BillM]

Hello,

I am a relative newbie to Labview but an experienced software engineer. I am using Labview 8.2.1.

I have what I thought was a relatively straightforward task: Use a PXI-5122 (NI_SCOPE driver) to sample both channels simultaneously at 100MHz and acquire a single record for a minimum of 4 seconds, and have it on disk afterward. The lit says stuff like "stream to PC RAM" and I thought I could stream to a contiguous piece of allocated PC RAM or something, but there seems to be a limited repertoire of "fetch" tricks (the only DMA mechanism?), that make this harder than I thought.

Our 5122 has 32MB of memory.

There seem to be only two schemes supported by NI-SCOPE, in which to use a 5122:

1. "Continuous acquisition": use multi-fetch to acquire only 1 record at a time, or fetch relative to a moving read pointer, in a loop, and dump to disk after each fetch, as fast as you can, and operate at a reduced sample rate, so the queue doesn't back up and overflow the limited memory in the 5122 (we didn't pay the extra $5k for the 512MB version).

2. Large, single acquisition, and one large fetch. At 100MHz this doesn't work without overflow.

I was hoping there was some way to use method one, let each multi-fetch use DMA to get the data off the card, into PC memory, and then instead of trying to get it out of RAM and onto disk during the acquisition, let it pile up in (ideally a known, contiguous block of) PC RAM, and after acquisition is done, take it from RAM and put to disk. This must not be too uncommon a need? The only thing I can think of is to use the Labview-to-C routine interface, to manage memory either quickly after each fetch, or take it all from memory to disk after the full acquisition (~4 sec).

I realize 100MS/s, two channels, 4 seconds is maybe pushing it, but am willing to concede resolution, sample rate, in case the 1+GB of memory needed (I think) in a 32-bit system (2GB max addressable?) is asking for real trouble (PCI-x bandwidth?). It doesn't need to be a single record, either, in fact, I am scanning a sensor of 512K "pixels" at a desired rate of 20 frames per sec, and each frame could be a record, I don't care.

Anyway, thoughts, help, criticism appreciated.

Thank you,

Bill M.

[BillM]

Okay, it seems that the PCI bus will not support such a speed.

And it looks like I can use a queue to store the waveform from a fetch-relative-to-read-pointer in a loop to avoid file i/o in the fetch loop, and have another loop de-queuing for saving to a file.

If I can achieve the reliable maximum throughput of the bus I'll live with the reduced sample rate.

The only thing I can't see how to do right now, is accurately trigger the start of the acquisition, the current trick is to set up a software trigger than is never sent, and depend on pre-trigger sampling for continuous acquisition? However I need to trigger on a marker event from a digital pattern generator, which I already have working in a simpler VI with less throughput.. This is because my samples need to be known to be aligned with pixels selected by a multiplexer driven by the pattern generator.

Sorry to change my requirements a little, but better to update my post rather than waste your time..

Bill M.

[Ton Plomp]

Have your analog trigger set to the digital line you use as a trigger.

Look into the LabVIEW examples, they probably have something you need

Ton