Hello all:

I just have to vent, and I'm surprised that this topic has never been discussed. Allow me to start.

People recommend labelling wires. Various style guides trumpet the importance of labelled wires. You lose points on your CLD exam if you don't label wires.

We all agree that labelling wires is a huge step towards world peace and yet very few VIs I've seen (including NI's) actually do it.

WHY Because there is NO wire label !!!

At present a wire label is just a free label placed over the wire, so heaven help you if you have to shift, modify or expand your VI once you have labelled your wires.

You have two choices:

- Label wires as you develop. This is when you have the clearest idea of what the most informative name would be. Labelling at this point is also a big help in testing/debugging. Then, as your VI develops and changes size, or as you improve the aesthetics you can chase all your free labels that don't line up and put them back where you think they should go.

- Finish your VI, (knowing that you will never, ever have to modify it ) and then label wires where you have room, if you have room and if you can remember exactly what each wire does.

Mousing over with the wiring tool can get you a description, if you enter it. If the wire is connected to a control, you will even get the name of the data but that is usually self-evident anyway. It's the intermediate data that really needs labels, even if you chose not to have the labels visible due to space constraints.

There! I'm done now. My medicine is taking effect.

Barrie

So you can enter a description of the wire and you can triple click and get it's source and destination ... so do you need a label? I used to think so and used to paste the clear type text over my wires but over the years have let that go. You're right its a pain the &%&^%& to move them whenever you change the diagram and the new auto-wiring is sure to help ...NOT. But, I how many people show and label their FOR and WHILE loops? I would guess close to 0.01 %, as most people wouldn't even know that the labels are there!

Not to start a slanging match (I agree a nice flowing label such as you get with VISIO (or other such sw) connectors would be nice), but comments are WHY not WHAT and with an intrinsically visual medium such as LabVIEW I think a well placed comment will serve much better that labelling a wire, and for that purpose the desciption suits.

What would be a thing to wish for is having that description "visible" or not, at the flick of a preference switch. Now that is what I'd wish for!

cheers, Alex.

You've made some good points and there are a number of mechanisms already in LabVIEW (or almost there) that can be used to accomplish them.
As for for and while loop labels, I very often use labels, particularly if they are nested.

This brings up a pet peeve of mine. If you select the label to be visible on any structure, the label comes up with the less-than-useful information of 'For Loop" or "While Loop" and the label text is NOT highlighted to allow easy typeover, which is inconsistent with every other labelling function in LV. Sure, it's just an extra triple click away, but I already know it's a %*##* while loop! If I select the label as visible, chances are 100% that I want to change it to something more meaningful.


I agree on the issue of WHY vs. WHAT but I think both are needed.

-What
I still feel that intermediate data needs a label, or more accurately, a signal name. Often, a number of wires are bundled together to be output as a cluster from a SubVI or as an input to a SubVI. One can (and should) assign signal names on the indicator cluster but that is after the fact, WRT the diagram. Further, any cluster element created within the VI can not be accessed using the Unbundle by Name function, reducing the diagram's understandability (unless, of course, the element is created using a labelled constant). Luckily, only one instance of the data creation needs to be labelled, when the data is being created in a case structure. Using labels at the data creation point also gives the convenience of automatically creating consistent labelled indicators when "Create Indicator" is selected.

Backward inheritance of labels to unlabelled wires would be nice, but it would probably give the LabVIEW developers fits.

-Why
As I mentioned, there are (potentially) a number of ways to accomplish this. The description, or a tip strip can provide interactive information, but binding a visible label to a wire as part of the diagram is also important, so that the various signals can all be seen "at a glance". This is particularly necessary if the diagram is to be printed. I really like the idea of being able to switch descriptions/labels on and off easily.

All of this applies to other objects on the BD that don't presently support labels or tip strips, like shift register terminals. You can never have too much documentation. How many times have we written a VI, assuring ourselves that everything will be self explanatory when we look at it a year later, only to find our "very clever" VI to be obscure at the very least?

Of course, it's never happened to me, but I have heard about it.

As intuitive as graphical programming is, the myth that LabVIEW is self-documenting is just that.

Regards,

Barrie

This post has been edited by Barrie: Jun 11 2005, 09:56 PM

You're right, never noticed that ... how bizarre. It's like the labels on the LabVIEW functions themselves.



It is a myth that any language is self documenting. Even a text based language where MyFunctionDoesThis = AllTheInputs(AreLabelledThus) won't help after the core code has been dumped from your brain. I am eagerly awaiting my brain upgrade but I think that the hardware might not be able to handle the new software

cheers, Alex.

I have to second this, but what I really want is to be able to put a state diagram in the label which will pop up if you make the label visible and you hover over it with the mouse. We use CASE structures for state machines so often these days that having a simple 2D state-diagram (and/or) table graphic would go a long way to making them more readable.

This post has been edited by Michael Ashe: Jun 14 2005, 01:37 PM

My only issue with Wire labels would be, that it would place the labels in the worst place possible, the way auto-wire routing works. If they do it, you should be able to slide the label along the wire! Additionally, you should be able to click on a wire and have it inherit the label from the previous junction. If you put a wire description in outside of any structure, the wire on the inside of the structure does not maintain the description. FINE, but allow me to right click on the wire and inherit the description.
That would be my implementation. Plus color coordinate the label to match the wire!

This post has been edited by Pana-man: Oct 11 2005, 07:59 PM

The last time I remember being at an NI presentation here at LLNL the presentation team asked what new features we'd like to see in LabVIEW and wire labels was one I mentioned so perhaps if they hear it from enough places it may come to be.

One other labeling area that could stand some "fixing" is if you choose to show the label of a subVI you will find that it is the VI's filename and that there is no ability to modify the label to say anything else. I would like to be able to change the text to say or mean anything I choose to use.

I also use wire labels a lot on shift register wires, just to the left of the CASE in state machines.

I was writing a fairly long algorithm over the last couple days with a lot of intermediate signal wires, and I got really sick of moving my wire labels every time I rearranged some code. So I had a cheezy idea that I think could work as a pitifully simple wire label. This is too rudimentary to be usable, but perhaps one of the more experienced (that is, way smarter than me) people on these boards could take the idea and make something useful of it.

All I did was make the world's simplest express vi, gave it an In and Out control that was just a pass through, and made the configuration dialog change the title. Therefore this vi just stays attached to the wire, and if you move the wire the vi stays attached.

Andy

Now if you could move one wire and have the express VI and the other wire move too. Someday...

That's a really nice idea, but the problem is that every time you call a SubVI, it takes time. Imagine you have a FOR loop that runs a million times and you want it to go as fast as possible. Every wire will add about 8*10^-6sec (8 micro seconds is how long it takes to call a SubVI as far as I remember) to every loop. If you have an algorithm that should do fast calculations on buffered data and meanwhile go and acquire data (fast) into the buffer, every extra micro second affects the rate you can acquire the data. That at least is my experience with SubVIs. That's why NI always tell you to have the loops in the SubVI and not have a loop that has a SubVI in it

Amiram