Provide a better way to implement a polymorphic VI

[DanyAllard]

Let’s take the Value Changed from OpenG, This polymorphic as 30+ VIs to support all data type and array size up to 2D. But basically it’s the same VI for all data type.

 I think it could be a “.vip” and when you define the connector pane you select constraint of the possible data type that can be accepted.

[Jim_Kring]

Hi Dany,

The feature that I think we want is a form of edit-time "type adaption".  We need some control/indicator type (called "adapt to type" or similar) that we can use instead of the variant that will propagate the specific type down into a subVI at edit-time.  I think that this is already on NI's radar, now we just have to raise our voices together and vote on it, here.

Cheers,

[gb119]

This should be possible already using XNodes, except that XNodes aren't released to the public - officially anyway ! They provide a way of doing edit-time polymorphism. The problem with an adapt type is that you have to have some way of constraining what types are allowed (e.g. numerics, just arrays, just arrays of numerics etc) and potentially altering the sub-vi code on that basis. Polymorphic vis do that by providing a separate vi for each possible input type, XNodes use scripting to programmatically construct the code to order.

[smercurio_fc]

I vote for this. I missed this the first time through, and this has been asked for so many times over the years.

[altenbach]

Note that the newest Mathscript already has a similar feature inplemented. (details).

[altenbach]

One possibility would be to be able to create a reentrant VI that would act exactly as if the code were flattened to the diagram, i.e. it would adapt to whatever is wired to it and propagate the type to the output. It would also follow the current coercion rules so mixed inputs are allowed and would create coercion dots. I would suggest black terminals and wires for this. Here's how the code of such a subVI could look like. (Sorry, the specific code is quite meaningless, so just look at the colors ;))

Message Edited by altenbach on 12-25-2009 11:12 AM

[altenbach]

Actually, my above code is a bit misleading, because the subVI does not need to know the difference between arrays and scalars. The code would work the same, even if all inputs are scalars (or all arrays or another mix, unless it would result in broken code if wired directly). If all inputs are scalars, the output would turn into a scalar too.

[WG-]

For this idea I would suggest also the following.

When creating this ".vip" file you should be able to (de)select the datatypes you want this VI to work for.

[JimboH]

I like this idea.  I wish more people would vote for it!

WouterG: I think this is how you would have to implement this type of code, otherwise the problem seems a bit too ambiguous and would require connection time checking (does the code work when the inputs are connected), versus checking during edits of the vip file.  

A few thoughts that are running through my head:

1) For most data types you could specify which built in operators are allowed, this would need to be done by NI.  Inclusion of an inappropriate operator could be marked with a big x, which upon inquiring (right click -> what's wrong?) could indicate which of your selected types are invalid with that connector.  For example, inclusion of a multiplication operator when strings are included would not be alright.

2) Inputs presumably don't need to be of the same type, which also causes confusion.  I think I would prefer some easy to edit gui that allows selection of the types of inputs in sets.  Specification of specific sets makes the editing easier to understand.  For example, in the case above you might have:

Input 1      Input 2     Input 3

sc. doub   sc. doub   sc. doub (sc. indicates scalar)

sc. doub   1d  doub   1d doub

sc. doub   1d  doub   2d doub  (INCOMPATIBLE)

As a bonus, once the code is corrected, you could auto generate a list of valid types given the code presented.

NOTE: The final case is invalid due to the dimensionality differences, which could be indicated in some way

3) Specification in this manner would allow for a mode in which you could observe the code as evaluated given an example input. Clicking on a row would generate the actual code, given the input types of that row, so you could see things like coercion and the resultant output type.

[SteenSchmidt]

I just suggested something quite similar in this post (which obviously wil be marked a duplicate of this one):

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-a-generic-or-adapt-to-datatype-control-indicator/i...

So I'll move my comment here:

I often make code that can handle many different types of input data - code that obtains queues, functional globals that just stores data and doesn't operate on it and so on. Usually I can get along by using poly-VIs, but many times I could save a tremendous amount of code if I had a generic-type control, or a control that adapted at edit-time to the wired data type. I could also much more easily re-use poly-VIs inside other poly-VIs (to obtain variability on more than one input, without making all permutations of instances).

Second best would be something like a generic cluster control/indicator, since I can't make a poly-VI that takes a cluster of a type I don't know when I make the poly-VI. And what would be the odds of me knowing the type of any cluster before someone using my toolset defined that cluster?

This code snippet could replace an entire poly-VI (I know this snippet does nothing that the ordinary Obtain Queue doesn't do, but imagine that it did):

I'd expect a broken arrow if a generic input wasn't wired, even if it is only recommended or optional - the compiler needs to know the data type to determine default values, available methods, to select other poly-VI instances down the wire etc.

Mind that what I'm suggesting isn't limited to poly-VIs, it's a generic control/indicator. Period.

Cheers,

Steen

[Ken_Brooks]

Here's one more voice in the enthusiastic support of this idea. I've been wanting it for over a year. My favorite example is an array manipulation VI that takes an array, a desired size, and expands or contracts the array to the specified size, using the first element (or type default if none) to fill newly created slots.

Note that this means that type adaptation needs some smarts to handle arrays. We need Adaptable Type and we also need Array [1D] of adaptable type and higher dimensions as well. I'm really just asking to be given, as a designer, access to the same kind of smarts that already exist in Index Array, Array Subset, Replace Array Subset, etc.

My other favorite example is a crossover switch: a VI that takes in two wires of the same type, and a Boolean, and puts out two wires of the same type. The outputs are copies of the inputs, either straight through or crossed, depending on the Boolean state.