Reduce The Number Of Wires

[chrisml]

In LabView 7.1, what are the techniques for reducing the number of wires! I sometimes have too many.

For example, is there some function (etc) such as FROM and TO using a GOTO mechanism?

Thank you,

[Odd_Modem]

Many "from" "to" type schemes are subject to race conditions. This is because of the parallel execution model of the LabVIEW diagram, where the execution will attempt to evaluate all of the data sources that it can in one time slice. It might evaluate the 'to' data source before the 'from' data source has executed. I find the best way to reduce wires is to use a lot of sub-vis. Wires are good, I think.

[IEC]

You could always use some global variables  (uh oh, I said the G-word).  Just be mindful of the force, luke. (and by that I mean be mindful of the memory allocation and race conditions if you have many things writting to same globals)

[Chaos]

If the signals are related to each other you could combine them into a cluster.  Unbundle to modify or display seperately as required.

[jasonhill]

Take a careful look at what you want to do.  Can you use a for loop?  How about sub-vis?  The compound arithmatic element can eliminate a lot of addition / multiplication / boolean rail-yarding.  Most math functions can be applied directly to arrays instead of breaking them apart, performing math on each element, and then rebuilding.  Sometimes (if you are lucky) just rearanging the layout of elements can streamline the wires and make them look less messy.

[edit for stupid spelling mistakes]

Message Edited by jasonhill on 12-07-2005 01:33 PM

[Ben]

"...the number of wires! I sometimes have too many."

Please post an example showing too many wires.

Action engines are a great way of reducing the number of wires. They can be coded similar to file I/O function. Behinf the scenes there are lots of wires (data values) that ware required to support your file I/O. File Atribute Blocks, Record attribute blocks, etc (ther can be a hundred fields) but they are all associated with the File reference.

So for another twist on this subject I recomend looking at "action engines".

They store data that is related to a specific function in shift register of a single VI that can be invoked using a variety of "actions" (methods). This way the data used to perfom that function do not have to be moved around from one part of the code to another. They reside in a single location and accessed when required.

Ben

[chrisml]

Ben,

    I am just looking for general ways to unclutter things, thanks.

[IEC]

This question is somewhat related....

When you use a lot of wires, and have many wire connections going into and out of sub VIs doesn't labview start eating up all the system memory? Also, doesn't this lead to labview having to perform a lot more functions to move around this data?

What I'm getting at is this...  When developing a medium size application (that being one which communicates with ~10-20 instruments across gpib, rs232, parallel, usb, etc), what should be the "general" idea of efficient programming.  Should I use a mixture of global vars., sub VIs called normally, sub VIs called through VI server, etc. in order to limit the amount of wiring?  If someone could just maybe give a superbrief explanation and efficient programming practices or head me in the right direction that'd be cool.

jonathan

[jasonhill]

Its not so much the number of wires, as it is what is done with them.  When you are moving around a large amount of data, branched connections can eat your lunch.  Each branch creates a copy of the data.  NI has a really good article discussing the ins and outs of memory management: http://zone.ni.com/devzone/conceptd.nsf/webmain/732CEC772AA4FBE586256A37005541D3

I like to put most of the memory intensive operations in a sub-vi that contains a Request Deallocation.  I also put any functions that reduce the data set as early in the program as possible.

[DFGray]

Use of object-oriented programming techniques will greatly help medium sized program development (or almost any size, for that matter). If you are unfamiliar with object oriented techniques, try to break your problem into a set of objects - data/function sets which logically go together and interact with each other. For example, a graph would have X and Y axes objects, as well as a display object and perhaps a buffer object. I have attached an NI Week presentation which should serve as a simple introduction to the subject. It uses functional globals as the data repository.  The LabVIEW versions are 7.1 and 7.0.

If you want more information one the types of data repositories, check our the thread on Clusters as data structures. Several options are given, with benchmarks. I have switched to using queue based repositories for my current development.

Let us know if you need more info :).