Local variables for clean code

[pobrepablo1]

A question of style and LV correctness: 

I'm quite aware of the risks of these guys, but I see no option here. Right now I have a program with ~35 events in an event structure. I have a wire that contains many device settings that only 2 of these events can change. About 6 events in total require the use of the data on this wire.

Now, I see two choices:

1) I can use a shift register and drag the stupid wire across 35 frames and then remember to do it in any additional frames when I add more

2) I can use a local variable.

This seems much, much cleaner to me, and I see no better way of doing it. My question is, is there? I've looked up feedback nodes, but I think I can only use them in single event cases. Their data doesn't seem accessible beyond one event case. is there some better option? The data on the wire is an array of objects (classes), if that helps. 

[Mark_Yedinak]

Provided you use these local variables ONLY within the event structure you will not encounter any race conditions. However, I would still prefer to use shifts registers to pass the data between events even if only a few are going to use them. What version of LabVIEW are you using? Starting in version 10 you can automatically wire up the unwired tunnels within an even/case structure.

The problem with using the local variables is that you will create additional copies of your data. Not a problem if the data is small but it can be a problem if the data is fairly large. The other issue is that it does hide the fact that the data can be modified. The shift register and wire running through is a very clear indicator that the data is subject to change. The other benefit is that the data will be available in any event. If you find you need the data in more events cases you start to get a local variable explosion. If you want to minimize the number of wires you can always use a cluster to aggregate the data and run one or a few wires (I like to make local aggregations) through the event structure.

[altenbach]

---

@pobrepablo1 wrote:

1) I can use a shift register and drag the stupid wire across 35 frames and then remember to do it in any additional frames when I add more. 

---

A wire is never "stupid".

You can link the tunnels and all wiring will be automatic when you add new events or cases. so that arguments is invalid. 😉

[pobrepablo1]

Our program is only one event structure. I'm using 2011; automatically wire the tunnels? That's a nice feature. Didn't see that. Still though, I object on principle to having a wire across every one of my diagrams, it's cluttersome .

But, it's a good point that it will create copies. My dataset is not small, but it isn't huge. Since we're dealing with linear CCDs, aside from some trivial settings I have arrays - arrays of about ~2000 doubles, and a max 3 arrays.  So I'd perhaps have 6000 elements in arrays running around. This probably is not ideal. 

I thought of a compromise, how about I use a shift register but wire it around my event structure, through a case structure breaking the wire only when I need to? i.e. see attached

[Mark_Yedinak]

---

@pobrepablo1 wrote:

Our program is only one event structure. I'm using 2011; automatically wire the tunnels? That's a nice feature. Didn't see that. Still though, I object on principle to having a wire across every one of my diagrams, it's cluttersome .

But, it's a good point that it will create copies. My dataset is not small, but it isn't huge. Since we're dealing with linear CCDs, aside from some trivial settings I have arrays - arrays of about ~2000 doubles, and a max 3 arrays.  So I'd perhaps have 6000 elements in arrays running around. This probably is not ideal. 

I thought of a compromise, how about I use a shift register but wire it around my event structure, through a case structure breaking the wire only when I need to? i.e. see attached

---

While that would work I would still run the wire through. Running teh wire through is much more clear and less likely to result in a bug. Your solution it would be easy to forget to set the boolean to trigger an update. I eally don't understand your objection to running a wire through the event structure. I will allocate some space at either the top or the bottom of the case/event structure where all my pass through wires run. It doesn't take that much space and it is clear what is happening. I also have access to read or modify the data in any case.

[altenbach]

---

@pobrepablo1 wrote:

Still though, I object on principle to having a wire across every one of my diagrams, it's cluttersome .

...

I thought of a compromise, how about I use a shift register but wire it around my event structure, through a case structure breaking the wire only when I need to? i.e. see attached

---

So a single thin 1D object across all event cases is more cluttersome than an additional external 2D case structure, partially wired extra tunnels, and all the extra convoluted logic holding it all together? You priorities seem to be biased.

A nice wire across all cases is much better. It can be read and written in any event case that needs to, and can always be found in exactly the expected location. Remember that a shift register is very efficient. If the data size does not change, it operates fully in place for the duration of the run. It also often contains data that is not directly of interest to the operator so it does not need a display. A local variable requires a front panel object that needs to be updated in the UI thread. In needs a data copy in memory memory for the control/indicator itself as well as another copy for the transfer buffer (because the FP update is asynchronous). Then we have a third copy in the wire itself. Than makes it three copies of your potentially large array. Add another copy for each local variable instance, and you probably end up using 10x more memory compared to a simple shift register. It all adds up!

Local variables can be placed anywhere and keeping track of them is like herding cats. The next programmer to work on your project will have a hard time tracking them all down. In properly designed code, it is just "follow the wire". Much more clear and almost self documenting. 😄

[crossrulz]

I'm with the others, just wire it through the event structure.  Your work arounds is just making it worse.  Use the linked tunnels (actually introduced back in 8.6).  Those have saved me hours.  Also put a label on the wires so it is obvious what the data in the shift register is.

If it doesn't need to be seen by the user, then it should be in a shift register.

[billko]

---

@pobrepablo1 wrote:

<snip>

Still though, I object on principle to having a wire across every one of my diagrams, it's cluttersome .

<snip>

---

Never choose asthetics over functionality - especially since style consistency will make it possible for the two to co-exist in harmony.  If, for example, all your shift registers end up towards the top and the error cluster propagated on the bottom, it will make the whole event structure more pleasing to the eye, while making the data easily avaliable to any new events you might add later.

Combined with the advice to consolidate realated wires into clusters and you'd be surprised at how clean-looking your diagram ends up looking.  🙂