Surprise! A property node can accept a variant wire on refnum input

[littlesphaeroid]

I am working through an elaborate exercise in obtaining all settable properties for all LabVIEW classes. This requires ninja scripting skills, but I'm a wee Grasshopper.

Observe this curious diagram:

 

At the top we have a property node that gives a Label Reference, and this feeds into a second property node which is of type Text.

At the bottom the variant Value property also produces a non-broken wire, and this is seen by LabVIEW as the class type Instr. 

The Get Type Information.vi primitive returns the data type of the Value terminal as Refnum, so at least that's consistent.

The fact the the value for this class is indeed a refnum explains what's going on, but I am surprised that the variant doesn't need to be cast to the refnum type before being wired to the property node. The workaround to determining if the second property node in the chain should be read for its class type eludes me. However, since this is the only case where this occurs, I do have a workaround.

[tst · Accepted solution]

The answer is actually simple and LV actually told it to you - the wire is not actually a variant.

While the value property does return a variant if the class the node works on is not strictly typed (which happens a lot) and the wire is purple, it isn't a variant in this case. It's the Instr class, which is also purple (which you can see by dropping controls of this type, which include not only VISA, but also DAQmx, FieldPoint, IVI and others). The class also works with property nodes, which is why this works.

You could also see this if you use the context help button on the wire, which will show you its type.

[littlesphaeroid]

Thank you. The wire type is actually "refnum" when I test it, but looks like a variant which most non-strictly typed value properties are. Definitely tricky!!

[rolfk]

---

@littlesphaeroid wrote:

Thank you. The wire type is actually "refnum" when I test it, but looks like a variant which most non-strictly typed value properties are. Definitely tricky!!

---

It's specifically a VISA refnum, more gernerically a named refnum. Named refnums contain internally both a MagicCookie (a 32-bit identifier) and a String. If the MagicCookie is invalid, the VISA functions (or DAQmx, or IMAQdx or similar) try to resolve the String to a valid resource and implicitly create a MagicCookie refnum to be used in consequent calls that receive that refnum. Named Refnums also implicitly cast from a String.

All other refnums in LabVIEW use only a MagicCookie and have an explicit Open, Create or similar function that converts a specification of the resource into that refnum. VISA also has a VISA Open function but that has been mostly optional since the named refnums have been introduced. It doesn't hurt to do an explicit VISA Open, but it is not really necessary as the first function that receives that VISA resource identifier will implicitly call the underlaying viOpen() API call in VISA if there is no valid MagicCookie in the resource identifier.

Most refnums in LabVIEW (exceptions are the refnums that existed already before LabVIEW 7.0 or so, like network and file IO refnums) support the object manager interface that allows to connect property and method nodes to them and in that way call methods and acces properties of that resource. Theoretically all the VISA nodes for instance could be method calls instead, but for backwards compatibility the VISA nodes remain as they already existed from a very early stage.