I've created this VI that perform a spectral analysis of a 0-1000 Hz sinusoidal signal.
In the "simulation" all works as espected with a very fast response to frequency (manual) changes:
Than I've modified the VI connecting it to a real signal (generated by means a real function generator) and acquiring the signal by means an USB-6000 interface and DAQ Assist and configuring the new VI with the same number of sample (10000) and the same rate (10000 kS/sec).
This real VI, however, is more slow and more inaccurate than the Simulated VI and don't seems to works in the same, reliable, manner.
The question is:
is the hardware inadequate or are there any settings than may I change to make the "real" VI working as the "simulated VI"?
And if the HW is inadequate to wich parameters must I look to purchase an "adequate" acquisition HW?
Thanks in advance
Solved! Go to Solution.
LabVIEW uses the Principle of Data Flow. Among other things, this means that a Loop cannot iterate until every function inside the loop has run. Furthermore, you have two Express VIs (boooo!!) connected in series (naturally, because the FFT requires the data from the Dreaded DAQ Assistant), which means that the first loop will take 1 sec (for the DDA) + however much time it takes to process 10,000 points (should be fast, but with an Express VI, who knows? It certainly won't necessarily be "express").
Also, next time attach your VI. There may be other errors "buried" inside your Express VIs that we can't see in the picture.
Hi Bob, thanks for your fast reply.
I'll follow all your suggestions and I'll let you know.
Attached to this reply is my VI.
Thank you for attaching your VI. I was worried that, as a beginner using the Dreaded DAQ Assistant instead of DAQmx, you might have chosen (as I can now see you did!) to set the Acquisition Mode to "N Samples". You are sampling 1000 points at 10 kHz, and then passing the data to the FFT. So let's look at what happens:
Do you see the problem?
The alternative to N Samples is "Continuous Sampling". This means that the underlying DAQmx is told (in effect) "Take 1000 Samples. As soon as you have them all, output them and start taking the next 1000." Does this make a difference? Let's see ...
Note that the key point is that the processing step must complete before the (next) acquisition step finishes.
A lot of stuff !
I'll study it and then update this thread with my experiences.
Thanks a lot
Hi Bob !
I've an update.
I've re-create the VI using normal VI instead Express VI:
The real issue is that when I set sample rate (i.e. 1000 kS/s) equal to # of Sample (i.e. 1000 sample), the refresh rate is equally the same ( 1 sec and than too slow).
The reason because I must set the sample rate = to # of Sample is to prevent the scattering (see this post: https://forums.ni.com/t5/LabVIEW/Spectrum-analysis-strange-behaviour/m-p/4032339#M1156460).
Thanks in advance.
P.S. attached is the new VI
Thanks. I found two minor errors -- you originally took 1000 samples at 10,000 Hz, but here you do 1000 and 1000, so I changed it back to 1000 samples at 10kHz. Second, the FFT plot should (initially, at least) have the X and Y axes set to "Auto-scale" -- who knows what the values really should be.
Now, I don't have a DAQ device (nor signal generator) to test this, but in the true Spirit of LabVIEW, I build a "Dummy Signal Generator" and connected it to my "Dummy A/D" that samples at 10kHz for 1000 samples, taking 100 msec to do so, and fed it to your analysis routine. It runs just fine, all the Graphs plot (showing we can update the plotting at 10 Hz), and the numbers seem to be reasonable.
Here's the code, in the form of a Snippet (I'll attach the actual VI, as well).
The first While Loop simulates an A/D converter sampling 1000 samples at 10kHz, requiring 100 msec to run (look for the numbers 1000, 10k, and 100). The Function Block is on the Waveform Palette -- it serves as the Function Generator for "Tones and Noise" -- two Tones at 200 and 433 Hz, amplitudes 1 and 0.3, and RMS noise of 0.2. So every 100 msec, this function generates 1000 points, as though it were an A/D connected to known (but noisy) signals. So then what?
So I'm a great fan of Asynchronous Channel Wires, which allow you to send Data across ("asynchronous") the boundaries of LabVIEW Structures. You can think of them as re-packaged Queues. The gadget getting the output Waveform from the "A/D" is a Stream Channel Writer -- it packages the data and sends it out of this While Loop and into the next one by means of a "Magic Pipe". It also has some additional inputs, one of which is "Last Element?", to which I wired the Stop button so that I can stop the A/D.
The next While Loop has the corresponding Channel Reader, whose output will be the data that was place in the corresponding Channel Writer (i.e. from the A/D). The rest of the processing is just your FFT and two plots. The Channel Reader also brings over the "Last Element?" signal from the first loop, so when I stop the first loop, it sends the "Stop" signal to the second loop, and everything stops. Note that if we slow down the first loop (say, by changing the Wait time to 1000), the second loop will "slow down" too -- it cannot run unless the Channel Reader has been given some data, so Loop 2 gets "clocked" by Loop 1. [I should point out that it can run slower however -- try putting a 200 msec Wait in the second loop, run for a few seconds, and press Stop. See if you can explain why the program "seems" to have ignored the Stop (Extra Credit)].
You might have heard of the "Producer/Consumer Design Pattern" -- that's exactly what this is, two independent loops running asychronously in parallel, with a data communication path such as a Queue or Channel Wire that "sneak past" the boundaries of the LabVIEW Structures.
So fix up your original code, and try it out. It should work.
Sorry for delay.
I've thoroughly studied and tested your suggestions.
I think the your better suggestion is related to the use of normal VI instead of Express VI regarding the DAQ VI.
In fact as you can see in the following video, even using 10000 sample at 10 KHz, I've a satisfactory fluidity and a fast response in the Spectrum Analysis (that is what I was looking for😞
This is very similar to a fully simulated instrument like this:
Using the stream channel (that is a very interesting thing) the results don't changes significantly.
I've very appreciated your help and your suggestions and I thanks you.