Convert to enumeration

[Jarrod_S.]

The Typecast function is slow because it actually goes through the process of flattening the data to string and then unflattening it. Take a look at the help topic for it:

"Casts x to the data type, type, by flattening it and unflattening it using the new data type. If the function must reinterpret data instead of transforming it, LabVIEW uses a temporary buffer."

This makes it safe to use universally. You don't have to worry about crashing LabVIEW by casting different sized values or anything. However, it is slow as people have noticed. Look for alternative methods such as the int to enum function, or you could just write your own cast function in C and build a DLL. It wouldn't take long.

[Ben]

Thanks Jarrod,

When first released the SDE int to enum was "open" and it used the construct I illustrated.

What code construct can I use that achieve the same end but is more efficient?

Trying to learn,

Ben

[dwisti]

I though ;DNI_IntToEnum.vi used a bundle and unbundle, see attached pic:

Message Edited by dwisti on 10-15-2007 09:39 AM

[Jarrod_S.]

I did a quick experiment, and it seems that a quick easy way to convert an integral value into an enum is to build a subroutine subVI that simply passes an input integer into an output enum. When run in a for loop 1000000 times (making sure the end result wasn't constant folded out), the subVI took about 40ms while the Type Cast took about 1250ms.

Here's a copy of the example I used. It's not really meant to measure the absolute time these operations are taking, just to show a relative difference.

Message Edited by Jarrod S. on 10-15-2007 10:04 AM

[Ben]

Well that was a nice "Whack on the side of the head"!

No operators required, and just let coercion do it thing. I did a similar thing to convert DAQmx device spec to a string.

Thanks*!

Ben

* i won't tell Christian about this.

Message Edited by Ben on 10-15-2007 10:06 AM

[earlevel]

---

@jarrod S. wrote:
I did a quick experiment, and it seems that a quick easy way to convert an integral value into an enum is to build a subroutine subVI that simply passes an input integer into an output enum.

---

Jarrod--could you please post a picture of that? I'm using LV 8.2, and can't open your example. I'm not sure what you mean by "passing an input integer to an output enum"--it sounds like something I already tried, which does not work...

thanks

[tst]

---

earlevel wrote:

Jarrod--could you please post a picture of that? I'm using LV 8.2, and can't open your example. I'm not sure what you mean by "passing an input integer to an output enum"--it sounds like something I already tried, which does not work...

---

You should note that Jarrod also mentioned changing its priority to subroutine.

[earlevel]

Thanks tst--actually that's exactly what I tried (but in-place) the very first thing, but couldn't figure out how to make it an output and of course, the answer was to make it a separate vi (was so trivial, it seemed like I could do it without it being a subroutine/vi, but apparently not).

[earlevel]

---

@earlevel wrote:
Thanks tst--actually that's exactly what I tried (but in-place) the very first thing, but couldn't figure out how to make it an output and of course, the answer was to make it a separate vi (was so trivial, it seemed like I could do it without it being a subroutine/vi, but apparently not).

---

After I wrote that it occurred to me I could make it a control and add a local variable to read it--being fairly new to LV, I often find it awkward you can't both read and write a control directly (without using a local variable or other trick).

[tst]

---

earlevel wrote:

After I wrote that it occurred to me I could make it a control and add a local variable to read it

---

Yes, but you would have to make sure the local is read only after the control has been written to by forcing the execution flow using something like a sequence structure. This is both dangerous (creating potential for race conditions) and not very aesthetic (creating controls just to have variables), which is why local variables are usually adviced against. You should note that a control is not a variable and so a local isn't either. A local should usually be used only as a secondary access point for a control.

Obviously, there are cases where they are legitimage. You just need to know and understand what those cases are in order to use them safely.