5152 - Multiple record acquisition forever

[Schrockwell]

Is there a way to do multiple record acquisition on the 5152 that will automatically retrigger itself forever?

I currently have a multiple record acquisition set up to acquire 256 records, but the external triggers (using the TRIG BNC input) are so close together that the software cannot re-arm the scope in time for the next acquisition, and some triggers are missed.

For example, we are capturing 8000 samples at 2 MS/s, so each record is 4 ms in duration. The external trigger occurs at the start of every record, with a period of 4 ms, so I essentially am doing continuous acquisition. Every 256 records (about once per second), the LabVIEW VI transfers the data to memory, writes it to disk, displays it on the front panel, etc., then re-arms the scope for the next acquisition. It would be ideal if the scope could be configured for immediate retriggering of another multiple record acquisition (preferably in hardware), so that it could be acquiring records in parallel with LabVIEW processing and writing the data to disk.

Any thoughts on how I could accomplish this?

[Schrockwell]

Alternatively, is there a way I could continuously acquire data by collecting pretrigger samples forever, but be able to fetch relative to the most recent trigger?

[TimmTheEnchanter · Accepted solution]

Hi Schrockwell,

There is no way to do a Multi-Multi Record Acquisition.

For what you want to do, the short answer is yes--there's a way to set it up within the finite construct of the NI-SCOPE API, but you'll need to make sure that

1. You must Enable More Records Than Available Memory

2. You must set the Number of Records to be very very large.  Since this value is an Int32, theoretically, the largest you can set this to avalue of about 2.15 billion (2^31 - 1).   After that, you would need to stop and re-start your acquisition.

The total time the acquisition will continue for is:

Total Acquisition Time [s] = Total Number of Records [#] / Trigger Rate [Hz]

3. Finally, you must ensure that you can sustain the throughput across your PXI/PCI bus, and you've designed your code efficiently to sustain this.  

Two major things I noticed is that you're displaying data on a graph, and you're writing to a disk.  Displaying data to a graph will cause your program to take much longer to complete one loop iteration--instead, try Fetching without display data.  Secondly--if you are writing to a disk, you should be using Queues to do so.

If you're already doing this, then the higher-level question is whether or not you are backlogging data on your digitizer.  If so, you need to work around this so that there is no data backlog.  The Fetching Throughput (data that is brought into your program using the Fetch function) must be equal to your Acquisition Throughput:

Acquisition Throughput [B/s] 

= # Samples per Record [Sa/Rec] * Trigger Rate [Hz] * Digitizer Resolution [Bytes/Sa]

(Since the 5152 is an 8-bit digitizer, your Digitizer Resolution is 1B/Sample.)

If you can benchmark your fetching throughput, and then subtract that from the calculated acquisition throughput, then you should see a number (in B/s) that reflects how quickly you are backlogging data.  In order for an acquisition to be sustained forever, that number must be essentially zero.

Hopefully that helps, 

-Andrew

[Schrockwell]

Hi Andrew,

First off, thanks for the prompt and detailed response. It is extremely helpful.

#2 will not be a problem, as this is more than enough time for the acquisition. Throughput should also be sufficient, as I've tested continuously writing to disk with one of the example VIs and it was able to keep up with the data rate. In this case it works out to only about 4MB/s total for two channels. I did not know about Queues, however, so I will definitely read up on that.

As for the graphs, I will update the UI infrequently, maybe once every one or two seconds, so I don't expect it to bog down the fetch cycle too much.

One thing I don't quite understand is how often the fetching occurs. If I set the number of records to the maximum, then after how many records will the fetch occur? Does it just happen "as quickly as possible", where the VI takes in any records that were captured since the last fetch?

[Schrockwell]

I was just playing around with the example "Multi Record Fetch More Than Available Memory", which describes exactly what you were saying in terms of acquisition. I changed the trigger to be from the External TRIG source. I found that when (samples per record) / (sample rate) is close to the trigger period, then the acquisition rate gets cut in half, as if the scope is missing the (n + 1)th trigger which appears immediately at the end of record (n).

For example, Fs = 2 MS/s and # samples = 8000 => 250 records are gathered in 2 seconds (should be one second).

However, Fs = 2 MS/s and # samples = 7000 => 250 records are gathered in one second, as expected.

This unexpected behavior is making me lean towards another solution, because the above method will not work if the scope cannot re-arm itself quickly enough. After some testing, it looks like the trigger re-arm time is around 7.5 us (edit: spec says 8 us, so that's confirmed). I suppose if push comes to shove I could toss out the last few samples to give the scope time to re-arm, but it's not ideal.

[Benjamin38]

Shrock, 

You are exactly correct with that Trigger Re-arm spec you mentioned for this 5152 digitzer as 8us.  If you are running into this limitation with your application you may want to try and disable the TDC (time-to-digital-conversion) Circuit which will can reduce rearm time in favor for a small trade-off.  If you set this property to False, it bypasses the TDC circuitry which allows the trigger to be seen as specified along your incoming waveforms.  When you disable this property, the trigger will be rounded to the closest rising edge of the sample clock.  If you look at the picture I have attached, you will see what I mean by the TDC calculating the trigger position based on the SampleClock edges.  

Setting this niScope Property to FALSE may reduce the re-arm time but will be set at the closest SC rising edge.  If you are working with the  EX Multi Record Fetch More Than Available Memory.vi, drag the niScope Property Node down to expand to three properties and go to -->> Horizontal:Advanced:Enable TDC

[Schrockwell]

Hi Ben,

Thanks for your reply and the screenshots. I tried disabling TDC, but this did not seem to make a difference in the trigger re-arm time. In fact, when I created the constant for the "Enable TDC" property, the constant initialized as FALSE, indicating that TDC was already disabled.

Perhaps there is no difference becuase I am using an analog edge ref trigger, as opposed to a digital trigger? I don't have SMB connectors so I can't test using the PFI ports as triggers right now.

[Benjamin38]

Schrock, 

The fact that you are using an analog reference trigger doesn't make any difference as far as it's default path to the TDC (see the help file below).  The fact on whether disabling the TDC will reduce re-arm time is unknown.  Were you observing the same 8ns of holdoff/re-arm?  If you are triggering on the the end of the SC period its possible you may see very little (or measurable) difference when you bypass the circuitry.  

[Schrockwell]

Hi Ben,

Yes, I saw the same 8us holdoff with TDC both enabled and disabled. I am triggering right at the end of the record, so I suppose there is no advantagein this case.

After some analysis, I will be able to tolerate the trigger re-arm delay in my data acquisition, so I will use this for now and revisit the issue if it doesn't work out.

Thanks again for all the help Andrew and Ben. I'm going to accept Andrew's reply as the solution because it sent me in the right direction.