Pass any Enum by Reference

[SJazzJAS]

Is there any way to pass the active value of an enumeration to a SubVI in such a way that it's value can be used by the SubVI, yet have the SubVI input not tied to that specific enumeration?  Here's an example scenario:

The first enumeration has 4 states, "low", "medium", "high", and "unknown".  The second enumeration has 5 states, "very slow", "slow", "fast", "very fast", and "unknown".

I need to have a SubVI which can take either of those two enumerations as an input and check if the state is "unknown".

Currently, the only way I can find to do this is to convert the enum to a string, pass the string into the SubVI, and then do a string comparison inside the SubVI.

Since this SubVI is going to be used in many different locations of my code, I would prefer to keep all of the enum-to-string steps inside the SubVI so I don't have to repeat the string conversion code every time I call the SubVI.

Does anyone know of how to accomplish this?

Thank you,

J

[billko]

Seems like an odd request.  What is this VI trying to do with such seemingly different data?

[Kyle97330]

Two options.

1. Use a polymorphic VI

2. Use a malleable VI

With the polymorphic VI, you'd create it, then choose 2 or more options for polymorphism.  In your case, you'd create 2 and have them have identical connection panes except for the enum input.  Each one then does "something" to translate their enum into something else, such as a floating point number representing an actual speed value plus a Boolean for "unknown" or not, then calls a 3rd VI that you make that does the actual work needed.  So in the end, you're making 4 files.

The malleable VI option is a bit newer (LabVIEW 2017 and newer only) and while you could do it with just one file, it has certain restrictions.  Most notably, it has to be renamed to a VIM extension instead of VI, and it has to be set to "Inline", so anything that can't be inlined won't work with it.  You'll use a type specialization structure to check which input type was wired in as an enum, then pass out a common variable type or types for the rest of the VIM to work with.

NI has a page here with some guidelines on which to use.

[billko]

---

@Kyle97330 wrote:

Two options.

1. Use a polymorphic VI

2. Use a malleable VI

With the polymorphic VI, you'd create it, then choose 2 or more options for polymorphism.  In your case, you'd create 2 and have them have identical connection panes except for the enum input.  Each one then does "something" to translate their enum into something else, such as a floating point number representing an actual speed value plus a Boolean for "unknown" or not, then calls a 3rd VI that you make that does the actual work needed.  So in the end, you're making 4 files.

The malleable VI option is a bit newer (LabVIEW 2017 and newer only) and while you could do it with just one file, it has certain restrictions.  Most notably, it has to be renamed to a VIM extension instead of VI, and it has to be set to "Inline", so anything that can't be inlined won't work with it.  You'll use a type specialization structure to check which input type was wired in as an enum, then pass out a common variable type or types for the rest of the VIM to work with.

NI has a page here with some guidelines on which to use.

---

I just thought that maybe if we could figure out why this VI needed to exist, we could figure out a better way to do this.  This seemed to me as odd as needing a poly VI to handle data from a DC Power supply and a Waveform generator.

[Darren]

I agree with Bill, I struggle to see how exactly this VI will be used in practice. Nevertheless, it's super-easy to accomplish with a Malleable VI, and no type specialization structure is even needed:

And here's the code that calls this Malleable VI:

[wiebe@CARYA · Accepted solution]

If unknown is always the last item in the enum, you can prevent to string conversion (which will be slow-ish, but that might be no problem at all):

I'd personally prefer to make 'unknown' the first item, because it's more consistent and even easier to check. This doesn't even require a .vim, ( or even a sub VI)...

Some consistency of order (always first or last) sounds like a good idea to me. Just comparing text is prone to typos, although it adds the flexibility to put 'unknown' somewhere in the middle.

[rolfk · Accepted solution]

I always tend to use the first enum value, with the index 0, which happens to be also the LabVIEW default default value, to indicate the canonical "unknown", "none", "bad" or whatever value for an enum. That way a simple equal 0 is all that is needed to detect this and no special VIM, poly or whatever VI is needed.

[paul_cardinale]

Try this.

[SJazzJAS]

Thanks for all the replies everyone!  I too wish I could explain more what my VIs need to accomplish, but it is difficult to go into detail due to the sensitive nature of my research/work.  Even the example I provided is abstracted quite a bit from what I'm really doing.

I believe I can go with the option of making all the enumerations have unknown be the first (or "0") value in the list, that way a simple comparison to 0 will suffice.  If not I will be looking into the malleable (or polymorphic) VIM options.

Thank you!

J