Enumerated Out-Of-Range Detection

[Allen_W.]

I'd like to solicit opinions and ideas on a LabVIEW technical issue. The objective is to have a subvi detect when it receives an out of range value on an input that is an enumerated type control. Of course one way is to change the enumerated type so that the first and last items are named Underrange and Overrange, and handle these cases. But I am looking for a way to do it without adding items to the enumerated type. The attached LLB illustrates what I am trying to do. If the Numeric input on the top level VI is set to a value of 22, the subVI runs with a value of 16. Note that the subVI has a property for Out of Range Action that is set to Ignore, but the value is still coerced.

The LLB is in LabVIEW 7.1.  In LabVIEW 8.2 the behavior is different. There is apparently a bug in LabVIEW 8.2 that allows the Number of Items to change if an overrange value is input.

Allen

[smercurio_fc]

I did not see the bug that you're referring to, and I'm running LabVIEW 8.2. The "Number of Items" was always 17, regardless of the numeric input value.

With respect to the behavior that you're seeing when feeding in a value that "out of range" and saying it's being coerced and not being ignored, this is not unexpected behavior. In fact, if it wasn't doing it I would be surprised! I say this merely from the fundamental definition of what an enum is. It's not really a number. It may seem to take on numerical values, but it should be considered a separate datatype. An enum can only have a value from a pre-defined set, so by definition even if you feed in a value that is "out of range" of the enum, its eventual value can only come from the set of values defined for it.

What you're talking about is an artificial problem of converting a numerical value to an enumeration. How should this conversion behave? Well, that depends on whether you think this should be handled by the programmer, or by the language. It seems to me that LabVIEW is doing exactly what it should be doing. I believe it's up to the programmer to deal with a number->enum conversion properly. In my code I use an "UNDEFINED" or similar enum value to deal with the cases when I'm converting numbers to enums. This is typically when I'm reading values from an external file. In these cases an error gets generated so the problem can be corrected with the file rather than just letting the "automatic enum coercion" happen.

That's just my 2 cents.

[Allen_W.]

Thanks for the comments. What I am concerned with is validating the subVI as an independent module. A basic step in validation is to feed out of range inputs to the VI. Although the programmer using the subVI should perform the numeric to enum conversion properly, the subVI should handle out of range inputs in cases where the subVI is used improperly. I could used "Overrange" and "Underrange" items as I suggested or "Undefined" as you suggested, but I am exploring other possibilities and searching for a more elegant solution.

[smercurio_fc]

There is no built-in elegant method since the numeric->enum coercion is something that obviously happens automatically. If you provide a subVI that has an enum input you have no way of knowing that somebody wired an integer to that input unless you use the "Underrange" and "Overrange" enum values to deal with that situation. From your subVI's perspective all that you see in your subVI is the enum. There's no way for you to know that the enum value was chosen that way because somebody wired a constant of, say, -1 to your subVI's enum input. The programmer could just as well have had a number/string->enum conversion routine that actually chose those enum values.

The real question is whether or not you should be providing an "Underrange" or "Overrange" enum value. That depends on how your subVI gets used. Normally I don't create such values, and I would suspect most programmers also do not. The only time I do it is when I know the subVI is used in situations where the value would likely be coming from an integer or a string value like, when it gets read from a file. In the latter example I use a string->enum conversion VI, but I make sure that the enum has an "undefined" value in the case when I get an empty string or an incorrect string.

As a side note and follow-up to my previous message, it's interesting to note that even though the "Out of Range" action can be set for an enum via a property node, that section does not exist on the property page for the enum (and sensibly so). Perhaps that property shouldn't even be selectable for an enum.