Methods to break down large VI so that it runs faster

[charris]

If you're interested comparing your current VI implementation with the LabVIEW FFT function, the detailed help has a fairly in-depth overview of the math used.

FFT VI - LabVIEW Help

FFT Fundamentals - LabVIEW Help

[Yamaeda]

---

krwlz101 wrote:

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?

---

This reminds me of an old project where i implemented a Fourier transform on a one-chip ARM computer. The basic formula is easy, but the calculation was slow. After finding some FFT code (which uses the cycling nature of the calculations alot) the result was 40-80 times faster.

/Y

[krwlz101]

Here is what I am, (and was) thinking on the fourier part.

I've used Fourier Transforms in both Dynamics of Mechanical System, and in Circuits.  I don't think what I'm doing is a transform.  I'll be honest, those classes were a while ago, so I need to relearn, but...

I am actually just looking for the time based function that reasonably approximates the periodic input. The FFT instead transforms the signal into the frequency domain with use of complex numbers.

I may be missing something here, and if I am, a pointer would be much appreciated, but I don't know (or remember) how to use a FFT to get what I'm looking for.

The crux of this is that I need to write this function into the Equation String for an ODE solver, thus I need the actual sine and cosine terms.

[krwlz101]

Ok,

So I did some homework, and some planning, and I'm in progress on fixing this vi.  So far so good, I wrote some of the sub vi's and I'm in the middle of putting together all the parts.  Attached is the main vi.

My questions ultimately come down to:  Should I be using a state machine?  Event structure seemed simpler to learn (arguable, I'm sure) but I'm running into some snags.

So, this vi solves the ODE for a mass spring damper system (specifically, the one found in a helmholtz resonator).  I have not implemented the forced response section yet, just free response to initial conditions.

The vi takes the system parameters (on the left of the FP), and computes the ODE (any time a parameter is changed).  When the Solve button is pressed, the solution is computed, and the displacement, velocity and acceleration arrays are computer and passed to the shift register.  I have the graphs updating on a button click, as I like to use the graph pallet, and can't with constantly updating plots.

The functionality I would like to get out of the vi is:

Load system parameters on initialization (if they are already entered, currently i need to change one of them, then put it back)

Resolve the ODE every time system paramters change.

Update the graphs every time the ODE updates.

None of this seems difficult, I'm just not seeing the methodology.

Hopefully this vi is improved compared to the last one.

Message Edited by krwlz101 on 03-10-2010 01:44 PM

[Yamaeda]

Your new VI looks alot better!
3 small tips, which makes no real difference:
- You can expand the Index array function to get the 4 indexes directly.
- Your Solve Value change comparison will never be true, as the event wont trigger if it's the same. 😉
- There's no need for the external wait, the timeout to the event loop will cause the Timeout event to trigger every second and thus the big loop will fire, and if you have severals events in queue you probably want to solve them as fast as possible, with the 150ms wait that's the max speed.

/Y

[krwlz101]

Well,

Thanks too all that helped.  I decided to implement a state machine rather than simple event structure, and my life just got so much simpler.  To be honest, I now feel like I actually have some idea of what I'm doing in labview.

I've attached the latest vi to see if anyone can give me any last pointers on this one.  I know I havn't documented this part of the vi yet, but it's on the to do list.

One question I did have is:

In this situation, is there any benefit to initializing all the shift registers?

Also, I know it's a little wide, another task on the current to do list.

Message Edited by krwlz101 on 03-11-2010 09:34 AM

[Mark_Yedinak]

It is always a good idea to initialize shift registers unless you specifically want an unitialized shift regiser (i.e. a functional global or action engine).

As for the code it looks MUCH better. There is no need to have the timeout case in your event structure since all it does is send you right back to the idle state. If there is no timeout defined the event structure will simply wait for the next event. However, you would need to add an event to handle the Stop button. This would also eliminate the superflous Or on your Stop value. Every case passes a False to it so the only value that will affect the test is the value of the button. If you stick with the poll of the Stop button you should create an artificial data dependency so it is read after the execution of the case statement. As written your code will generally run one extra iteration than what you intend.

Since you didn't include all of your code I can't see how you are updating your controls and indicators. Are you using references? I generally prefer a producer/consumer architecture with the prodcuer handling all of teh user interaction and the consumer as the state machine. I may include a third task to handle updating indicators on the front panel.

Message Edited by Mark Yedinak on 03-11-2010 09:55 AM

Message Edited by Mark Yedinak on 03-11-2010 09:57 AM

[krwlz101]

The stop issue is easily fixed.  Would eliminating the OR, and just passing the stop button to the stop terminal work just as well?  I don't actually have any reason to stop from within the case structure, I anticipated doing so when I started, but now see no reason.

Currently the front panel indicators are tied to the cluster that passes through the shift registers, and controls are just hanging out in the main loop.  Is this not prefered for some reason?  I intended to put a small wait in there for processor reasons.  Graphs update on the case structure after any ODE change.

Also, what code did I miss?  Just the subvi's?

Message Edited by krwlz101 on 03-11-2010 10:16 AM

[Mark_Yedinak]

I prefer to use an explicit event in the event structure to catch the Stop button. I also add events for Application and Panel close events. The reason I asked about your controls and indicators is that several are just sitting there. They are not wired to anything. These were the onces I was concerned about. I can only assume you are using references in subVIs to manipulate them or there is code that hasn't been implemented yet.

[JÞB]

---

krwlz101 wrote:

Well,

Thanks too all that helped.  I decided to implement a state machine rather than simple event structure, and my life just got so much simpler.  To be honest, I now feel like I actually have some idea of what I'm doing in labview.

I've attached the latest vi to see if anyone can give me any last pointers on this one.  I know I havn't documented this part of the vi yet, but it's on the to do list.

One question I did have is:

In this situation, is there any benefit to initializing all the shift registers?

Also, I know it's a little wide, another task on the current to do list.

Message Edited by krwlz101 on 03-11-2010 09:34 AM

---

Defininatly going in the right direction!

Personally- I would place the event structure in a "Producer loop" by itself and pass the event driven "states" to a "Consumer Loop" that holds your state machine.  Why-you ask? because I expect some of the states take a discrete amount of time to execute- look up the help "Caveats for using event structures".  When the event structure is not executing (when you are in an active state) the FP events still enqueue to the event structure- this leads to unresponsive FPs.  By seperating the event loop and the state machine that it controls you ensure that all events can be acted on immideatly (the state commeands are immedatly queued) and the FP doesn't "lock up."

As far as the USRs go.  well USRs are memory elements and retain the last value between successive calls.  This CAN lead to unexpected results.  Unless you WANT to retain these values ( and trust me there are times its nice to have a USR see: Ben's nugget on AEs ) It is good practice to initialize the SRs.  I'd hit them in a code review-but those are my standards and a matter of style as FOR THIS code it seems not to matter (yet-the code may change and the USRs could still come back and bite you later)

Coming along nicely - and it LOOKS like you are getting the hang of it.