Methods to break down large VI so that it runs faster

[Ben]

---

Mark Yedinak wrote:
...(Though Ben would argue that a queued state machine is not a true state machine.)

---

 You are correct!

In my book a state machine realized a state transition diagram (or a finite-state machine) where every state has a finite number of tranisitions into or out of a finite number of states.

A QSM does not have a finite number of transitions into or out of states and are impossible if not difficult to represent using a State Transition Diagram, so they are not TRUE state machines.

Ben

[krwlz101]

Well,

I'm OK with a QSM not being a true state machine.  

Now, on to other issues.  I am begining to use this program for what it was designed for in addition to constantly tweaking.  One thing I'm running into is the definition of my unit function.  

The definition works well, and the fourier series is sufficient for the moment.  However, I am exploring the response to the input, and would really like the baility to tweak the curve just a little bit each time I press "Load Input Function".

In other words, it would be fantastic if my numeric inputs retained their value from the last time the VI was called, so that I could just modify the curve, rather than trying to match up fresh inputs to the last curve, and then making modifications.

Is there a way to do this?   Obviously we can't send values into a control, so...  Perhaps I could reset defaults from the main vi prior to each call, as RavensFan indicated was possible?

Would that even work, since the main vi loads all other vi's when it loads?  If that is the case, is there any cons to reloading vi's for each call?  Speed I would imagine?

[krwlz101]

EDIT:  Did not mean to post.

Message Edited by krwlz101 on 03-17-2010 03:27 PM

[krwlz101]

Got it.  Invoke node + AE.

So at this point I have a few AE's.  Is there any real advantage to condensing them into one super AE, with multiple ins and outs?

I kind of like the ones I've created, only because they each carry one type of data, and I've got them color coded, which is nice.  But if there are any real memory or processing speed implications, I would condense in a heartbeat.

Message Edited by krwlz101 on 03-17-2010 04:08 PM

[Mark_Yedinak]

I would create your action engines to function on a related set of data. I wouldn't combine a bunch of unrelated stuff just to minimze the number of AEs you have. Your AEs should function on a single, related set of data.

[krwlz101]

Thanks again to all that helped on this thread!  My feet are now firmly planted on the path to quality VIs!

I think that I've got enough under my belt to continue on.  If I need more help, I can either search other posts, or start a fresh thread.

Thanks again!

[JÞB]

Great-

It was fun watching you work so hard!

[Mark_Yedinak]

---

krwlz101 wrote:

Thanks again to all that helped on this thread!  My feet are now firmly planted on the path to quality VIs!

I think that I've got enough under my belt to continue on.  If I need more help, I can either search other posts, or start a fresh thread.

Thanks again!

---

You're welcome. It was a pleasure helping someone so eager to learn and willing to listen to our advice. Stop back anytime if you have more questions.

I would start a new thread though.