LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Avoid wires

I would like to add to the very good suggestions already made above by others.

  1. Clusters! Do not forget, you can bundle up wires into clusters. Imagine you have several values which correspond to a logical group lets say. You can create a type defined cluster, and you already reduced the N number of wires into 1!
  2. Read this page too: http://www.ni.com/newsletter/51735/en/

edit: i mentioned clusters just as a general info how to avoid "too many wires going around", they are not necessarily needed in your current project (arrays what you need here i guess only).

0 Kudos
Message 11 of 16
(1,205 Views)

I'll be the Devil's advocate on this and say that if you absolutely want to avoid wires you can look at Action Engines (AE) and/or Functional Globals (FGV) and/or Global variables. You'll most probably run into Race conditions as mentioned earlier, but it'll be less wires on the diagram and it'll probably bite you in the butt later, but hey, it's less wires.

One cute effect is that if you bundle an AE in separate Read and Write VI's you can even have it like the black dot. You'll need one such group of 3 VI's (AE, Reader, Write) per wire though.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 12 of 16
(1,187 Views)

@Yamaeda wrote:

I'll be the Devil's advocate on this and say that if you absolutely want to avoid wires you can look at Action Engines (AE) and/or Functional Globals (FGV) and/or Global variables. You'll most probably run into Race conditions as mentioned earlier, but it'll be less wires on the diagram and it'll probably bite you in the butt later, but hey, it's less wires.


Now I feel I must supply a link or two...

A Look At Race Conditions

Are Global Variables Truely Evil?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 13 of 16
(1,185 Views)

Good idea @crossrulz. There are way to use and abuse all functions, but as i interpreted OP, globals and similar will cause more problems than they'll solve (currently).

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 14 of 16
(1,178 Views)

@Blokk , Thank you very much for the link, now i really understand the importance not to use local variables everywhere!  Could you please take a look at the file attached to show me how to accomplish not to use local variables that way.

Thanks again.

0 Kudos
Message 15 of 16
(1,161 Views)

@MaxiBarac wrote:

@Blokk , Thank you very much for the link, now i really understand the importance not to use local variables everywhere!  Could you please take a look at the file attached to show me how to accomplish not to use local variables that way.

Thanks again.


You example is too simple and anything we show you will be more complicated than using a local.

 

But how about this? 😛

vrt.png

 

 

If you are worried about a "messy" block diagram think about using sub-vi's and clusters, NOT local variables or Property Nodes.

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 16 of 16
(1,138 Views)