03-05-2010 01:46 PM
I've attached the code for a very large vi that I created. I'm doing work with mass-damper-spring systems, under a given periodic input.
Thus, I've written code that solves the ODE for the system parameters, and the input function. The input function is arbitrary at this point, so I wrote a portion of the vi to execute a fourier series, summing sines and cosines to replicate the arbitray function. That section of the code also creates a string containing the equation that represents the periodic function, as a fourier series.
The problem is that the code, when all together, runs very slowly. I've written different parts of the code, and each runs smoothly on it's own, but I'm having a hard time figuring out the right structures to get it all put together. I apologize for the sloppy wiring in the attached vi.
I've attached two vi's, the first is the summation of all the code, and the second is just the fourier series portion, which I've then further simplified using subVIs.
Any pointers or suggestions would be very appreciated. I have tried using a main while loop, which would then activate the fourier portion, either in a case structure, or another while loop. Either method seems to max out my processor.
03-05-2010 02:07 PM
Have you tried to use the VI profiler? It will give you some stat on your program. However, you should make more subvi for the program before you run the profile. Everything is on the main vi now, it is very hard to tell what is what and what is doing what. My suggestions:
1. make more subvi.
2. use standard vi architecture, such as a state machine.
3. use event structure as much as you can and don't poll using input in a loop if possible.
Yik
03-05-2010 02:10 PM
I'm still relatively new to labview, can you just clarify two things:
What do you mean by state machine?
And what do you mean by polling inside a loop?
03-05-2010 02:10 PM - edited 03-05-2010 02:14 PM
Wow! Not to sound harsh but this code is so poorly written it is difficult to even begin to make suggestions on how to improve it. I use large monitors with high resolution and I needed to scroll all over just to see all of the code. Your user interface doesn't even fit on a single screen of the computer. You really need to break things down into more manageable pieces so that you, or anyone looking at the code, can even begin to understand it, have a chance at optimizing it. Take a look at the style guides or any of the threads where people ask for help in passing the CLD exam. I realize that you are asking for suggestions and I applaud you for that. But this code as written would take quite a bit of time to go through and understand it.
Some general guidelines to writting better code are:
These are just a few things that came to mind very quickly. A review of style guide will help as well.
Try to break your task down into small tasks. Avoid thinking about the problem as a whole. Make a list of the individual steps you need to do to complete the task and then think about creating a subVI for each step. Thinking about the problem in smaller terms will help you to optimize the individual pieces as well as identify things that may be able to be done in parallel.
03-05-2010 02:20 PM
Hi,
If you go to New... --> VI --> from template --> Framework --> Design Pattern, you can see what are the standard templates for design.
A suggestion on your front panel:
You really should fit your front panel onto one screen. Try to use a tab control.
03-05-2010 02:24 PM
While I concur with Mark wholeheartedly I would offer these two resources (and a Caveat about using Lots of sub-vis)
The Style guide can be found here and should be required reading for LV developers (I Link it at least twice a month)
You seem to have code that counld have very large data sets. LabVIEW makes data copies a lot For the code execution speed to improve you need to manage the data MUCH better and understand whats happening to the PC memory befor you create sub-vis (data copies) willy-nilly. Break it down on paper and remove the desired information from the large data first. then the sub-vis won't bog down the PC
03-05-2010 03:09 PM - edited 03-05-2010 03:10 PM
Thanks all for the suggestions. I will spend some time doing some reading and planning, then see if I can't simplify things.
No offense taken at the poorly written code part, that is, in part, why I'm here asking. Ultimately, that was the direction I was going with the second VI I attached, I just wasn't quite sure where to start.
After all, I'm not a programmer, I'm a mechanical engineer. I'm familliar with some of the concepts, but obviously have some work to do.
03-05-2010 03:20 PM
krwlz101 wrote:Thanks all for the suggestions. I will spend some time doing some reading and planning, then see if I can't simplify things.
No offense taken at the poorly written code part, that is, in part, why I'm here asking. Ultimately, that was the direction I was going with the second VI I attached, I just wasn't quite sure where to start.
After all, I'm not a programmer, I'm a mechanical engineer. I'm familliar with some of the concepts, but obviously have some work to do.
Message Edited by krwlz101 on 03-05-2010 03:10 PM
Yes- some work to do. But were here to help with pointers and resources. If its any consolation I grew up as an Electronics Technician. Now I do software- Go figure
03-05-2010 04:20 PM
03-08-2010 07:19 AM
There probably isn't a problem with FFT, other than my not being familliar with it yet. I had thought about this problem before attempting the labview portion, and figured that a fourier series would be easily implemented here. Didn't really look at the FFT.
I guess I figured a FFT was somewhat different than a basic fourier series? This isn't the case?