LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
DanyAllard

Provide a better way to implement a polymorphic VI

Status: Completed

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.

 PolymorphicVI.pngI 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.
LabVIEW ChampionArchitect
36 Comments
tst
Knight of NI Knight of NI
Knight of NI

> 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.

 

 

This already exists (since 8.5, if memory serves). Under the app control palette there's a memory management palette where a swap primitive exists. In versions earlier than 2010 (?) you can actually wire two different types into the node, but this doesn't actually work.


___________________
Try to take over the world!
tst
Knight of NI Knight of NI
Knight of NI

This discussion is also relevant to this idea - http://forums.ni.com/t5/LabVIEW-Developers-Feature/Now-available-for-download-quot-Randomize-1D-Arra...


___________________
Try to take over the world!
WG-
Member
Member

*kick* I was wondering... How is NI doing with generic datatypes / (C++ like) templates? Is it ever going to come to LabVIEW? A update would be nice. Since the "Randomize-1D-Array" was flawed, http://forums.ni.com/t5/LabVIEW-Developers-Feature/Now-available-for-download-quot-Randomize-1D-Arra...

AristosQueue (NI)
NI Employee (retired)

> How is NI doing with generic datatypes

 

We're a long way off. I've been avoiding a general update about the status to just let the issue lie -- I hate getting customers excited about something on the horizon and then disappointing them. But the long and short of it is the project is back to the drawing board and, honestly, a lot of the development effort has shifted to other projects that have a more clear path to completion and are at least as high in priority, if not higher. I was sort of hoping that someone would come up with a way to make the current solution viable so it could move forward quickly again, but that hasn't happened.

Jared7
Member

Any update on this feature? It would address my issue the best. My issue is described here: http://forums.ni.com/t5/LabVIEW/Generic-Queue/td-p/2526376/highlight/false. Consider my voice yet another enthusiastic one in support of this idea!

crossrulz
Knight of NI

Jared, if you like this idea then give it a kudos.  That is how your vote is counted for ideas in the Idea Exchange.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Jared7
Member

Kudos given! Thanks. I'm new to these forums.

InfiniteNothing
Active Participant

I wonder if we could accomplish something like this that uses a script to generate the "30+" VIs and stick them in a library so that we can use the current polymorphism

CLED (2016)
crossrulz
Knight of NI

I have a VI that does just that.  It is far from the best solution though.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
ToeCutter
Active Participant

Just adding my 2c in the form of a *bump*. I can't think of a single feature that would increase the power of LV more than this one.