The method you use to analyze your data is fine. The only thing I would watch out for is memory problems. If you keep with the numbers you gave earlier, 100 waveforms at 3000 pts/wfm, you will be transferring 2.4MBytes of data per set. This is way over the 1MByte buffer NI-SCOPE uses for data transfer. It will work, but it might be slow. If you have problems, switch to niScope Fetch WDT.vi for your acquisition and move it inside the loop. Before you call the fetch VI, set the record it will fetch by using the property node and setting Fetch->Fetch Record Number using your loop index.
A couple of other performance tips I think you probably know. The graph inside the loop will slow you down a lot. In addition, the graph of all the data outside the loop will also take a fair amount of time (plotting 2.4MBytes of data). If you want to see just the last waveform, pop-up on the terminal going out of the loop and disable indexing so only the last waveform goes through, not all of them.
Your analysis method should work fine. You may consider doing an I16 fetch instead of the WDT fetch you are currently using. This will reduce your memory usage by a factor of four, provided you don't immediately convert it to a double array. If your analysis is actually finding a max/min, this is faster on an integer array than a double. You can scale the integers using the numbers in the information cluster. It is much faster to scale one integer at the end than a whole array. That said, the I16 fetch is not particularly faster than the WDT fetch, just less memory. This choice will depend on your analysis.
The min record length is the minimum number of points the device will acquire. The actual record length is different if the acquisition rate you ask for is not one of the acquisition rates the device is capable of. The acquisition rate is then coerced to the next highest rate and the record length increased so your acquisition time remains constant. This behavior is part of the IVI specification for digitizers. Using your VI as an example, you ask for 300kS/s acquisition rate and 800 data points. What you actually get is 300,300.3003 S/s and 801 data points. The sample rate is determined by an integer divisor from 100MHz, in this case 100,000,000/333. So, if you really want a certain number of data points, you need to set the sample rate to a physically realizeable one. Alternately, you can just fetch the number you want instead of all the points, realizing your sample window will be a bit shorter than you asked for.
You are correct. To see anything in the records done, you need to delay. However, in this code, the records done output is really not doing anything. The fetch won't fetch until everything is done, so you know all is finished when your data shows up. I would just delete it. If you do want to put a delay in, wrap a sequence structure around the records done query. Add a frame before the current frame and drop a Wait (ms)delay into it. You can find this primitive in the timing and dialog palette. This is an example of when the sequence is actually useful. The delay VI has no good way of enforcing data flow, so the sequence does it.
The way you have implemented it, you don't need to poll acquisition status. To get acquisition status, use niScope Acquisition Status.vi. You would put this in a WHILE loop before your acquire and exit the WHILE loop when the acquisition was done (or an error occurred) to proceed to the acquisition. Make sure you also put an appropriate delay in the WHILE loop or it will eat your entire processor capacity. The delay should be based on how long you expect the acquisition to take.
You should definitely put your fetch code in a subVI if you are going to call it more than once. LabVIEW makes it easy. Select the code you need to make into a subVI, then select Edit->Create SubVI. Don't forget to put an icon and documentation in the subVI. You will thank yourself later.
Let me know if you have any more questions...
