Jump to content

Wire Labels wanted


Recommended Posts

Schematic capture programs have had wire labels for decades. Seems like an obvious thing for LV. I'd prefer color-coded like my example here. I have a VI full of these color-coded labels, and I use it to plop down labels, but this should be an easy thing to implement with a Right-Click, Show Wire Name.

I've found these labels particularly useful in state machines when the data is "just passin' through", or of course on long wires.

Richard

Link to comment

QUOTE(BrokenArrow @ Oct 27 2007, 07:11 PM)

Schematic capture programs have had wire labels for decades. Seems like an obvious thing for LV. I'd prefer color-coded like my example here. I have a VI full of these color-coded labels, and I use it to plop down labels, but this should be an easy thing to implement with a Right-Click, Show Wire Name.

I've found these labels particularly useful in state machines when the data is "just passin' through", or of course on long wires.

Richard

Not to nag you, but you know you can create a description for a wire, and see that in the Help window?

But your idea sounds good, and it shouldn't be too hard to code it.

Ton

Link to comment

A few additional relevant options for the present:

  1. Use a cluster for your state machine SR. This allows you to pass multiple values on a single wire and makes it easier if you need to add new states. Handling the value is simply a matter of unbundling and bundling by name.
  2. Use the label available in the system controls palette. Drop one on your FP and then drag it to the BD. It has the advantage of having its background adapt to whatever is under it, so you can place it on the wire itself and it looks nice.
  3. Create some merge VIs with the relevant labels. This will probably speed up your process somewhat.

Link to comment

QUOTE(tcplomp @ Oct 27 2007, 01:19 PM)

Right Ton, but it ain't the same. One, because you have to "hover over" the wire to see it. Plus, it doesn't have the intelligence to know that the entire wire node is the same name. For example, you can name pieces of the same wire (i.e data) different things, within different cases/sequences/loops. For that one reason, I've found that "describing" a wire is next to useless. My habit of using free labels is also problematic, because the labels aren't attached to the wires, and can get moved or lost. I spent most of the 90's doing schematic capture and PCB design, and got used to having wire labels (net labels) showing wherever I wanted them. Net Ports were also nice, but in LV, those are Local Variables ;):nono: RichardQUOTE(Yen @ Oct 27 2007, 02:20 PM)

A few additional relevant options for the present:
  1. Use a cluster for your state machine SR. This allows you to pass multiple values on a single wire and makes it easier if you need to add new states. Handling the value is simply a matter of unbundling and bundling by name.

  2. Use the label available in the system controls palette. Drop one on your FP and then drag it to the BD. It has the advantage of having its background adapt to whatever is under it, so you can place it on the wire itself and it looks nice.

  3. Create some
    with the relevant labels. This will probably speed up your process somewhat.

1. I beleive that if you have flat data, it should stay flat.

2. Neat, but as I said in my last entry, this type of label could "get lost" couldn't it? I'll try it.

3. Good idea. I've actually left my "WireLabels.vi", where I go to copy and paste labels, in the digram by accident!

Richard

p.s. Yen, I never knew the System Controls label was transparent by default -- that saves a step when you want a transparent label. Cool, thanks! :thumbup:

Link to comment

QUOTE(BrokenArrow @ Oct 27 2007, 08:29 PM)

1. I beleive that if you have flat data, it should stay flat.

Why? The cluster is simply the state machine data cluster. It holds all the data the SM needs to do its work. I consider that concept to be very simple and elegant and it has the added advantages of making your work easier, your code much cleaner and of satisfying your requirement. If you don't use the cluster in subVIs, you don't even have to make it a typedef.

QUOTE

2. Neat, but as I said in my last entry, this type of label could "get lost" couldn't it?

Yes, it could.

Link to comment

QUOTE(Yen @ Oct 27 2007, 02:36 PM)

Why? The cluster is simply the state machine data cluster. It holds all the data the SM needs to do its work. I consider that concept to be very simple and elegant and it has the added advantages of making your work easier, your code much cleaner and of satisfying your requirement. If you don't use the cluster in subVIs, you don't even have to make it a typedef.

Yes, it could.

Yen, Regarding the cluster vs. flat data, it's a bias on my part, having been told 6 or 7 years ago in some LabVIEW book somewhere to "keep data as flat as possible". Putting the data in a cluster has the advantage of just one wire "passin' through", which is an obvious advantage. When you unbundle it, there's your label. I probably should rethink some of my biases.

:DBut I still want me wire lables! :D

Link to comment

QUOTE(BrokenArrow @ Oct 27 2007, 08:46 PM)

I definitely agree.

QUOTE(tcplomp @ Oct 27 2007, 08:54 PM)

Create a Tool VI that: finds the center of the current selected wire, get the datatype, drop a system label with the correct make-up.

I don't know how practical that would be on a per-wire basis (invoking it might be too time consuming), but we could probably do it for all wires if we add a tag to each wire describing its name. Of course, that has a host of other issues.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.