LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Automated creation of polymorphic VIs

Creating polymorphic VIs is extremely tedious work. Until the day such VIs are made obsolete (generic data type) it would be very nice if LabVIEW could automate parts of the job.

 

In many cases creating the different instances of a polymorph VI only involves changing the data type of one or multiple inputs and outputs of a VI. No changes in the underlying code (other than those who happen automatically already). For such cases it would be nice if LabVIEW offered an option to automatically generate the polymorph VI.

 

You would then just select the "template" VI, and for each of the input and outputs (listed in a table for example) you could then choose which data types the polymorph VI should support, and then click OK to generate the polymorph VI.

 

I'm sure we can create such a tool ourselves using VI Scripting, but it would be better to have it integrated into the shipping IDE.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
8 Comments
Active Participant

One of the reasons I usually don't bother creating a polymorphic. I only need the one data type now. Too much work to create a vi I *might* need later.

PaulG.

LabVIEW versions 5.0 - 2018

“All programmers are optimists”
― Frederick P. Brooks Jr.
Active Participant

I just found a similar idea here. The difference is that I'm proposing a "Polymorphism Wizard" that can be implemented without really changing anything else in LabVIEW, so less reasons not to implement itSmiley Happy

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Trusted Enthusiast
Trusted Enthusiast

You are referring to native data type. I can't see how this can be done in a foolproof manner with custom datatypes (or classes, although I am venturing in unknown territory for me here).

Active Participant

Native datatypes are simpler yes, but for custom datatypes the "Polymorphic Wizard" could accept paths to saved controls (type defs). Several people have made such tools for themselves already so it is definitely doable.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Active Participant

I'm not giving this a kudo because I'll settle for nothing less than real generics. Until then, Open-G's variant functions serve that purpose well enough.

Active Participant

Variants do not really fill the role of a polymorphic VI, that's why OpenG consists of  a huge amount of polymorhp instances.

 

Sure, we can all wish for a Carerra GT, but it's still nice to upgrade to a newer model of the old family car every once in a while 😉

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Member

I also would be happy with a possibility to use something equivalent to #include for the generic part of the several vis in a polymorphic vi. I do not mean a inline subvi because that also have strict definition of inputs and outputs and does not remove the problem. Copying the vi and only changing the input definition is a lot of work and in case of an error you have to fix the error in every vi of the polymorphic vi and is therefore error prone by the best. I would prefer the common part of a polymorphic vi on only one place.

Active Participant
What I think would be really cool is a special type of case selector for case structures: a "data-type case selector" if you will. The way I'm imagining it is that you wire up a variant input then your cases are the possible LabVIEW data types, so that the inside of the case selector is the variant data type-cast to the data type of the case. This way you just put your generic code in the case, sort of like an in-place element structure with to/from variant type casting input and output nodes.
____
Ryan R.
R&D