'CommonResults' conflict in TestStand 3.5

[leek]

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?

[RayFarmer]

Hi,

It sounds like you have some or all of your SequenceCall steps dynamically load they sequence file at runtime, otherwise you would be seeing the conflict dialog appearing when you first load the top level sequence file into the sequence editor.

Have you actually changed the CommonResults?

Probably, one of your sequencefile has a local copy of CommonResults and is using this, you will have to work you way through them by loading each sequence file into the editor to find the affected sequence file(s) and then delete the CommonResults that is local.

Regards

Ray Farmer

[leek]

Hi,

I think you are correct that they are loaded dynamically.  And this is a default setting.  I have not made any change to the CommomResults variable.  This variable, among others, is not deleteable, per TestStand user manual.

However, many of us share the same TestStand in the Test Station.  I don't know if others have changed this variable.

I loaded all sequence files with conflict variable and seaved manually one-by-one.  And go through this same routine of loading and saving again after I exit the TestStand, turn-off computer, and turn-on computer again.

Thanks

[RayFarmer]

Hi,

The default setting is to pre-load everything.

Regards

Ray Farmer

[leek]

Hi,

You are correct. I just checked. And I selected one of the sequence file with the conflict problem, changed to dynamically load option, and ran TestStand.  It made no difference.  I still got the very same complaint. But if I open the problem-sequence file and save it, TestStand detects the same problem in the very next sequence file. All of these files have been saved and re-save every time I launch and run TestStand.

Thanks,

[AllenP]

What is the version of CommonResults?  Does it have any fields inside of it, or is it empty?  Even though you may not have modified it, since it is a type, if you opened a file that had a modified version of it, you may have modified your sequence file.  Can you post a small example?

Allen P.
NI

[leek]

Hi Allen,

The version for CommonResults is 3.5.0.1.  The field is empty.  Attachment of a small file is included.

Thanks,

[AllenP]

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

[leek]

Hi Allen,

The process took me sometime to do.  I had many sequence files with this problem.  But the update seem to solve my problem. I was able to run my sequences, save them, exit TestStand, turn-off computer, and changes remained fix after turn-on computer again.

Thanks

[mitulatbati]

Hi Allen,

I have followed your instructions, but there is no success 😞 The version of the CommonResults by me was 3.1.0.12738 (or something like this, but not 3.1.0.0.) I have made the changes which you mentioned, I opened all the sequence files, where this type occurs. As I have been ask, if I want to use the currently loaded file, I pressed YES, so the version of the type in the sequence file hase been changed to 3.1.0.0. I have done it with all the possible sequence files, as well as the called sequences from the sequential model.

If I open these sequences, I see the correct version of the CommonResults, but if I open the Type Pallette, the star is there - so the type pallette file is changed. But the version of the CommonResults is 3.1.0.0 too. It seems to be no type conflict anymore. Why do want TestStand to save changes, when I idn´t change anything? Annoying.

Best Regards

MB