Wise use of Local Variable

[Kyle97330]

---

@billko wrote:

Unfortunately, the forum does "pre-processing" of pictures before displaying them, so your snippet won't work.  You'll have to upload the snippet as a file.  

---

FYI you can use snippets that were posted in-line.  If you click them in the post, the forum enlarges them to fill the screen and also puts up a zoomed window of it with three buttons on the lower right of it (star, flag, down arrow) and if you click the down arrow it downloads the original file as uploaded, which you can then view offline as a png or dropping it as a snippet in LabVIEW.

[altenbach]

---

@gkartik wrote:

Instead, it can just point to the address of the variable and read it.

---

Compared to a wire, an indicator typically requires two more copies of the data (total 3x), each with it's own address. (1) What is held in the indicator and (2) the transfer buffer which holds the data until the UI thread can asynchronously update the front panel while the code can carry on with the downstream code, possibly re-using the buffer for in-place calculations, etc.. Any memory location that is accessed by multiple parts of the code requires protection so data cannot be written while it is read and vice versa. Imagine one code part writes a long array or complicated cluster while another part is trying to read it at the same time. Without protection, you might get a mosaic of old a new data if you are reading while the write operation is still occurring. Any additional local variable makes all this more complicated.

These are just some random (maybe even wrong) ideas, the detailed reasons are probably much more complicated. We have multiple CPU cores, many, many threads, data in RAM and copies in several cache levels, the OS that can swap out processes at any time, etc. etc. You are not juggling just one ball.

Trust me, the LabVIEW compiler team is absolutely brilliant and they know what they are doing. They would not do something unless there is a good reason for it. 😄

[billko]

---

@Kyle97330 wrote:

---

@billko wrote:

Unfortunately, the forum does "pre-processing" of pictures before displaying them, so your snippet won't work.  You'll have to upload the snippet as a file.  

---

FYI you can use snippets that were posted in-line.  If you click them in the post, the forum enlarges them to fill the screen and also puts up a zoomed window of it with three buttons on the lower right of it (star, flag, down arrow) and if you click the down arrow it downloads the original file as uploaded, which you can then view offline as a png or dropping it as a snippet in LabVIEW.

---

I didn't KNOW THIS.  Thank you!

[altenbach]

---

@gkartik wrote:

Well here is my VI, after using local variables. 

---

I can see many glaring race conditions that make the code completely unpredictable. For example you cannot guarantee that all the "Io Pt" and "To Pt" (etc. etc.) locals are only read after their indicator has been written by the code fragment far away. All of your "code boxes" depending on locals might operate partially on new and partially on stale values from the previous iteration. I would not trust this code at all!

[Kyle97330 · Accepted solution]

Back to the original reason for the post, since we can now see the block diagram, here's what I would do.

Put down a FOR loop in your While loop.  Wire a constant of "16" to the N input.

Inside the FOR loop, put a case statement with the selector wired to the iteration counter.  Add cases until there are 16 of them (0 to 15).

Inside each case, stick a comment at the top explaining what's being calculated ("No load test data", or whatever) and then do the calculations for one of the 16 sections of your code (that's how many boxes I counted on your diagram).

Pass out all of the arrays needed for your graph and assemble them after the FOR loop completes.

If you do that, the size of your block diagram is now just a bit bigger than the size of your largest decoration.  You also establish an execution order, so if you want to run one state first and use its results in a second state, the order of operations is definitive, and you can pass results from one box to another using shift registers (best) or local variables (easier).

Small other bits of advice:

Create icons for your subVIs.  Even just black text on a white background is better than the default icon.

Label your constants.  If you multiply by 1000, explain that you're converting from millimeters to microns, or whatever.

Consider using formula nodes instead of math nodes so that your math looks like math and not orange spaghetti.

Bump your loop wait time up to 15-20 ms.  Most monitors don't display faster than 60 Hz in any case, you're just churning the CPU for no reason if you have a loop updating a graph faster than that.

[JÞB]

---

@billko wrote:

Unfortunately, the forum does "pre-processing" of pictures before displaying them, so your snippet won't work.  You'll have to upload the snippet as a file.  I'm already afraid of what I'm seeing though.  You know that LabVIEW doesn't really flow left to right; it just appears that way because you connect the nodes together from left to right - usually.  That being said, the "floating code" that you have in there can execute at any time it feels, and if you have locals attached to it, you may or may not be operating with stale data.

---

Bill,  you can download the png from the picture manager then the snippet works fine

[johntrich1971]

As others have said, there are lots of chances for race conditions in this code. Also, I see lots of duplicated code - areas where you can make more sub-vis. If you make a cluster with all of your data, make a subvi for each of the blocks that you have separated by decorations, pass the cluster to each subvi and then unbundle by name and bundle by name (you would have a cluster in and a cluster out) you could line the functions up so that they execute in a known order and you don't have wires going everywhere and don't have lots of local variables. This becomes much more self-documenting (if you make descriptive icons, etc) and has a nice look with only one shift register required to pass your cluster from one iteration to the next.

[billko]

---

@JÞB wrote:

---

@billko wrote:

Unfortunately, the forum does "pre-processing" of pictures before displaying them, so your snippet won't work.  You'll have to upload the snippet as a file.  I'm already afraid of what I'm seeing though.  You know that LabVIEW doesn't really flow left to right; it just appears that way because you connect the nodes together from left to right - usually.  That being said, the "floating code" that you have in there can execute at any time it feels, and if you have locals attached to it, you may or may not be operating with stale data.

---

Bill,  you can download the png from the picture manager then the snippet works fine

---

Perhaps we should update the sticky at the top of the forum?

[gkartik]

"So, the calculation and the 8 reads can happen in any order!  Imagine, 4 reads of stale data, a write to the indicator and 4 reads of new data!  as an example!  without dataflow the values read are unknowable."

I don't know how local variables work. But from what you are saying, the data transfer from the indicator to all other local variables don't happen simultaneously. So it can cause problems and wiring can eliminate them. Am I correct? Can you some simple example to demonstrate your idea.

[gkartik]

@altenbach Could you please suggest me some resources from where I could learn good programming styles. Because it is difficult to make a good readable VI without good programming practices.