'CommonResults' conflict in TestStand 3.5

Question

I have 105 sequence files.  One main seq files calls other subseq files.  The structure is 4 level deep, if I not mistaken.  But every time I run the file, through 'Test UUTs', 'MainSequence', or 'SinglePass' entry point, I get the sequence editor dialog that said "Error loading step ... of sequence ... in file ...  Type 'CommonResults' is invalid because it conflicts with exisitng type of that name.  To avoid this error message, you should open the file with type conflict in the Sequence Editor and resave it.  Error accessing item 'Action.Result.common'. 
Error accessing item 'Action.Result'.
The sequence file ... could not be loaded.
Error code: -17329, Invalid type - conflicts with an exisitng type.
Source: 'TSAPI'"
I open and save all sequence files everytime.  Once I did that it work fine, but not all the time.  It shows the same problem as above more than working.  I have to re-save all files everytime.  Saving of conflicted seq files do not stay saved.
Several of us share the same TestStand on the very same Test Station.  But I am the only one with this problem, so far.  Other users without this problem has only one or very few (i.e. 4) sequence files.  But they have many sub-step groups within the sequence.
I have been working with NI's Application Engineer.  But the suggested solution does not resolve this problem, so far.
Do I exceed the maximum number of sequence files allowed or something else?  If yes, what is the maximum number of file?

Answer 1

CommonResults ships as version 3.1.0.100 by default (even in 3.5).  You are seeing the results of a Type Conflict that is happening when TestStand is trying to open an additional file that has a different type of the same name (either structure or version), and is unable to resolve the differences on its own.  Normally a mere version difference can be handled appropriately and you will not see any issues.  Since there are no "substantial" differences between your version and the CommonResults that ships by default, the best way to fix this is to try to replace the current version of CommonResults with the default version.  If you actually made changes, such as adding a property, you would want to follow a different procedure than the one I outline below.
The first part to clean up is the default files that are opened when you start the Sequence Editor.  Start the Sequence Editor and go to your Type Palette.  Find CommonResults in one of the files (such as NI_FlowControl.ini).  Change the version to 0.0.0.0.  Close TestStand and save all files that you are prompted to save.  Do not increment any of the types if it asks you to on save.  Start TestStand back up.  You will notice that your Type Palette Files are now loaded with the 3.1.0.100 version of CommonResults.  Close TestStand again and save the files.  This will ensure that you have a proper baseline when creating new files.
Now you need to clean up the offending files.  You will repeat the same procedure outlined above, with one exception - only save changes to the files that you want to clean up.  When you reopen the file, it will now be updated to 3.1.0.100 as well.
In case you did not clean up all files (or recieve a file from another user with a newer version of the type), you may open a file that has a newer version of a type.  Normally this is harmless.  However, DO NOT save your type palette files in this case.  You will notice that all of your type palette files will wish to be saved when you shut down the engine.  Unless you consciously made a change to a type, I would not recommend saving these files.  This usually indicates a modified type that is widely used, such as CommonResults.  This should be a cue to you to examine the file for modified types.
Generally, CommonResults is the most common type that gets a "modified" version.  I believe some of our Customer Education classes such as TestStand I & II have "modified" versions of types that may have originated from a Beta version of TestStand 3.5.  CommonResults is also special in a regard because it is a built-in Engine type- it is created every time the Engine starts up, without even using Type Palette Files.  If you have modified another type, resetting the version will not cause it to revert to a default value unless it is a built-in Engine type.
This should resolve most of your issues regarding the type conflict.  As an alternative to the "clean-up" type solution, if you open both the calling and the called sequence file at the same time, the Sequence Editor will force you to choose which type you want to use if there is a type conflict.  Then when you save the files, they will have the same type information and no longer cause a conflict when you attempt to have one call the other.
Allen P.
NI