Hi, as i was new to the labview its some difficulte to understood, now i had done what you said and attached the files.
in that i had used 35000 samples but i need 160000 samples, as my computer does not support for that samples i done it as 35000.
When I analyze your data using different VIs, I get very similar results. I do not see anything which looks like a strong resonance, at least to the frequencies covered by this data set with the lower sampling rate.
What does Comsol predict the resonant frequency to be? How much damping does it predict? Do you have any reason to think the resonance is being excited by your tests - a reason other than what you see from LabVIEW?
I just had another idea. The DAQmx Write and Read run sequentially. If the excitation has completed before the measurement starts, all you would measure is noise. I do not have the SV toolkit so I cannot see what the signal transmitted looks like. What is the duration of the transmitted signal?
One way to work around that kind of issue is to start the Read before doing the Write. Do the Write in a parallel loop so that both are running simultaneously. Set the number of samples to read to a value substantially larger than the duration of the noise burst. If the buffers are not big enough to do that without errors, then do multiple smaller reads and accumulate the data in a shift register.
The concept is Start reading. Write noise burst. End reading. That way you are sure the data being read while the excitation is present.
Comsol predicts that resonate frequency at 20kHz and at 40 KHz, Sorry could you please elabrate the idea what you said......
and i had attached the word doc where we get some resonance....
OK. Thank you for the data.
1. The resonances are very sharp. From the appearance of the Comsol graphs I suspect that the simulation does not accurately report the width of the peaks. The frequency bins in the spectrum of the data you posted are ~2.1 Hz apart. It is conceivable that the noise excitation and the resolution of the spectrum result in missing the peaks.
2. You will not see any of those peaks because you are not sampling fast enough. The Nyquist limit for a 35 kHz sampling rate is 17.5 kHz, which is less than the expected resonances. Your 160 kHz sampling rate should be adequate.
3. The frequency resolution (df) of the spectrum is df = fs/N where fs is the sampling frequency and N is the number of samples. Ideally df will be smaller than the width of the resonant peak.
The attached VI shows the beginnings of a VI to read and write from/to DAQ in parallel. Because I do not have many of the subVIs, this has not been tested. It does not include any accumulation of Read data, partly because of the missing subVI.
Hi, I tried to run your FFT analysis.parallel vi but i encounter with an error says:
I have already tried to save it and change VI's and save again, it does nothing,
Some error codes are used by various devices and VIs to report different errors. You do not have any GPIB devices so the first explanation is the relevant one - Input parameter is invalid. Which subVI produced the error? The information should be in the Source portion of the error. I rarely use Simple Error Handler.vi so I am not sure how it reports the source information.
Usually that error results from an improperly formated physical channel name or a bad file name or something like that. Because oall the subVIs that I am missing, I cannot test the VI. Check the Channel Info control to make sure the values in it are correct. I had to do some creative cutting and pasting when I moved SVL Scale Voltage to EU.vi into the Process loop.
I think this may occur on the last iteration. The queue is released before the loop receives the stop notfication. The error is due to an invalid queue reference - after the queue is released the reference is no longer valid.
Try re-arranging the Send Notification and Release Queue as shown here.
Hi I made a changes what you said and now we have a new error at DAQ Read we have an error 200279 and at DAQ write we have 200016
I had share a screen of my vi could you please check it http://screencast.com/t/PUI0F5wl
I do not have DAQmx so I cannot suggest solutions. From the error descriptions it looks like you need to read or write faster. If the buffer is big enough, regneration on the write might help.
Since this is really a different problem, you might create a new thread about these errors.