Problems with multiple TestStand versions on the same computer

[jsiegel]

I installed LabVIEW 2014 and TestStand 2014; then later I installed TestStand 2010 SP1 and have been using it since.  (I also updated LabVIEW 2014 to 14.0f1; I think I did that after installing TestStand 2010 SP1.)  Is this "legal?"  I have been seeing strange behavior with TestStand 2010 SP1:

- if I type in any expression text boxes in the Sequence Editor (e.g., for a pre-expression), I periodically get an error dialog as I type:

 "The .NET support dll could not be loaded.  This is caused by an assembly path that could not be resolved.  Error Code: -18700, The .NET support dll could not be loaded.  This is caused by an assembly path that could not be resolved! Source: 'TSAPI'

After I acknowledging the dialog, I can contine to type a little more before getting the dialog again, but it doesn't seem to invalidate anything I type.

- If I open the Simple LabVIEW Simple User Interface that ships with TestStand 2014 while TestStand 2010 SP1 is active, LabVIEW immediately crashes.  I can open all the subVIs without a problem, but the top-level VI always crashes LabVIEW.

So I used the TestStand Version Switcher to make TestStand 2014 active, opened the top-level Simple UI VI, and deleted all the UI controls.  Then I switched back to TestStand 2010 SP1, and then I was able to open the top-level VI.  I added back the TestStand UI controls to the VI, and now the VI runs.  But many operations return a TestStand error dialog, such as Close Execution ("Value invalid or out of range [Error Code: -17300]"), Logout ("Cannot find item to select in ComboBox [Error Code: -2147467259]"), and (critically) Exit ("Operation Failed.  Error Code: -17500]") and the X in the upper right corner of the window ("Operation Failed.  Unknown System Error in <VI name>").  So I can't exit without killing LabVIEW.

These two issues may be unrelated.  But maybe installing an older version of TS after installing a newer version is not a valid use case?  Is the ActiveX error a result of this?  Should it be possible to use a (simple) UI written for a newer version of TestStand be able to work with an older version of TestStand?

I have another issue that is probably unrelated, but I'll bring it up here just for completeness.  If I right-click on a LV property node or invoke node for a property or method from the TS API and ask for help for the property or method, a command window flashes briefly before showing the TS help window with the top-level item selected (i.e., it doesn't take me to the help for the selected property or method).  I have this problem with either version of TS active, and I saw this problem even before I installed TS 2010 SP1.  I seem to recall having this problem once before, but I can't find the solution.  I don't know if this problem is an indication of some other larger problem.

For what it's worth, I am running WIndows 8.1 on a virtual machine.

[dug9000]

1) Installing TestStand 2010sp1 after installing TestStand 2014 should be ok as long as the OS you are using is one that they both support. See the following:

http://www.ni.com/teststand/product_lifecycle/

TestStand 2010 is not officially supported on Windows 8.1. That doesn't necessarily mean it won't work, just that it is not officially supported.

2) Using a TestStand 2014 User-Interface while a TestStand 2010sp1 engine is active is NOT supported. Using a older user interface with a newer teststand engine is supported, but not the other way around. If you want to create a UI that works with both TestStand 2010sp1 and TestStand 2014, you should base it off of the TestStand 2010sp1 user interface and modify it while TestStand 2010sp1 is active.

Hope this helps,

-Doug

[jsiegel]

Thanks for the information, Doug.  Maybe the ActiveX error dialog I get while in the sequence editor is related to the fact that I'm running an unsupported operating system.

So using a UI that was created in a newer version of TS is not supposed to be able to run with an older version of TS.  Is there any way to enforce this (like having a dialog appear informing you of the incompatibility when the TS engine is loaded) and avoid an immediate crash?  (Maybe the crash has to do with the incomaptible OS as well.)

Is there a way to "relink" a UI to an older version of TestStand?  Can you just relink all the ActiveX reference controls/constants to the TS ActiveX servers?  As far as I can tell, everything I am trying to do with the new TS version should work with the old version.  And also, as far as I can tell, the TS version switcher changes the version of the available ActiveX server; so unless my UI uses a feature unavailable in older TS versions, I would think it shouldn't know the difference.  (I'm making a lot of assumptions in that last statement, so I may be totally wrong here.)

Thanks,

Jeff

[dug9000]

I'm not a LabVIEW expert so I'm not sure how to get LabVIEW to refresh ActiveX nodes. Perhaps someone else can help you with that.

Did you get ActiveX errors in the sequence editor? I didn't see that in your previous post. ActiveX errors in the LabVIEW UI could very well be due to trying to use a UI from a newer version of TestStand with an older version of the engine. There might even be APIs used by the newer version of the UI that don't exist in the older version of TestStand. That's why it's best to start with a UI written for the oldest version of TestStand you would like to support.

-Doug

[jsiegel]

Yes, I do get ActiveX errors in the sequence editor (in TS 2010 SP1) when typing in an expression box, but I think that is a different issue from LV crashing when using an OI written for a newer version of TS.  The only explanations I can come up with are that TS 2010 SP1 does not play nice with Win 8.1, or maybe something about my TS 2010 SP1 installation is corrupt.

For the LV crashing issue, I simply tried opening the Simple OI (that ships with TS 2014) while TS 2010 SP1 was active.  As far as I can tell, that OI has some refactoring compared to the previous versions, but it looks like the exact same API calls are used in both (I may have missed something though).  In any case, I would hope that I would just get a runtime error or LabVIEW load error saying that my API is not compatible (or something like that) rather than getting a LV crash.

Jeff