Benchtop Measurement and Test
Distributed Measurement and Control
Systems Engineering Software
Perspectives showcases how NI sees what’s next in the world of test and technology.
You can request repair, RMA, schedule calibration, or get technical support. A valid service agreement may be required.
Provides support for NI data acquisition and signal conditioning devices.
Provides support for Ethernet, GPIB, serial, USB, and other types of instruments.
Provides support for NI GPIB controllers and NI embedded controllers with GPIB ports.
Not every bundle is linked to a Typedef. It would be very useful to automatically inherit the names of previously named wires into bundles.
Showing the Current and Proposed behavior for name inheritance in the bundle function
I think what you are proposing is more generally to be able to rename the data using the wire label.
While I think this is a good idea, I'm just exposing some particular cases.How would you name the elements in the following cases:
Wow, raphschru, thank you for those examples; they really highlight both the power and possible pitfalls. My opinion is the last label should take precedence (so "X", "Y", "Z", and ""This is just a comment" in your examples), but I could see how it might not be possible to implement changing labels on a single wire.
I'm not sure if this is a good idea, and if it is if it will even happen, but...
Iff this gets implemented, it should be considered for variants too:
If this is going to be the way objects get their wire label, I think at least it should be consistent.
LabVIEW Programming ((make LV more popular, read this)
Wire labels are not names, in my opinion. Comments should not change code. If you want to name the items, do it formally with a Coerce To Type node. Or, you know, make a constant and wire the middle terminal of the bundle... 😉
Though I wouldn't use the wire labels, as they are used as documentation, I would really like a way to change the name of a wire, so as to be able to define clusters like this.
@drjdpowell This is a primary use of the Coerce To Type node. It allows you to set the name of the downstream wire.
"Coerce To Type" coerces the type, hence the name. It changes name as well, but I usually don't want to coerce the type.
A change in name is a change in type. It is nonsensical to say that you want to rename the type without changing the type because the name is part of the type. You wire the identical data structure into the center as into the left but with a different name.
Imagine an output of a subVI that is a SGL named "Process Variable". You rename using Coerce to Type to be named "Temperature". Later, someone upgrades the subVI to use DBL, but no-one remembers to change the SGL constant. Now you are losing precision without realising it, coercing a DBL to single precision. A bug. At best, you'll waste time running through all your code hunting for coercion dots.
If that's an actual concern for you, there's a solution for it:
If anyone tries monkeying with the representation, the VI breaks.
[Ignore my comment about .vim... I forgot about the terminal names overriding on VIMs.]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What do you need our team of experts to assist you with?
We'll be in touch soon!