speed up execution of this VI?

[billko]

---

@Bob_Schor wrote:

Paradoxically, making a lot of sub-VIs ("encapsulate most functionality") will probably greatly speed up your code.  The reason I say this is that to grasp what is going on in its present form requires 24 monitors (or one of these wall-sized $10,000 monsters) to get a grasp of the whole thing.  If you start putting "pieces into little boxes", you will probably begin to see "Oh, I did that already over here" or "Oh, I could do those simultaneously rather than sequentially" (this is especially valuable if one thing is much slower than the other).  At some point, there may even be an "Aha!" moment when you realize a Much Better, Faster Algorithm (perhaps because you are only Doing It Once instead of 100 times).  

At least, this has been my experience in a few messes I've tackled ...

Strive to get the Top Level Block Diagram to a single screen (it can be done, but even 2 screens would be a big improvement).

Bob Schor

---

Writing LabVIEW without subVIs is like coding everything in Main() in C.

[Bob_Schor]

I like that "main()" analogy!  Yet how many of the VIs that are posted on the Forum fit this mold ...

BS

[Ralph@NES]

Bob,

I started looking at this over the weekend, and it seems to me that the big tickets for SubVI territory are the loops for each table/housing.  Only issue is that each of those has about 25 different control inputs and there's not enough terminals in the world to make that happen.

I'm probably at a point where advanced methods of passing data and controls are needed, and I'm not that versed yet.  I'm thinking local variables for all the controls, but I know you're not supposed to overdo those.

I'm not asking for any real legwork here or to have any of you talk me through great learning strides, but a nudge in the right direction for how to work those loops into subs would be appreciated.

[Dennis_Knutson]

You seldom need any connector other than the default 4-2-2-4 pattern. Multiple controls can be bundled together or into arrays if they are the same type. Not really that advanced a subject.

[Ralph@NES]

Dennis,

Thanks - I meant advanced for me and things that I've dealt with directly.

Does anyone think it's sufficient to simply subVi those large table loops, or should smaller sections of those be turned into Subvis?

[Bob_Schor]

I just opened your Project and took another look at Main Front Panel to try to suggest ways to bundle related Wires together (bundle = Cluster, which allows you to make a Big Conduit filled with all sorts of wires, including Arrays).  I noticed that some wires looked like they had data flowing backward in them, that is, they looked like they came in on the "input" (left) side of a While loop, yet entered the "output" (right) side of a Case and the right-side of a sub-VI.  Curious, I tried to open the sub-VI (one was TABLES File Analsysis and Matching G001), mainly to look at its Connector Pane.

To my surprise, this sub-VI (and many others) had no connector pane, and appeared to be "locked" in some way.  In some cases, I could see the Block Diagram, but could not gain access to any VI Properties.

Can you provide "unlocked" versions?  It is pretty difficult to make sugggestions about how to organize the multitudes of wires and data flowing around here if we can't clearly see it!

Bob Schor

[Ralph@NES]

That's odd, everything should be unlocked and the password restriction removed.  I'll look again.  I've also begun writing a description for the main front panel.

[aeastet]

It is because the vi has a reentrant execution. If you go to the edit in the menu you have to change it to edit mode.

[Ralph@NES]

Oh yes, what he said. It's opening as a clone and in 'operate' mode.

Thanks for catching that.

[Ralph@NES]

I'm trying to attach an update that has the VI description, unfortunately the forum keeps rejecting the zip file.