My approach to local variables....

[crossrulz]

Where you should be storing this data is in shift registers.  That way all of the data stays on the block diagram and you avoid the extra (completely unneccessary) data copies.  And just because your computer has lots of RAM does not mean you should use it.  More memory usually ends up meaning slower performance.  And in the world I live in, I need all of the performance I can get.

[LeroyBogz]

Race conditions are not posible here, mostly these are read only values.

If everyone's advice is either 1)use FGV or 2) use wires, I'm not surE I agree.

Asthetics and readability matter;and I'm willing to sacrifice unimportant data flow.

[LeroyBogz]

---

you're trolling, right?

Using offscreen controls as data storage is an awful idea.

Clumping data together as a cluster is a good idea though. What you can do is to create an AE (Action Engine) with this cluster and use that.

---

Still not sure why it's such a bad idea, albeit crude.

I'll look into these action engine things, because everyone here seems to be in love with AE's, but it seems like the scope control is more of an issue with that.

And wires for stupid things that don't need to clutter the top level VI is undesirable. 

[BowenM]

---

@LennyBogzy wrote:
and I'm willing to sacrifice unimportant data flow.

---

...  ok.

[LeroyBogz]

---

@LennyBogzy wrote:
and I'm willing to sacrifice unimportant data flow.

---

...  ok.

---

Yes. 100 times yes.
 
If a user enters his name at the beginning I'm not stretching a wire throughout the entire top level VI to the logout subVI which says "goodbye Bowen". 

---

[BowenM]

What you are missing, sir Troll, is that you have one wire for ALL of them that you keep track of.  You have a type defined cluster and unbundle / bundle by name throughout your VI and store in a shift register.  It retains your dataflow, it adds greatly to readability, and it becomes increadibly easy to add additional functionality.

[crossrulz]

---

@LennyBogzy wrote:
Race conditions are not posible here, mostly these are read only values.

If everyone's advice is either 1)use FGV or 2) use wires, I'm not surE I agree.

Asthetics and readability matter;and I'm willing to sacrifice unimportant data flow.

---

Except for the fact that LabVIEW is a data flow language.  Data flow is always important.  If you can't follow a wire, then you have problems.  You are just making things more inefficient and harder on the compiler.

And based on your description here, you might as well just use global variables.  At least then you can still see the values by having the global VI open.

[altenbach]

---

@LennyBogzy wrote:
What do you guys/gals think about this approach? 

---

Well, you already got a lot of good feedback, so I just contribute my opinion that I don't think much of this approach. 😄

Why don''t you wire up a code skeleton and post it here. We will then show you how it can be done in a much more maintainable and efficient way.

Controls/indicators are for the UI. They should not be abused for tasks that belongs entirely on the diagram.

[LeroyBogz]

Sure.

Here is my VI. I think the "local vars" add quite a bit of self-documentation in addition to cleanliness.

[crossrulz]

Again, horribly inefficent.  Use wires.  If you can't figure out what the wire is, use the wire label.

I have a really good example floating around somewhere where I inherited a CRC calculation vi that was built with locals as you are showing.  I rewrote it to use shift registers and it was ~80x faster with the shift registers (~5ms with locals, ~61us with shift registers and wires).