shift Register vs local Variable

[WWolf78]

Hi Together,

I don't know if this is the right place, but one (maybe philosophical) question:

in one subVi of my program, I have several Cases for a specific proceeding:

in one Case I'm collecting data from an external device and store this in an double array

and in another Case I save this data in excel:

in all the other cases (!) I just have the lines for keeping the information

which is pretty awkward, as I have to place all the other stuff around this lines

for better readability and clear cases, which have only the relevant information I think about change all this to like to local variables:

good idea / bad Idea?

[GerdW]

Hi Wolf,

---

@WWolf78 wrote:

in all the other cases (!) I just have the lines for keeping the information

which is pretty awkward, as I have to place all the other stuff around this lines

for better readability and clear cases, which have only the relevant information I think about change all this to like to local variables:

good idea / bad Idea?

---

Definitely a very bad idea (IMHO)! (As I already told you here…)

Several comments.

• You can set tunnels to "linked tunnel", so LabVIEW will wire them automatically for new/all cases.
• You can bundle related stuff (like your several arrays) into a cluster to reduce the number of wires/shift registers. Use a typedefined cluster and (Un)BundleByName… (From here it's just one more step to using an OO class implementation.)
• "Better readability" means "follow the wire(s) as they hold the data", it does NOT mean "hide data access in hidden cases because of extensive usage of local variables"…

[WWolf78]

Hi GerdW

• You can set tunnels to "linked tunnel", so LabVIEW will wire them automatically for new/all cases.

I already do this, otherwise I'd went crazy connecting the bunch of lines...

• You can bundle related stuff (like your several arrays) into a cluster to reduce the number of wires/shift registers. Use a typedefined cluster and (Un)BundleByName…

I've done this for several other Informations as for the MHL and CL and another loop,

anyway this is additional work as to create the Cluster, name all the items, and create the respective bundle/unbundle operations

advantage is just one line walking through all cases

• "Better readability" means "follow the wire(s) as they hold the data", it does NOT mean "hide data access in hidden cases because of extensive usage of local variables"…

that's right.

It's anyhow laziness as I'd have to wire less items (and less distance),

BUT

if it is recommended / common practice (?) I'll do this

[GerdW]

Hi Wolf,

---

@WWolf78 wrote:

if it is recommended / common practice (?) I'll do this

---

Tell me any programming IDE/language where data copies and unrestricted data access via locals/globals is "recommended practice"…

(I'm not talking about using variables in text-based programming: in LabVIEW the wire is the variable!)

[WWolf78]

hm, got it
but when it's neither good practice nor recommended, why is it even possible?

resp, when should you use this?

[GerdW · Accepted solution]

Hi Wolf,

---

@WWolf78 wrote:

why is it even possible?

---

Because there might be reasons to use locals/globals in LabVIEW.

(You can also use global variables in most text-based languages…)

---

@WWolf78 wrote:

when should you use this?

---

You could use locals to write/initialize values in a control.

You could use globals in a WORM (write once, read many times) approach.

But keep in mind:

• Controls/indicators are used to present data to your user, they are not intended as "data buffer/storage". (In LabVIEW the wire is the variable!)
• Locals/globals come with the risk of race conditions…

[Yamaeda]

---

@WWolf78 wrote:

Hi GerdW

• You can bundle related stuff (like your several arrays) into a cluster to reduce the number of wires/shift registers. Use a typedefined cluster and (Un)BundleByName…

I've done this for several other Informations as for the MHL and CL and another loop,

anyway this is additional work as to create the Cluster, name all the items, and create the respective bundle/unbundle operations

advantage is just one line walking through all cases

---

If you have some sort of Init-case you can bundle everything without a type def. Just remember that the unnamed bundle requires wires to have a name for you to see them later on if you use Unbundle by name (Unbundle shows all, and you can't hide stuff)