LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to create a single VI accepting multiple input type defs?

Solved!
Go to solution

Dear users,

 

how can I simplify (or modify) the following code for better overview and maintenance:

 

snippet with all the def types.png

 

The structure on the top is a code manipulating my cluster (the uninteresting code is blocked). On the bottom, there are clusters of multiple type defs, which I use. So, I created multiple subVIs to accept my type defed clusters (all together 4 pieces). I bound all my subVIs into a single polymorphic VI and use it as wished. In all of my subVIs, I modify the items of the cluster in the same order.

 

But when changing the code in one of the subVIs, I have to change the code in the other subVIs, too. Is there any way to create a single VI that is going to accept multiple type defs clusters?

 

Thank you for listening!

 

Cheers,

0 Kudos
Message 1 of 10
(6,103 Views)

Another way to do it is to make the input a Variant. The entire thing could be handled within one subVI. The disadvantage is that outside the subVI, you must specify the type you are wiring, so that the subVI knows how to unpack the Variant. The way you have it, this is handled automatically by the polymorphic VI, as this is determined by the wire you connect to that input.

 

So outside the subVI, you have a Ring or Enum listing your data types, and this gets wired to a case structure with different code for each type.

Message 2 of 10
(6,085 Views)

You could also go with a LVOOP design using dynamic dispatch. The input would be a variant but processing would be the correct because the obkect type would determine the correct instance to use. You could use methods in the parent class to do the generic processing which would mean updates would only be required to be made in a single VI (method).



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 3 of 10
(6,073 Views)

@garrettmarsh wrote:

Another way to do it is to make the input a Variant. The entire thing could be handled within one subVI. The disadvantage is that outside the subVI, you must specify the type you are wiring, so that the subVI knows how to unpack the Variant.


Thank you, garrettmarsh, thank you, Mark_Yedinak. I dived into LVOOP (well, let's say, I made a few splashes), but I won't start to implement that way: It seems to be an overkill for my subtle issue.

 

But because the list of my type-defed clusters is limited, I came up with the following extendable solution using a variant:

snippet with variant (notes).png

So, I can correctly read any of my cluster type defs. The remaining unsolved thing is the output. The output could be only one of the available type defs (note the difference in the numbers within the icons). But so far, it seems that I have to choose the output upfront, instead of dynamically. Any thoughts here? Can be any output a variant, too? The idea is to maintain also the cluster format and its type definition.

0 Kudos
Message 4 of 10
(6,038 Views)

Hi ghighuphu,

 

I think the easiest and fastest way is using a variant for input and output.

 

 

Kind Regards,

 

Philipp

 

AE | NI Germany

0 Kudos
Message 5 of 10
(6,030 Views)

Just like an input an output must be of a single type. Your output can be a variant as well. However anything that will use that output will need to know which cluster that data is. Also, you can simply wire your cluster name to the case statement and use the names of the typedefs as the case selector. The FOR loop lookup is not required.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 6 of 10
(6,012 Views)
Solution
Accepted by ghighuphu

What I would do is go back to your polymorphic setup and turn any code that is common amonst the different polymorphic cases into a subVI.  Then you just have to edit the subVIs.


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
Message 7 of 10
(5,984 Views)
That is exactly, what I ended up doing today morning.
0 Kudos
Message 8 of 10
(5,980 Views)

These days you'd use a Malleable VI to achieve this.

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 9 of 10
(692 Views)

@littlesphaeroid wrote:

These days you'd use a Malleable VI to achieve this.


Old threads being resurrected...At least this is additive.

 

A malleable may do the job.  What I did with one of my setups was to make a polymorphic for each data type and then had a malleable VI that most of the polymorphic cases used.


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
0 Kudos
Message 10 of 10
(663 Views)