Creating my own FFT and THD VI

[KostasB]

Hi Alex,

you don't need to delete the data in the shift register. The program is indeed getting slower as you are passing an ever increasing amount of data to perform THD and FFT analysis. The attached modified VI  performs the FFT only on the last 1024 points. To achieve that, you divide the array size by 1024 and if the remainder is 0 (e.g. if the array size is 1024, 2048, 4096 and so on), you perform the analysis to the last 1024 points. To do that, you use the 'Array Subset' function where you specify the starting index and the length you desire. In your case, the first time you perform the FFT, the loop iteration terminal count (i) will be 1023 so you start from the (i-1023) =0 index for a length of 1024 elements. The second time you start from the (i-1023)=1024 index for a length of 1024 and so on.

I hope that helped and definitely take a look at the link... the material there will definitely help you in the long term as well.

Regards,

KostasB

NI Applications Engineering

[bogiasac]

Thanks for your reply Kosta.

Your modification did the job!!! + the CPU load is still relatively low at around 28-32% and I get the correct FFT.

The material on the link you sent me looks very similar to LV Basics 1, which I have done a while ago. However, as my LV skills are rusty, I will at least browse through them.

However, now I am interested in triggering the sine wave (the waveform I acquire).

I have achieved this using the ‘Basic Level Trigger Detection VI’.

The problem is that the CPU load has now increased quite dramatically to around 60-70%.

I am wondering whether it is possible to reduce this value, by using the above VI more efficiently? I don NOT know, however, how I would tackle something like this.

I have attached the modified VI. Please have a look at it and give me some advice.

Regards

Alex

[KostasB]

Hi Alex,

One way of offloading the CPU is by adding a time delay in the while loops. Otherwise, the while loop will tries to execute as fast as possible and LabVIEW takes over the CPU.

Try to run the VI of the image with and without the time delay and compare CPU usage!

Regards,

KostasN

NI Applications Engineering

Message Edited by KostasB on 01-17-2008 11:12 AM

[bogiasac]

Thanks for your reply Kosta.

I am afraid I spoke to soon with regards to your previous post! The CPU usage slowly increases and my Labview program effectively takes over the PC.

By adding a time delay (of just 1ms) as per your last suggestion the CPU does stabilize at a high value of around 60%. However, the ‘# elements at queue’ variable increase at a rate of about 3000-4000 a second. This basically means that any change made on the AC signal after I have started receiving/processing data will not show (or will take over 5 minutes!!!.....to show).

I do understand that performing ANDing-ORing (string manipulation), division/subtraction, FFT and triggering can be a very computation intensive process.

However, I was wondering whether there is a way to make my program more efficient.

Apart from the efficiency of the FFT and triggering part, I am still puzzled at why the ‘Bytes at port’ property node produces so erratic data values when connected to the VISA Read.

I believe it was with you colleague Tom, who suggested ways of reducing the CPU usage, with respect to the VISA Read (the receiving of the data), on a previous post.

His modifications to my program, did reduce the CPU usage, but I never got the ‘Bytes at port’ property node to work along with the VISA Read. I was thus forced to read 2 bytes at a time, which works fine. However, from my understanding, reading 2 bytes at a time requires many more cycles compared to using (correctly) the ‘Bytes at port’ property node.

I am under the suspicion that my String Manipulation VI might be to blame for the improper processing of the received data and I am currently looking into that.

I believe this, because when I use the ‘bytes at port’ my CPU usage drops to 6%, the ‘Serial Settings:Number of Bytes at Serial Port’ and ‘# elements in queue’ are always at near zero value. However, it seems only a fraction of the data that arrives gets processed. From the attached picture one would expect to see at least 12000 points (80 points *50Hz* 3 second time frame shown on graph), but we only get a few hundred at most.

I am trying to find why this is. However, any advice for any of my VIs would be more than welcome.

Regards

Alex

[Tom O]

Hi Alex,

Kostas is out of the office at the moment so I'm helping out here!

I have made a couple of modifications that should allow the consumer loop to keep up with the data. The modifications were as follows:

1. The array in the shift register was growing infinitely, although only 1024 samples were used at a time. The array will now be "cropped" to the requested size to avoid the memory leak.
2. The FFT is now only performed every 1024 samples. Performing on every sample is, I believe, unnecessary as well as impossible to implement at these speeds. I hope performing the FFT every 1024 samples is suitable, this will still have a very fast update rate.
3. Similarly, the triggering is now performed every 1024 samples. I don't know if this is suitable for your application, but without this modification the consumer loop won't keep up. Perhaps there are other ways to approach your triggering that will have the same effect - I'll leave that to you.

The program will now run with a queue length staying at 0. The CPU usage when running the VI was quite low, too. Additionally, there should be no memory leaks. The boolean operations you perform in the string manipulation VI and the arithmetic you perform are really no problem at all for your CPU, these operations are the simplest CPUs of any kind can perform. The heavy use was coming from the FFT and triggering.

As for your issue with bytes at port, I'm not sure why this appears not to be working. Your string manipulation appears to filter numbers out, although I don't know enough about your application to know if this is the problem or not.

I hope these improvements help you to move forward, good luck with the rest of your project!

Regards,


Message Edited by Tom O on 01-24-2008 04:53 AM

[bogiasac]

Hi TOm. Thnaks for your reply.

I am afraid i can not open the VI as it is in LV 8.5.

Would it be much to ask for you to re-save it in LV 8.0.

Thanks

Alex

[Tom O]

Sorry about that!

This one should be fine.