My approach to local variables....

[LeroyBogz]

Right, but efficiency is not a concern! I have another high-speed data aquisition application where it certainly is, but for something that's simply a test executive who cares?

Adding wires will clutter this and make it more intimidating for maintainers.

[altenbach · Accepted solution]

Well, that's not code, just a (very long!) picture. Sorry, I don't have teststand.

(I guess, opinions on the concept of "cleanliness" vary. Local variables make any diagram look dirty in my mind. :D)

If you would keep all your data in an action engine (or even globabl variable), your subVIs would not even need most of these inputs.

[RavensFan]

The first frame called User Setup is the epitome of what is wrong with using local variables.  Do you realize you have a huge race condition there?

You read from the local variable of a cluster called Local Vars at two different spots.  Then you bundle in a new value in each one then write it back into a local variable.  Depending on what executes first, the change where you updated the value in one piece of code, winds up getting overwritten in the other piece of code.  (Heck, why didn't you update both of those in the same Bundle by Name?)

I'll admit that your code does look clean.  But because you didn't take proper lessons in LabVIEW to learn dataflow programming, you are making huge mistakes that are going to cause bugs in your code.  It may even act one way when executing one time, and completely differently another time.

Please take some lessons.  Don't keep posting ridiculous statements on the forum trying to validate your programming style which is obviously broken.

[LeroyBogz]

Dude, chill.

You're right, there is a race condition in the user setup frame of the version of the program i posted, but nothing a flat sequence wouldnt fix.

In the end I'm going to use FGV, which will clean it up even more. I've gotten some good advice on this thread from some people.

Thanks for the advice on the lessons. I'm going for the CLD soon...hopefully I can take some by then.

Updated GUI attached

[crossrulz]

---

LennyBogzy wrote:

In the end I'm going to use FGV, which will clean it up even more. I've gotten some good advice on this thread from some people.

---

And you still have the same race conditions from the local variables.  If all you are doing is a Set and Get case in your FGV, then you might as well use a Global Variable.  The global will be faster and will be easier to maintain.

---

LennyBogzy wrote:

You're right, there is a race condition in the user setup frame of the version of the program i posted, but nothing a flat sequence wouldnt fix.

---

You mean nothing a simple WIRE wouldn't fix.  That would be a lot easier to read and it eliminates the race conditions.

[altenbach]

---

@LennyBogzy wrote:

... , but nothing a flat sequence wouldnt fix.

---

I thought they said that about duct tape too 😄

[LeroyBogz]

---

LennyBogzy wrote:

In the end I'm going to use FGV, which will clean it up even more. I've gotten some good advice on this thread from some people.

---

And you still have the same race conditions from the local variables.  If all you are doing is a Set and Get case in your FGV, then you might as well use a Global Variable.  The global will be faster and will be easier to maintain.

---

LennyBogzy wrote:

You're right, there is a race condition in the user setup frame of the version of the program i posted, but nothing a flat sequence wouldnt fix.

---

You mean nothing a simple WIRE wouldn't fix.  That would be a lot easier to read and it eliminates the race conditions.

---

I believe you are mistaken. No race conditions, I have 3 different non-reintrant FGV's.

Also no thanks on the wires, this is a much cleaner top level VI, which will be easier to maintain.

EDIT: also, I support writing individaul elements to clusters, so it's beyond a simple set and get.

[RavensFan]

Again with the "Dude"  ????

So  a functional global variable that is properly designed to update the different elements of a cluster is better than using a local variable.  What a novel idea.  If only someone in this thread prior to now had mentioned functional global variables, and also warned you that using local variables was a bad idea.

[LeroyBogz]

Bro, it just means I respect you. You should feel proud.

[Yamaeda]

---

@LeroyBogz wrote:

Sure.

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

---

You have a race condition in the Edit me-structure for starters, which is a typical problem with heavy Local usage.

I understand your issue about very long wires adding clutter in such a large VI. The solution is actually rather simple, change it to a State machine. You already have well defined function blocks, make the each a case in a case structure and you'll end up with a few well defined states in a much smaller VI. Then the wire flow through the VI will be of little concern.

/Y