Is it ok to use local variables within the same loop?

[David99999]

Most examples for local variables show them being used between multiple loops. But what if my code is starting to get messy and I want to reduce the amount of wires in a loop, so I do something like the basic example above. Is this acceptable? Or will I get odd behavior? For example, if I used a shared variable with an RT FIFO; if I'm reading from the shared variable from multiple places I'll get undesirable results.

[StevenD]

That very simple code is the most basic example of why NOT to use local variables. There is no way to determine if "numeric 2" will be written to first, or the local variable read first. 

If you have too many wires, I would suggest making a cluster that can contain multiple values and data types.

[David99999]

---

@StevenD wrote:

That very simple code is the most basic example of why NOT to use local variables. There is no way to determine if "numeric 2" will be written to first, or the local variable read first. 

---

If they are being implemented between different loops, how is that making it determinable which will be read or written first?

---

If you have too many wires, I would suggest making a cluster that can contain multiple values and data types.

---

Great idea on the cluster, thanks!

[crossrulz]

You will have the classic race condition.  When is that local variable read compared to when the terminal was written?  You cannot determine this.  Data Flow is, by far, the most efficient method of passing your data around.  So if your loop is getting too unwieldy, you might need to think about your architecture.  Could things be moved to another loop?  Would it make sense to make more subVIs?  Could a bunch of wires be bundled into a cluster or, in my opinion, preferably a class?  (A class would likely combine the ideas of more subVIs (methods) and bundling the data (private data)).  There are a lot better ways to deal with messy code than switching to local variables.

[StevenD]

---

---

If they are being implemented between different loops, how is that making it determinable which will be read or written first?

---

It is still not deterministic. Wires dictate data flow and program execution. There are a bunch of tools that work much better than local variables (queues, notifiers, etc). 

[David99999]

---

@StevenD wrote:

---

---

If they are being implemented between different loops, how is that making it determinable which will be read or written first?

---

It is still not deterministic. Wires dictate data flow and program execution. There are a bunch of tools that work much better than local variables (queues, notifiers, etc). 

---

Copy that

[David99999]

Would a channel writer/reader setup be better than a local variable for sharing data between loops?

[billko]

---

@David99999 wrote:

Would a channel writer/reader setup be better than a local variable for sharing data between loops?

---

Probably over a billion times better, but I didn't check the math on that.

[StevenD]

My answer would be a reluctant yes. I haven't ever used a channel writer and don't really like how they look and feel, but they exist for this kind of thing.

A longer answer would be, as crossrulz said, think about better architecture. Without knowing what you are doing we can only give vague answers. Things like what you are doing with the data, how fast it updates, and your current architecture come into play if you want a better answer. Personally I like to have independent loops controlled by a queue (and optionally a notifier for return data) for any piece of hardware that is in my application. But, as the adage goes, more than one way to skin a cat. 

[altenbach]

---

@David99999 wrote:

But what if my code is starting to get messy and I want to reduce the amount of wires in a loop, so I do something like the basic example above. 

---

(You've already got good advice on why not do that, so I won't repeat)

Wires are not messy! Local variables are messy!

If your code is starting to get messy, the problem (and the solution!) is entirely elsewhere!!!