As Doug mentioned previously, the behavior experienced and mentioned above is a result of the XML and Binary file format conversion code being skipped for step instances whose modules are exactly the same as the module specified for their respective step types. We have found that this issue affects the .NET and Sequence Call Adapters. In the case of the Sequence Call Adapter, if you have a sequence call step whose module exactly matches the module specified for its step type, you will encounter an error provider at edit-time if any of the parameters of the sequence call step are of type Number or Array of Number (this does not include Numbers or Arrays of Numbers that are nested within containers). If you click the error provider to reload the prototype, you will lose the value expression for parameters of that type.
Doug's previously mentioned workarounds are both valid and recommended for these two issues so I will restate them:
Recommended methods to workaround this issue
1) Save your files in the INI format in 4.2.1 before opening them in
TestStand 2010. Once you have opened them in TestStand 2010 you can
change them back to binary and resave them since the conversion has now
already been done.
Or:
2) Another alternative is to make a trivial change to the .NET
modules in your step types so that there are no steps that have exactly
the same module settings as their step types. One such trivial change
you can make that does not affect how anything executes is to modify
the value of the TS.SData.ModuleSrcPath property of your step types
(You will need to turn on the "show hidden properties" setting in the
station options to see and edit this property on your step types). This
property is only used for the create and edit code feature of code
modules and does not affect how anything executes. Also, once you have
resaved all of your files in TestStand 2010 you can change this back to
whatever it was before. NOTE: You only have to change the step types,
not the steps, so this workaround might be easier if you have lots of
files since you can just put the modified step types in a type palette,
then opening any of your existing files should then work.
We are sorry for any inconvenience this has caused or may cause in the future.
If you are in a situation where you have already upgraded your sequence files to TestStand 2010, saved over the original version, and have absolutely no backups of your sequence file, you can use the tool attached to this post as a last resort for recovering any affected steps.
Last Resort
Again, please note that the attached tool is not a recommended workaround. It is only being provided as a last resort to aide users who have found themselves in the unfortunate situation where they only have one copy of their sequence file and that copy has been affected by this bug and saved to disk.
To use this tool, extract the zipped files to <TestStand Public>\Components\Tools\TS 2010 Upgrade Bug Tool\. Create a custom Tools menu item that calls a sequence, point to the MainSequence of TS2010_Step_Fixer.seq, and name the tool something meaningful to you. You can run the tool on an already open sequence file or you can run the tool on all sequence files located in a directory (and its subdirectories). The tool will prompt you before updating or saving any files to disk.
Please let us know if you have any questions.
Manooch H.
National Instruments
