Why some people say Local Variables are bad...

[Broken_Arrow]

---

DianeS wrote:

Here's one I responded to just today.

Note the sheer number of "Wheel circumference" locals, all hanging out together in the same loop. 

---

That's just lazy wiring.

I have noticed that some EE's will take their habit of using "ports" to connect circuits together on one page (to keep from crossing lines) and carry that habit over to LabVIEW using Locals. Maybe that's the case here. 

[DianeS]

The thread can be found here.  The OP says that he used all those locals for clarity.

Clarity?  Locals?

While the rest of the code is not a thing of beauty, I've shown you the worst parts.  However, he threatens that it's going to grow over the next few months...

...oh lordy.

I encouraged him to research code architectures and choose an appropriate one BEFORE things go any further out of control.

[Ray.R]

---

Broken Arrow wrote:

I have noticed that some EE's will take their habit of using "ports" to connect circuits together on one page (to keep from crossing lines) and carry that habit over to LabVIEW using Locals. Maybe that's the case here. 

---

That is probably the case.  Yes, lables are a good idea in a schematic.  Especially unique names for each net.  If you do any boundary scan sw, you'll know what I mean.

But to impliment something similar in LabVIEW using Locals is borderline insanity...  (for whoever has to read that code)

[Ray.R]

 From: http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=473355

When you have unwired controls, use them instead of Local Variables.  Don't try to program like a text-based language.

Also, when using a producer-consumer or event structure with a consumer loop (not as shown below), I suggest using a queue.  The queue can deal with multiple events.

[JÞB]

---

Ray.R wrote:

Good catch Diane.  I can only imagine what the rest of the code looks like.

The bigger question is: where do you start debugging such code?  😉

---

Its kinda like catching bugs in a rainforest.  Start anywhere- There's plenty to go around

[Ray.R]

 This is both abusing Locals and more of a Rube Goldberg.

There is no need for using Locals when the controls can be wired together, especially when they are next to each other as seen at the bottom of the diagram.  Glad I didn't look at the rest of the code...  😮

[Yamaeda]

Amazingly the progam works. Mostly (we just found a rather serious error due to localitis today). It's clearly not good LabVIEW, but it is structured and as such the results are mostly correct. I dont know how much i dare show you guys, but the design idea is:

State Machine, implemented through 3 nested case-levels of integers.

To ensure data to all sub-vi's it's all stored in globals

As much data is in the globals few wires is needed to transfer data so sub-vi's use the globals, often by copying it to locals

To ensure globals are written before used much is in stacked sequences

All code should be editable on 800x600 screens (sic!)

Combine this with an unbundled error thread to only run if no error, a few run time cases and you have up to 6-8 grey squares before you actually do anything. Ofcourse these cases have lots of locals and duplicate code, and identical cases.

It feels like it's all done with the hardest limit being the 1 screen code, then shell for shell built inwards until it'll collapse like a black hole.

I do believe it can be saved though, just adding terminals and wire directly allows for some sequences to be removed making it alot spacier and more readable.

/Y

[Ray.R]

---

Yamaeda wrote:

I do believe it can be saved though, just adding terminals and wire directly allows for some sequences to be removed making it alot spacier and more readable.

---

Glad to read that you are making improvements to the code.  

It is amusing to read that Locals, Globals and Stacked Sequences in order to keep the block diagram to a single screen..  😄

[Ben]

---

Yamaeda wrote:

Amazingly the progam works. Mostly (we just found a rather serious error due to localitis today). It's clearly not good LabVIEW, but it is structured and as such the results are mostly correct. I dont know how much i dare show you guys, but the design idea is:

State Machine, implemented through 3 nested case-levels of integers.

To ensure data to all sub-vi's it's all stored in globals

As much data is in the globals few wires is needed to transfer data so sub-vi's use the globals, often by copying it to locals

To ensure globals are written before used much is in stacked sequences

All code should be editable on 800x600 screens (sic!)

Combine this with an unbundled error thread to only run if no error, a few run time cases and you have up to 6-8 grey squares before you actually do anything. Ofcourse these cases have lots of locals and duplicate code, and identical cases.

It feels like it's all done with the hardest limit being the 1 screen code, then shell for shell built inwards until it'll collapse like a black hole.

I do believe it can be saved though, just adding terminals and wire directly allows for some sequences to be removed making it alot spacier and more readable.

/Y

---

That sounds like C code expressed using LV. Am I correct that is your code Y? If so have you seen my Nugget on using Action Engines? Forgive me if I'm misreading this thread. I just want to make sure the regular contributors don't get blind-sided by Globals.

Ben

[Dennis_Knutson]

Just part of the disaster that is here.

Message Edited by Dennis Knutson on 02-25-2010 09:02 AM