Multiple recording of waveforms using an external trigger signal

Question

Dear all,
Maybe somebody could help me with the following:
System:
Windows 2000,Pentium III,~800-900MHz,32-bit master PCI bus,256 MB RAM
PCI-NI 5122 Digitizer
PCI-GPIB card
PCI-DAQ card
Labview 7.1
NI Scope 2.7
Problem:
I want to acquire multiple waveforms (e.g. 100) using an external TTL trigger signal of ~40Hz. I have to acquire 1 waveform per trigger signal i.e. 100 subsequent trigger signals will acquire 100 subsequent waveforms.
After, or during the waveform acquisition (?), I have to transfer the waveforms as 100 1D-arrays from the onboard memory of the digitizer through my fitting routine (one-by-one!). The fitting routine accepts one waveform (1D-array) at the time, fits the waveform and calculates 1 fit-value per waveform. So, when I pass the acquired 100 waveforms subsequently through the fitting routine, I need to get out a 1D-array with 100 fit-values. This 1D-array with the 100 fit values will be further processed and a final value will be saved.
This procedure will repeat itself at different points in a sequence structure. The sequence structure will be located in a loop and running for several hours!
Please see attached program flow diagram.
Qustions:
1. When I want to acquire 100 waveforms using 100 subsequent trigger pulses, the attached VI (Multiple_record VI) gives me the following error message:
ERROR
"Possible reason(s):
Driver Status: (Hex 0xBFFA4009)
A previous acquisition is still in progress. If you are attempting to change an attribute, note you can only change fetch attributes while an acquisition is still in progress.
Status Code: -1074118647
What am I doing wrong? Is there a better and more efficient way to do this?
2. How can I transfer the 100 waveforms from the digitizer, one-by-one as 1D-arrays, through my fitting routine? A waveform will have ~2000-3000 data pts. (DBL type). Remember: I DO NOT HAVE TO SAVE THE WAVEFORMS!
3. Which way is faster, and more efficient (memory) for my PC system to transfer the waveforms from the onboard memory of the digitizer to the fitting routine?:
a) Start transfer of already acquired waveforms (1D-arrays), one-by-one through the fitting routine, during the waveform acquisition process is still in progress?
b) First, acquire the 100 waveforms (1D-arrays), store them in the onboard memory (digitizer) and then transfer them one-by-one through the fitting routine?
4. How can I make sure that after the waveforms were transferred through the fitting routine, the onboard memory of the digitizer is EMPTY (clear waveforms which have already been fetched) and ready to repeat the waveform acquisition at a different point of the sequence structure?
5. I do not want to display each acquired waveform because I think it will slow down the acquisition process. Instead, I want to display the last of the acquired 100 waveforms, so I can check my fit and maybe adjust the fit-parameters. How can I do that?
I think the important thing is to perform this process in the fastest way possible with the best use of the PC resources (memory etc.) because this process will run for hours. Any suggestions?
It would be very nice if somebody could give me some help with this.
Kind regards,
beam
Attachments:
program flow diagram.vi ‏11 KB

Answer 1

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...
This account is no longer active. Contact ShadesOfGray for current posts and information.