Ability to set or reset the name associated with a wire (data path)

[WMassey]

As things work now, many wires (data paths) have a name associated with them. It may be derived from a control label or a constant label or a VI terminal. This is useful if a group of wires having unique names are wired to a bundle node** since it later allows the cluster data to be accessed using an unbundle-by-name node. If however, a wire does not have a name because it has passed through something like an Initialize Array node or if it has a duplicate name then this bundle to unbundle-by-name option will no longer work.

It would be very useful to be able to set (or reset) the name associated with a data path either by directly modifying the properties of the wire (right click option?) or by the insertion of a (tiny) naming node into the wire that would take a name as an argument and change the name of any type of data path that passed through it.

** While it would be possible to use a bundle-by-name node instead, that assumes that the cluster definition already exists. Creating (and later maintaining) the initial definition of the cluster can be, in some cases, more trouble than the job warrants (e.g. temporary data passing through a state machine).

[jpdrolet]

As things work now, many wires (data paths) have a name associated with them. It may be derived from a control label or a constant label or a VI terminal. This is useful if a group of wires having unique names are wired to a bundle node** since it later allows the cluster data to be accessed using an unbundle-by-name node. If however, a wire does not have a name because it has passed through something like an Initialize Array node or if it has a duplicate name then this bundle to unbundle-by-name option will no longer work.

It would be very useful to be able to set (or reset) the name associated with a data path either by directly modifying the properties of the wire (right click option?) or by the insertion of a (tiny) naming node into the wire that would take a name as an argument and change the name of any type of data path that passed through it.

** While it would be possible to use a bundle-by-name node instead, that assumes that the cluster definition already exists. Creating (and later maintaining) the initial definition of the cluster can be, in some cases, more trouble than the job warrants (e.g. temporary data passing through a state machine).

You can use the Type Cast node or the Variant to Data node. Wire your named wire on the type input and the misnamed data on the x/Variant input.

[WMassey]

You can use the Type Cast node or the Variant to Data node. Wire your named wire on the type input and the misnamed data on the x/Variant input.

Ah, but that assumes you have a named wire of the right type to use in the first place.

I realized that I missed this capability when I found that I needed (but didn't have) a named wire from the output of an Initialize Array node which had a fairly large typdef'd cluster wire/value as its input.

Yes, I could do what you suggest and make an array constant using the typdef, give it a name and use that, but then it would have been a rather large blemish on the block diagram just to get the name. I also know that it is possible to hide large block-diagram constants within tiny single-frame sequence structures but that is, in my opinion, ugly too. It too is possible to hide large block-diagram constants within a one-output subVI dedicated to just holding the constant (indicator) on its front panel, but that always struck me as something of a waste of a subVI call.

I just wish that there were a better way which is why I spoke out here.

[David Boyd]

Yes, I could do what you suggest and make an array constant using the typdef, give it a name and use that, but then it would have been a rather large blemish on the block diagram just to get the name. I also know that it is possible to hide large block-diagram constants within tiny single-frame sequence structures but that is, in my opinion, ugly too. It too is possible to hide large block-diagram constants within a one-output subVI dedicated to just holding the constant (indicator) on its front panel, but that always struck me as something of a waste of a subVI call.

I just wish that there were a better way which is why I spoke out here.

Another possible option (which I've only recently adopted) when I want a named, type-defined constant on the BD (frequently just to use as wire-typing source into a named bundler):

Don't use a constant at all. Drop a typedef'd control on the FP, set up its default value(s) (if they're needed). DON'T attach it to the conpane. Optionally, deselect 'Autoupdate from typedef' if you want to force the BD to be revisited/reinspected if the typedef changes. Context-click its terminal on the BD, choose 'hide control' and also 'view as icon'.

Pros of this approach:

Tidy on the BD.

'View as icon' makes it clear the source is type-defined.

Cons:

There is still a control, lurking invisibly, on the FP, that's not used to pass data into the VI. (Guess I'm paranoid - this still troubles me a bit.)

Or did I miss the point?

Dave

[Mule]

Cons:

There is still a control, lurking invisibly, on the FP, that's not used to pass data into the VI. (Guess I'm paranoid - this still troubles me a bit.)

If I may inquire - would are the risks/negative attributes of having such a "ghost". If it doesn't pass data in, and sits dormant, where is the problem?

Appologies if this is a silly/"newbie" question.

[WMassey]

Another possible option ... Drop a typedef'd control on the FP.

:

Or did I miss the point?

No you did not miss the point and I have also done what you have suggested at various times. I guess I'm like you in that having the control lurking there just to provide a typdef does bother my delicate sensibilities - it's not exactly a valid reason not to do it; I just wish there was some other option like the one I suggested previously.

And, FWIW, when I do something like this I now drop all the controls and indicators which I want to hide into a tab control which just has one page/tab and then hide the tab control. I label the tab control "Hidden controls & Indicators" and place the terminal in a prominent location on the block diagram. It makes it very easy to view/hide/find the hidden front-panel stuff.

[David Boyd]

If I may inquire - would are the risks/negative attributes of having such a "ghost". If it doesn't pass data in, and sits dormant, where is the problem?

Appologies if this is a silly/"newbie" question.

Mule,

There really are no risks or downsides in terms of performance, maintainability, etc. that I know - this one falls in the realm of style. There's been a suggestion from time to time of having a way to show a typedef'd constant on the BD in an iconic style, since large constant clusters tend to look messy on the BD, and when typedef changes propagate, any modifications the programmer might have made to the constant's appearance are lost and the constant reverts to a standard layout. Making the data source into a control and then hiding it cleans up the BD, but just 'feels' wrong stylistically, if only because controls are supposed to pass variable values into the dataflow.

Dave

[jpdrolet]

Ah, but that assumes you have a named wire of the right type to use in the first place.

[...]

I just wish that there were a better way which is why I spoke out here.

I can't imagine a most convenient way to rename a wire than to use a wire of the right type. Otherwise you'll have to enter names for every member of the structure and need something like a tree or tree menu to provide them.

I don't bother at all to use a typed control to provide type to a wire. I just add a comment "For type only" and the job is done.