LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Methods to break down large VI so that it runs faster

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.

 

 

Download All
0 Kudos
Message 1 of 68
(3,318 Views)

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

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 2 of 68
(3,292 Views)

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?

0 Kudos
Message 3 of 68
(3,289 Views)

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:

  1. The VI should fit on a single screen
  2. Wires should flow left to right and top to bottom. Avoid wires running backwards.
  3. Avoid excessive bends in your wires.
  4. Avoid doing unnecessary tasks in loops. Only do what has to be done on every iteration inside the loop. If it can be done once outside the loop then put it there.
  5. Avoid unnecessary front panel updates. Your code has a ton of controls and indicators being updated every iteration of your code.
  6. Try to separate the processing task from the user interface tasks.

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.

Message Edited by Mark Yedinak on 03-05-2010 02:14 PM


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 4 of 68
(3,287 Views)

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.

 

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 5 of 68
(3,277 Views)

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


"Should be" isn't "Is" -Jay
Message 6 of 68
(3,274 Views)

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
Message 7 of 68
(3,253 Views)

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


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 68
(3,241 Views)
The front panel is rather easily saved by putting the different plots in a tab control.

As for the code it's alot more problematic. What's wrong with the built in FFT? Or is the point to build/implement a FFT of your own?

/Y
G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 68
(3,226 Views)

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?

0 Kudos
Message 10 of 68
(3,173 Views)