Changing Enum in a Labview Module

[paulmw]

I am having an issue with calling Labview modules that have an enum control.  When I specify the module the prototype gets loaded and a ring control is available in TestStand that matches the Labview control.  However, when I select a particlur value, TestStand modifies it to be some runtime variable.

I'll attach the an example VI that causes this but I have seen it in other VI's.  It seems to me that the name of the enum value is some sort of key word recoginize by TestStand.  Eitherway I would consider it a bug.

TS 4.0.1 LV 8.5

Message Edited by paulmw on 02-12-2008 12:08 PM

[Josh_W]

paulmw,

This problem was reported to R&D (# 4IBFKRAF) for further investigation. 

I did notice that if you choose "Set Only" the first time, it expands, and then if you choose it again, it stays as the correct value.  However, this only works for Set Only and Clear Only, not for Clear and Set.  During the process of narrowing down the problem I noticed that this problem seemed to only happen with Enum values that had spaces in them.  Perhaps for now a workaround would be to remove the spaces or use an _ (underscore) character.  R&D is currently investigating the cause of this issue.

Thanks for the feedback!

Message Edited by Josh W. on 02-12-2008 04:59 PM

[paulmw]

Josh,

Thanks for looking into this.  There are a couple of other places where I have noticed this.  The attached VI only has a enum control.  It shows the same problem with "Set Trend Event", "Set to Shipping Mode", "Upload Full Buffer No Data" and "Uplaod All & Flush No Data".  In the case for the last two it changes/adds RunState.SequenceFile.Data, so in this case the key word seems to be "data".

I also notice that for this example VI there are some "&" symbols and also numbers that get color coded while I am selecting enum values in teststand wich would indicate that it is attempting to parse it as an expression.

As you indicated, I do see that if you select it a second time with out clicking off to a new parameter it will set to the correct value.  I would also like to mention that if you manually enter in the numeric value for these problem enum values it will display the correct enum name.  This is how we have been working around it so far.  We have noticed that changing the name of the enum does/can fix it.

Thanks,

Paul

[paulmw]

I have noticed that in specifing the module for any VI you can type "set", "data", or even "result" and when you hit enter it will replace what you typed with these variables.

Message Edited by paulmw on 02-12-2008 06:02 PM

[paulmw]

Josh,

The work arounds are not working!  I have this VI and it bombs out every time I try to execute it from the sequence editor with the one control not set to default.  I have stripped every thing from the original VI except the enum control and TestStand can NOT call it.  This is seriously bad.

Please give this VI a try.  Just call it from an empty sequence as an action and uncheck the default value for the one control.  It doesn't matter what the value is, it will always error for me with error code -18002 and details "LabVIEW : parameter ReaderCmd not found in the VI's connector pane. "

[Josh_W]

paulmw,

I think I found the source of your error.  According to the following KB, leading or trailing spaces in LabVIEW 8.5 control labels cause problems when these VIs are called from TestStand.
KB 4F66LI0H:  'Parameter Not Found in Connector Pane' Error in TestStand After Upgrading to LabVIEW ...

I removed the trailing space from your control, and it solved the problem.
Also, this behavior has been remedied in the TestStand 4.1 beta.  You can sign up for the beta program at ni.com/beta

[paulmw]

Thanks Josh,

This does fix the problem of the above attached VI "Copy of tmiReader-Interface.vi ".

I would guess that this is not related to the Enum issue that originated this thread but just a coincidence that the particular VI has both issues (an Enum with "key word" lables and a control with a trailing space).

[paulmw]

I'd like to submit this VI with an array of enums that has actually crashed TestStand.  If you call the VI and un-check the default value, TestStand will populate an array with the default value from the control (this is good/ok).  Now, if you run the step and "step into" the VI all the values are wrong, they are all the same and corresponds to enum value zero.  Also, it has tendencies to generate memory errors and even crash TestStand.  The VI again has no executable code and only has one control that is an array of enums.  I have verified that the control does not have leading or trailing spaces.

Any ideas as to the cause?  Is this related to the single Enum issue above?

[Josh_W]

paulmw,

You've found another one!

This was reported to R&D (# 4IKCFSUZ) for further investigation.  The developer has already discovered the cause of the behavior.  When you uncheck the default checkbox, if you then expand the array, notice that the data types of the elements are set to (DBL).  But you are using an array of enums (U16), not an array of doubles!  To fix this, after removing the default checkbox, click Reload Prototype and it will update to the correct numeric type.

I'm sorry that you have run into so much trouble, but thank you for bringing these things to our attention so we can fix them.