Update Enumerator changes string values

[Michael_78]

Hi,

 I am having a problem with using a Labview Enum type def. within Teststand.  What I need to be able to do is insert values into the enum list to allow for future modifications to the tests.  The problem is that the value is fixed and not the string, so when I alter the enum, the string values are updated in the sequence.  Does anyone know how I can get TestStand to retain the string value and alter the numeric value when the prototype is updated?  As the reason for an enum is to specify a value by a string representation, I cannot think of a situation where the current behavior is desirable.

Thanks in advance,

Michael.

[Manooch_H]

Michael -

What version of TestStand are you using? This may be related to an issue in TestStand 4.1 and TestStand 4.1.1 that was fixed in TestStand 4.2.

Here are the details of the TestStand 4.2 bug fix list for the issue I'm thinking of:

Description:

LabVIEW Adapter might not remap an enumeration parameter properly if the enumeration element value changes in LabVIEW

Details:

If a LabVIEW Adapter step passes an element in an enumeration, removing an element from the enumeration in LabVIEW and reloading the prototype does not cause any visible change in the enumeration parameter in TestStand. TestStand displays the previous enumeration label, regardless of whether the label still exists, and passes the previous value for the enumeration.

Workaround:

After changing an enumeration of a LabVIEW step, reload the step prototype. You must then select another enumeration value before reverting to the desired value.

Hope this helps.

[SachaE]

Hi Michael,

  just to clarify one of your statements : "the reason for an enum is to specify a value by a strong representation" is not quite the full story. 

An enumerated type is by definiton a numerical value i.e. the data type is actually a number. The string is there to make things more readable (or as I saw on one website describing enums recently - they're half-baked and not real types and are there to save you on #defines in C).

Whilst in LabVIEW you can use things like format into string and scan from string to go between a string and an enum, fundamentally the data is a number.

If you insert into an enum a new "string" you're altering the string to number mappings.

In 'c' for example, you can declare an enum and leave space for additions later for backward compatibility.

enum e_tag{
      a, b, c, d=20, e, f, g=200, h
}var; 

So if we changed this to

enum e_tag{
      a, b, c, z, d=20, e, f, g=200, h
}var; 

a,b,c,d,e,f,g and h have all retained the same value as they had. since there was space between c and d numerically to do this.

changeing to  

enum e_tag{
      a, b, z, c, d=20, e, f, g=200, h
}var; 

leaves a,b,d,e,f,g and h alone, but c is now a different value to what it was before.

In LabVIEW however, the enums start at 0 and go up 1 at a time - no gaps.

So in TestStand's case, it is looking at a value of '4' which may relate to a string of "hi" and you want to insert above it "hello" to keep everything alphabetical. "hello" is now a '4' and "hi' has moved to '5'. TestStand has the value '4' still - so different text.

Depending on where you're implementing, for example instead of allowing the LabVIEW code to be used as a step code module, you create a step type and set this value through an edit substep instead, you retain control of the situation.

Hope that makes sense.

Thanks

Sacha Emery

(ATE Systems Engineer NIUK and Ireland)