Adaptable Terminal Type

[EMDI]

Hi guys,

I have seen VIs such as the "Unflatten from String" that take a "Type" input and can adapt their input/output value terminals to that type. Basically if you connect a string constant to the type terminal then the value terminal becomes a string, but if you connect an integer, then the value output is of type integer.

How do they do that?? I would like to do the same for some of my VIs.

Thanks.

[altenbach]

You can create a polymorphic VI.

Check the online help. (http://zone.ni.com/reference/en-XX/help/371361D-01/lvdialog/polymorphic_vi_dialog_box/)

[tst]

There are also XNodes, which do work like the primitives, but they are much more complicated and not supported by NI. You can find out more in the LAVA forums' XNodes forum, but I would also advise that you use a polymorphic VI if you really need this.

[Jarrod_S.]

The other way to do this in LabVIEW is with LabVIEW Classes and dynamic methods. Granted, this is a very limited option in the overall scope of LabVIEW, but I though it would be worth mentioning. Here's how it goes.

If you have a child that inherits from a parent, then that child can call all the parent's methods. The connector pane for the parent method will usually have a parent object input and output. All other things being equal, if you wired a child up to the parent object input, you should still have a parent object output as defined by the subVI, but LabVIEW is smart enough to propogate the child type directly to the output. So you don't have to downcast when calling parent methods. Pretty cool stuff.

If that doesn't make any sense to you, you might consider reading up on LVOOP for fun. I'm not claiming this technology solves the problem you mentioned, but it's worth noting. 🙂

[EMDI]

Thanks guys.

A quick follow up about polymorphic VIs: Is there a performance hit with using polymorphic VIs? For example, if a VI takes in an integer as an input, is there a performance difference if the VI is coded as a simple VI with an integer terminal versus the case where it is coded as a polymorphic VI?

Thanks again.

[Jarrod_S.]

Polymorphic VIs only have different Edit Mode behavior. During run-time (when they can no longer switch between instances), they are exactly like any other subVI.

[tst]

But there is a memory hit on having to load all the instances.

[smercurio_fc]

There's also the variant control.