Automatic conversion of enum to string

[viSci]

I was wondering why LabVIEW does not automatically convert enum's to strings on subvi inputs. The information is available on the wire so why not just offer this as a convenience instead of having

to send it in as a variant and doing the conversion manually inside the subvi. I think it would promote the idea of using typedef'd enum's as diagram tags instead of having to use strings which cannot be

're-applied' when the typedef changes.

[jdunham]

I'm not understanding why you don't use the typedef enum in the SubVI as well. Why pass the value as a string? The more strong typing you have in your code the fewer bugs. Other than that it seems like a harmless idea.

It's sort of like how you can wire any kind of data into a variant. It's pretty handy, but it can also lead to bugs. I would prefer to be forced to use the "To Variant" function so that my own worst enemy (me) would have a harder time making wiring mistakes which don't break the wires.

I also don't understand why NI doesn't use any typedef enums with it's property nodes, like enabled/disabled/grayed-out. At the very least that property node ("Disabled") could create a ring when you pop up on it, instead of just an integer.

I assume you already know that the Format Into String function is an easy way to get the enum's current string value, though it would be nicer to for enums to have their own special conversion function.

Scan From String does a pretty good job in the other direction too.

[viSci]

I should have explained my application...

I would like to create a generic CVT (Current Value Table) for cRIO applications. Instead of strings, I would like to use typedef'd enums

as the tag key on my diagram. The generic interface for a CVT read or write would have a variant input for the enum key and a DBL,STR, or BOOL

as the data input. I need to convert the enum to a string and use it as the key of a variant attribute which is used to strore all the CVT data. I thought

it would be nice if the enum could be automatically converted to a string at the vi interface (I am sure NI could do it more efficiently than I can).

I am currently preprocessing the enum typedef to extract all the strings and then use the enum cast to a I32 to index

out the string. Overall, on the cRIO, it turns out that working with variant attributes is quite costly in performance so I may have to rethink the whole approach.

[Aristos Queue]

In general, LV avoids type coercions. We do allow many numeric type coercions, but there's a lot of folks that wish we didn't do those automatically. In general, the more automatic type coercions that you allow, the more accidental miswirings are possible. Allowing enum wires to attach to string terminals would be a severe break with the strict type system of LabVIEW. Given a) how rare this behavior is desired and b) how easy it is (see previous comment from jdunham) to get the conversion when you want it, there's no way that we'd put such a conversion into LV.

The coercion dots are a constant balance of ease of programming vs correctness of programming. I don't think this conversion is one that would serve that balance.

[viSci]

Ok, the problem with 'scan from string' is that it cannot be used when trying to transfer an enum into a subvi. The only way to do that is with a variant. So how about adding some goodies to the scan function to scan a variant and we could have it do all sorts of cool lvdata parsing including obtaining the enum string.

[jdunham]

QUOTE (sachsm @ Aug 7 2008, 05:56 PM)

Ok, the problem with 'scan from string' is that it cannot be used when trying to transfer an enum into a subvi. The only way to do that is with a variant. So how about adding some goodies to the scan function to scan a variant and we could have it do all sorts of cool lvdata parsing including obtaining the enum string.

That's already available in the OpenG lvdata package. The VI is called Get Strings from Enum__ogtk.vi. It takes a variant as input and gives you both the list of strings, and the current value's string.

[JDave]

QUOTE (sachsm @ Aug 7 2008, 04:56 PM)

Ok, the problem with 'scan from string' is that it cannot be used when trying to transfer an enum into a subvi. The only way to do that is with a variant. So how about adding some goodies to the scan function to scan a variant and we could have it do all sorts of cool lvdata parsing including obtaining the enum string.

When I have needed this, I just convert to string before passing to subVI. You can make a smaller-sized subVI wrapper around the Scan From String if you need to conserve block diagram real estate.

I made a request for exactly this a while back, but I have come to agree with Aristos. I just would prefer a smaller sized icon, similar to those for converting between numeric types.

[viSci]

The problem with Get Strings from Enum__ogtk.vi is that it is way too slow to be used in a CVT implementation on an embedded target.

I agree that a smaller version of the format into string would be nice and could be called enum->string.

[Clio75]

QUOTE (sachsm @ Dec 12 2008, 07:20 PM)

The problem with Get Strings from Enum__ogtk.vi is that it is way too slow to be used in a CVT implementation on an embedded target.

I agree that a smaller version of the format into string would be nice and could be called enum->string.

I do the property node, Like the picture attached.

http://lavag.org/old_files/monthly_12_2008/post-10422-1229193355.jpg' target="_blank">

[LAVA 1.0 Content]

QUOTE (sachsm @ Dec 12 2008, 06:20 PM)

The problem with Get Strings from Enum__ogtk.vi is that it is way too slow to be used in a CVT implementation on an embedded target.

I agree that a smaller version of the format into string would be nice and could be called enum->string.

Here's a version based on the info in LabVIEW on the typedescriptors for LabVIEW 8.x, if it is way faster let me know (I have a feeling it should be faster).

EDIT: Done some benchmarking and looking into the OpenG code, the code functions the same.

The benchmarking shows that in multiple runs (>5000) OpenG is faster, my code is faster approximatly at 1000 samples. On smaller sample size the difference aren't statistically reliable, maybe you can tweak it for your embedded system.

EDITEDIT:

First tweak, removing the 'Split Array' and using a start offset of 6 makes my version approx. 30% faster than OpenG (with less functionality)

Second tweak, setting to I32 after the index array tops off another 10 %.

Tweakead:

QUOTE (Clio75 @ Dec 13 2008, 07:37 PM)

I do the property node, Like the picture attached.

But that requires scripting and you will need a control.

Ton