Available in LabVIEW 2017. Use Malleable VIs (.vim files) to define a generic implementation for a single subVI that will adapt to multiple wired input data types.
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.
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.
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 ;))
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.
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.
I just suggested something quite similar in this post (which obviously wil be marked a duplicate of this one):
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.