LabVIEW VI's enum outputs in TS

[maksya]

I'm working with LabVIEW VIs in TestStand. TS processes correctly VI's inputs of enum type (showing pull-down menu), but it doesn't process enum outputs =( it provides only numeric component of enum to the output.

Could someone explain why is it so?

Regards,

Max

[Al.B]

Hi Max,

Since TestStand does not have an enum data type, it would have no way to store the VI output in enum form.  You could pass out the enum name as a string if you needed this value in addition to the number, or just typecast it to the enum in another VI if you are passing your data later in the sequence. Please give a bit more detail on what you are doing with the data once it is output from the VI, and I can look into other possibilities!

[maksya]

Al B, thank you for your answer. I want to use a string value of enum in the next step after the VI's call. Could you give more detailes about how to "pass out the enum name as a string". VI's enum output is proceeded in TestStand as a Numeric and if I bind a sting variable to this output I will get an error.

Regards,

Max

[JÞB]

Just use the above conversions!  

The Enum actions of the scan into string and scan from string are pretty powerful for this

[maksya]

Jeff, that's a good LabVIEW-oriented solution! Thank you. And what if we don't have the ability to modify VI's logic?

Let's assume that we have a set of VIs with enum outputs. And it is needed to use enum's string component in the TestStand sequence.

One TS-oriented solution is to define array of strings variable for every specific enum - index of such an array will be equal to enum's numeric component and value of array's element - enum's string component.

Is it the only way to get enum's strings from a VI call in TS? Or maybe it is possible to get it via properties?

Regards,

Max

[JÞB]

As previously posted, TestStand does not have a native "enum" type (In fact TestStand has no types since it is not a programming language at all, TS relies entirely on the types of the IDE's defined by the adaptors)

in LabVIEW rings and enums pass around as integer values but display as strings associated by the properties of the variable.  TS has no direct access to any variables property so, if you need to pass the property of a variable to TS you have to discover the property in the language used. 

in short the answer to your quesion  "And what if we don't have the ability to modify VI's logic?" is : Bummer dude!

[maksya]

Cool answer 😃 I'm not quite unable to modify VIs but I'm lazy enough to do it, because it is needed to update lot of VIs. Also it is more interesting to investigate the absence of enums in TS than to blindly update a hundred of VIs..

Nevertheless, lets assume that a VI have enum input and enum output. When we call it in the sequence, the step properties of both parameters have type Number. And TS parses string property of the input enum correctly - appropriate Value has a drop-down list. So, it is logical to suppose that TS has an access to enum's strings of input parameter.. Why do input and output parameters differ in this sense? To my mind, inputs and outputs should behave similarly with the only one exception - we can write data to the input and read from the output.

[JÞB]

Your forgetting a couple VERY important settable properties of a LabVIEW enum.  Like- Allow undefined values!  since the value of a type enum can be any integer and not all integers are represented by strings How could TS co-erce an enum output?  The IDE must contain the type definition.   To Duplicate the type in TS would risk having the two definitions become dissimilar and then the code will be buggy.

[LabBEAN]

---

Jeff Bohrer wrote:

Your forgetting a couple VERY important settable properties of a LabVIEW enum.  Like- Allow undefined values!

---

"Allow Undefined Values" only applies to rings (not enums) in LabVIEW.  There is one discrete value per item for the enum.

---

Jeff Bohrer wrote:

since the value of a type enum can be any integer and not all integers are represented by strings How could TS co-erce an enum output?

---

LabVIEW enum values always start at 0 for the first item and count up -- they can only be unsigned integers.  The only thing numerically configurable by the developer is the max number of items / memory used by selecting U8, U16, or U32.  The first string is item 0, the second string is item 1, and so on.

Enums are useful because the string is easily accessible (no need to inspect the control and index the corresponding string array to get the current string) and case structures switching on enums display intuitive names versus item numbers.  Rings are useful when you want to have custom values for the strings (e.g. item "350 MHz" corresponds with the value "350"), dynamically populate the items at run-time, or allow undefined values.