Fetching triggered acquisitions forever

[gregoryng]

Hello, I have a follow-on question to my last inquiry on this thread a long time ago, synchronizing multiple generators using tclk and script triggers.  At the end, I asked if there was a way to acquire digitally triggered records forever.  It is straightforward to acquire a finite number of records, but as I mention at the end, it does not appear that there is a way to instruct the API to keep acquiring forever, in the niScope Configure Horizontal Timing VI.

However I notice that in the RFSA API, there is a property node called Acquisition:IQ:Number Of Samples Is Finite Property, as well as the "number of samples is finite" parameter to RFSA Configure Number of Samples.  

Is there a reason for this difference in features between the APIs, and is it possible to add this functionality to the High Speed Digitizers API?  As far as I can tell, there is no workaround other than to have some missed triggers (which is what is happening with our current system).

[Branch_Support-NIC]

Hi gregoryng,

Unfortunately, it's hard to say why one API has functionality that the other doesn't -- the RFSA and Scope API are used for very different purposes and the devices may not support the same types of acquisitions. You're welcome to submit a request for the inclusion of that functionality into the next version of the driver via our Idea Exchange forum here: http://forums.ni.com/t5/Idea-Exchange/ct-p/ideas.

In terms of the niScope API, your best bet may be the fetch forever functionality. More information can be found here: http://digital.ni.com/public.nsf/allkb/03726608568CB14786256F330071706D.

Hope that helps!

Thanks,

[gregoryng]

Thanks for taking the time to reply.   I have seen the fetch forever functionality and unfortunately it doesn't work for us because there is a lot of dead time that we would be reading (too much).

For the idea exchange, which sub-section would you suggest?  Data acquisition?  PXI and Instrumentation?

[blakney]

It is possible to set up a fetch forever variant where you set up a read thread to read to a pair of small buffers and watch the wvinfo for a trigger condition. Once triggered read the required number of samples to the main buffer and then using wvinfo and the three buffers recreate the require scope trace.

This is how we collect triggered and streamed transients in our data station (under Labwindows / CVI).

Greg

[gregoryng]

Thanks for that idea.  Could you give me a little more information, such as tell me which functions/VIs you were using and the definition for wvinfo?  I don't see any references for this with a quick search?  I'm having a hard time visualizing exactly what you're describing.

Also You mention that you were working under Labwindows/CVI, but what hardware were you using, and and what was your sampling rate and datatype (16-bit int?)?  the biggest problem in my application is that with a 50 MS/s sampling rate, there may not be enough processing bandwidth for this method.

[blakney · Accepted solution]

Let's do the easy part (parts and specs) and then I will have to refer to my code.

I use a PXIe-5122 (64MB option), PXIe chassis, and a MXI x8 remote control link although a MXI x1 link should be sufficient for a single channel solution. I have additional cards in my chassis for the experiment.

I can get full bandwidth from the PXIe-5122 which is 100 MSample/s.

The 5122 is a 14 bit digitizer where the data transfer occurs as int16.

I think that this card may in fact meet your needs if 14 bit will suffice.

The concept is as follows setup the digitizer for sample rate required and triggering.

Allocate three buffers. Two buffers are small temporary buffer let's say 1MSample each (we will call these buffers even and odd. The third buffer allocates enough memory to hold all of the required data.

Launch a separate thread that removes any collected data and initially stores this data in odd, next even, next overwrite odd, then overwrite even, etc.

(Back to main thread) Begin the scope and DUT then wait for the data to be acquired.

Along with each download you will get secondary info which can be queried to see if the trigger event has happened. When you note the trigger event, transfer all of the new buffer into the larger array note the new start position each time.

After sufficient data is recorded, break out of the instrument loop and merge the needed data from the temporary array with the data from the main array and pass the data to the main thread. (Thread safe queue may be necessary depending on your program.)

If you are still interested, I will look around for my initial project prior to integrating the other cards.

Finally, how much data do you need to collect post trigger event?

[gregoryng]

Thanks for all this info, I do appreciate it, since this has been an open question for a long time for me.  We've been dealing with the possibility of skipped triggers for a long time.  We acquire at 50 MS/s and only need 2 channels x 3200 samples per channel post trigger.  We're also using the the 5122 in a PXI chassis if I didn't mention before.

I think I understand the idea of what you're describing now with the pingpong buffers and full output buffer. I may not need your entire project as I can probably do the threading, but I don't yet see how you detect the trigger from the wfminfo, so that would be useful to describe or demo.

[blakney]

Ok. I failed to find to inital project so I just looked at the code for the active data retrieval thread.

The critical CVI function is called niScope_FetchBinary16 which returns any data as well as wvinfo.

wvinfo is a structure defined by National Instrument under niScope driver a s follows (I think G would call this a bundle maybe?)

Returns an array of structures with the following timing and scaling information about each waveform:

• relativeInitialX—the time (in seconds) from the trigger to the first sample in the fetched waveform
• absoluteInitialX—timestamp (in seconds) of the first fetched sample. This timestamp is comparable between records and acquisitions; devices that do not support this parameter use 0 for this output.
• xIncrement—the time between points in the acquired waveform in seconds
• actualSamples—the actual number of samples fetched and placed in the waveform array
• gain—the gain factor of the given channel; useful for scaling binary data with the following formula:

voltage = binary data × gain factor + offset

• offset—the offset factor of the given channel; useful for scaling binary data with the following formula:

voltage = binary data × gain factor + offset

relativeIntialX is what you will need to monitor to see if a trigger event has occurred. Prior to a trigger this value is "gibberish" and then post trigger the time becomes a positive value. Since the first value happened at relativeX, you can back in time to determine zero to within one dwell period.

[gregoryng]

Ah perfect, that's what i needed to know.  I'm familiar with both those functions and structures since that is we use that VI, but never used it in this way.  

I won't get to try this technique out for a few weeks, but I would consider this solved.  

Thanks again!

-gn