Switching from TS3.1 to 3.0

[Rafi2003]

HI,

We have, in our department installations of TS3.0 and 3.1. I developed a project on a system with TS3.1 and now wish to transfer it to a PC with an installation of TS3.0. I copied some files from the Cfg directory of the TS3.1 PC to the one with the TS3.0.

TestExec.ini - causes the TS in the 3.0 PC not to boot up at all. (so, I copied back the TestExec.ini from another PC with TS3.0)

StationGlobals.ini - TS3.0 will not read this file if saved with TS3.1

Is there a simple solution to this problem? I want to be able to , automatically, load any project on any PC regardless of the TS version installed.

Thanks
Rafi

[Scott_Richardson]

Rafi -
Even if the file format of TestStand 3.0 is identical to TestStand 3.1, we specifically prevent it from reading files from newer versions. This is because of problems that can occur with types, where types from a newer version can propagate to an earlier version and cause type conflicts. So files that are contain types are sequence files, type palette files and configuration files. In general the recommendation is when you want to share TestStand files between versions, you should only develop using the older version. Clearly modules like VI, DLL, COM, etc are developed independently of TestStand so these should not present a problem unless they access properties or API in the newer version that do not exist in the older.

[Rafi2003]

Thanks Scott,

Am I safe if I save the seq files in a separate folder and select SaveAs 3.0 type?
What I did with the *.ini files is save them in a separate folder and modify 3.1 to 3.0 inside them. Same thing for SequenceModel and Types.

I can use your advise in the future to develop with the older version but right now, I must load my project on the 3.0 system. Is there any other way to do it?

Thanks
Rafi,

[Scott_Richardson]

Rafi -

The SaveAs dialog does allow you to select a file format for an older version of TestStand.  It main purpose was for user who incorrectly saved a file in a newer format and should not have.  It is not intended as a tool to commonly use to share sequences built in different versions.  In general we recommend sticking with a single version of TestStand when developing code for a project. 

For NI types, TestStand will attempt to fix up any file format changes between the two versions.  In addition it will replace any new versions of NI types with older versions of those types by using a set of compatibility type palette files that it maintains. However if user types have been edited or changed explicitly or implicitly by TestStand, it is possible for those type changes to propagate back to the earlier version of TestStand and cause type conflicts. Types do have the "Set Earliest TestStand Version that can Use this Type" setting to instruct earlier versions of TestStand to ignore them, but if this is not used you may get a type conflict.  If you get a type conflict and you do not now why, it is recommended to use the existing type in the earlier version and discard the type from the newer version.

For INI files, I do not recommend trying to use them in the older version because they also contain types and these could cause type conflicts or error as you previously noted.