Cleaning up VI's.

[Mike_505]

Hi, I'm relatively new and am learning through the school of hard knocks.... My background is using tools like Cadence for schematic capture and IC layout. There are a few things you can do in Cadence that I just can't seem to figure out how to do with Labview which I believe would make my VI's much cleaner and easier to follow once I figure out how to do them.

These are:

1. How do you resize and icon? I created an icon with 12 terminals. What a fugly mess once it's wired up. It would be nice if I could enlarge this and manually move the terminals to group them appropriately.

2. This is a corollary to my first question. How do you make virtual connection? IOW, if two signals are called the same thing they should be virtually connected. Therefore, there is no need to run a wire between them. In my current example, 11 of 12 inputs to the VI are top level controls the user of the VI will be selecting.

3. Or, what about making a bus? Then I could tie together similar wire types. In my current example, four of the twelve wires are GPIB addresses; data type wires. I could tie these together as a bus (e.g. GPIB(1-4)),  and make one terminal on the icon, and run them to where the user controls are and separate them back to their individual components there.

Thanks!

[Hooovahh · Accepted solution]

You my friend need to learn about clusters.  They aren't the magic solution to everything but it sounds like they could help.  Clusters allow you to group any set of data types into a single data type, that is carried along one wire.  And that means one terminal into and out of a subVI.  Updating type can be a problem  Say you have a VI that takes 4 GPIO inputs, then you add one, well now your types don't match, you might only be providing 4 but you need 5.  Here is where you would make a cluster a type def.  A type def links copies of the same control so that when one is updated, all copies are updated.

Oh and here are some links to free training.

NI Learning Center

NI Getting Started

-Hardware Basics

-LabVEW Basics

-DAQ Application Tutorials

3 Hour LabVIEW Introduction

6 Hour LabVIEW Introduction
Self Paced training for students
Self Paced training beginner to advanced, SSP Required
LabVIEW Wiki on Training

[Bob_Schor]

As Hooovaah mentioned, combining related wires into Clusters (and Arrays, as per your GPIB query) is a good way to reduce your wire count.  A useful "Style Rule" is to strive to have all of your VIs use the 4-2-2-4 Connector pattern (4 inputs on the left, a pair of connectors on top, four outputs on the right, a pair on the bottom), with Error In wired to the lower left and Error Out wired to the lower right.  Even if you have only a single Input and Output (e.g. the Error line), it keeps your VIs much neater and keeps the wires lined up between VIs.

Your question about a "Virtual Connection" brings to mind variables with "global" scope, callable from anywhere by their name.  In the case of LabVIEW, while it does have a Global Variable, having to use Wires is actually one of the most powerful (but subtle) aspects of the language, as it encourages parallel execution of routines while enforcing (because signals have to travel through the wires) the proper "pre-condition" and "post-condition" needed to make sure your code, embedded in the VI, does "what you want" instead of "what you said".

Bob Schor

[drjdpowell]

With the caveat that that if you find you need this more than very rarely then you are doing something wrong, you can right-click on any subVI and unselect "View as Icon".  This will switch the subVI node to an ExpressVI-like depiction, which you can expand to show inputs and outputs by name.  

[Yamaeda]

---

Mike_505 wrote:

1. How do you resize and icon? I created an icon with 12 terminals. What a fugly mess once it's wired up. It would be nice if I could enlarge this and manually move the terminals to group them appropriately.

2. This is a corollary to my first question. How do you make virtual connection? IOW, if two signals are called the same thing they should be virtually connected. Therefore, there is no need to run a wire between them. In my current example, 11 of 12 inputs to the VI are top level controls the user of the VI will be selecting.

3. Or, what about making a bus? Then I could tie together similar wire types. In my current example, four of the twelve wires are GPIB addresses; data type wires. I could tie these together as a bus (e.g. GPIB(1-4)),  and make one terminal on the icon, and run them to where the user controls are and separate them back to their individual components there. 

---

1. View as icon is the closest you'll get as mentioned, though in general it's a signal of design problems.

2. Array of control references, 1 input needed. 🙂 (or a cluster if you want/need the predefined names, e.g.)

3. Cluster, as mentioned, or an array of addresses and a number/index input

In general i'd say LV is pretty much based on arrays, many functions handle them natively and they scale automatically as the program grows. It's common to combine the two and use arrays of clusters. E.g. if you make a cluster of serial/tcp-ip settings to an instrument you can place it in an array and have as many instruments as you need handled.

/Y

[Mike_505]

Thanks to everyone for the comments. Clusters will definately help clean things up a bit 

I have one more question, and it's probably right under my nose, but how I do a flip around a function. I inserted the "unbundle by name" function and the input is on the left and the outputs on the right. I really need it to be flipped so the input is on the right and the outputs are on the left.

Thanks

[Dennis_Knutson]

No, you can't flip a function. The convention is for wires to run from left to right so your request is backwards from the accepted style.

[Hooovahh]

---

@Mike_505 wrote:

I have one more question, and it's probably right under my nose, but how I do a flip around a function. I inserted the "unbundle by name" function and the input is on the left and the outputs on the right. I really need it to be flipped so the input is on the right and the outputs are on the left.

---

I'm trying to think of a more important rule to live by when programming in LabVIEW and few come to mind.  Inputs on the left, outputs on the right.  There are quite a few hits on Google for this by the way.  I think this was a question on the first LabVIEW quiz I gave to students too.

[Mike_505]

Thanks again, I figured it out. It was an error on my part....trying to use the tutorial and apply it to my design at the same time. Should have let it sink it a bit. Sorry for any inconvenience.

Thanks for the input!

[Hooovahh]

---

@Mike_505 wrote:

Thanks again, I figured it out. It was an error on my part....trying to use the tutorial and apply it to my design at the same time. Should have let it sink it a bit. Sorry for any inconvenience.

---

No problem.  It is probably a good idea to do as you said, take a tutorial or two, then take a break from coding and just think about how what you learned could be applied to other problems.  I paste those links all the time, but if someone where to just go through them all, and then start a project, I feel like maybe they wouldn't be as well prepared as someone who took some time to understand the steps they performed.

I remember when I took Basics 1 and 2 (Core 1 and 2) and it was from a book.  I had just got hired on to a company and I knew nothing about NI or LabVIEW.  They gave me a book, and a copy of LabVIEW and said go through it.  Over the next couple days I followed the instructions and went through the book.  By the end I had a neat little program that simulated lighting control in an auditorium.  But I still struggled with knowing things like when to use the index function out of a for loop.  What I really needed was some time to digest it, and then experience it on my own on a real program.