type conflict migrating from 4.0 to 4.1

[david_jenkinson]

Hello,
I have just installed Teststand 4.1, upgrading from 4.0.  I am getting a type conflict error preventing me from running.  The error is occurring on step "Setup Post Result Callbacks" in a modified version of the single pass process model.  It says the following:

"Type 'NI_DatabaseOptionsColumn' is invalid because it conflicts with the existing type of that name. To avoid this error message, you should open the file with the type conflict in the Sequence Editor and resave it.
The sequence file 'C:\Program Files\National Instruments\TestStand 4.1\Components\Models\TestStandModels\ModelSupport.seq' could not be loaded.

-17329; Invalid type - conflicts with an existing type."

We have not ever touched this type or modified it.  I am also having a problem finding where it is defined.  Now I could do exactly what it says and open that sequence, and save it, and maybe my problem would go away (I'd have to repeat this action on 6 test stations), but to me it seems like the type palettes should be automatically updated with the new definition.  So I went and changed the station options for type conflict resolution to "always" from the new option introduced in 4.1, and I  still get the error after terminating and re-launching teststand.  The option seems to imply that conflicts will "always" be resolved, but not in this case.

So it seems like if I go ahead and open the modelsupport.seq sequence and save it, won't the next version of teststand overwrite that and I'll have the same problem next time?  Shouldn't the "always resolve conflicts" option update the type palette files that are affected, and prompt me to save them on closing teststand, instead of erroring during the run? 

Thanks for any help
David Jenkinson

[RayFarmer]

Hi,

Have you tried the Type Diff Tool

http://forums.ni.com/ni/board/message?board.id=330&thread.id=18543

Regards

Ray Farmer

[david_jenkinson]

Ray,
No I haven't tried that, although it looks interesting. 

What I did end up doing, is actually relenting an opening up the sequence it was complaining about, then running.  I could close it after (no save prompt), close teststand, reopen teststand, and the problem is gone without saving anything (even though the error message said I need to open and SAVE the sequence).  StrangeI didn't have to save the sequence, as if there was really no change.   I had to do this on all the stations.

Thanks
Dave

[RayFarmer]

Hi Dave

Thats a bit weird but maybe the problem was in one of the cfg files that would have updated as you close TestStand.

Do you have a simple SequenceFile that you can post that came from your TS 4.0 and shows the conflict when you load it in TS4.1?

Regards

Ray

[dug9000]

If you modify the process model at all it's best to copy the entire directory under Components\Models to the user version of that directory. I think you might not have done this since you are getting the modelsupport.seq from the 4.1 installed directory and not your public directory.

I think what's happening is that you are mixing different versions of the process model sequence files. Modelsupport.seq seems to be coming from the 4.1 installed version, yet you mention you modified the process models which means that your process model sequence file is likely based on the 4.0 version of the process model sequence file you modified. What's happening is that when you run using your 4.0-based version of the processmodel you are loading the 4.0 version of the types into memory (process model types are not currently in a type palette), then when it gets to a call into modelsupport.seq and tries to load the 4.1 version of the types it can't, because while an execution is running you can't switch which version of the type you are using (i.e. because the modelsupport.seq has a newer version of the type TestStand would normally autoresolve the conflict to use that version of the type, but you can't do that while an execution is running).

Thus if while you aren't running you open modelsupport.seq it will autoresolve the types to the 4.1 version and since your processmodel is kept loaded it will keep that version in memory and that is why you don't see the error anymore once you do that for that run.

What I'd recommend instead is one of the following:

1) Since there were some signficant changes to the models in 4.1 in order to support the new Additional Results feature (changes were mostly to reports and database logging), if you want to take advantage of this feature you should redo your customizations of the process model using the 4.1 versions as your starting point. You can use the sequence file differ to help you figure out what exactly you customized in the 4.0 version if needed. You should make these changes by first copying the entire Models directory under the program files components directory to your public components directory and changing it there. This is what I'd strongly recommend as you will then get all of the new features of 4.1 including the additional results feature and the changes to the process model required to support it.
2) Another alternative is to copy the entire 4.0 models directory to your public models directory and copy over your modified files there as needed as well. If you do this you will be using the 4.0 process model with 4.1 which should work, but you will not be able to use the new additional results feature effectively.

Hope this helps,
-Doug

[dug9000]

---

@david_jenkinson wrote:
Ray,
No I haven't tried that, although it looks interesting. 

What I did end up doing, is actually relenting an opening up the sequence it was complaining about, then running.  I could close it after (no save prompt), close teststand, reopen teststand, and the problem is gone without saving anything (even though the error message said I need to open and SAVE the sequence).  StrangeI didn't have to save the sequence, as if there was really no change.   I had to do this on all the stations.

Thanks
Dave

---

I want to help explain what probably happened:

1) When you opened up modelsupport.seq it didn't modify that file because that file has the newest version of the type it instead modified your process model which is normally kept loaded while the sequence editor is running even if you don't have it explicitly opened. Thus there is and was no reason to save modelsupport.seq.
2) When you closed teststand it likely prompted you to save all modified files, this includes your process model that now has the newer version of the type even if it's not open in a window. You probably said yes and saved the updated version of your process model with this newer version of the type.
3) Since both your process model and modelsupport now have the same version of the type you no longer get the conflict.

I'd still recommend you update your modified process model to be based on the 4.1 version so that you can take advantage of the new 4.1 Additional Results feature and to ensure that you don't run into unexpected problems with report generation and database logging.

-Doug

[david_jenkinson]

Doug,
That is probably what happened.  I did get a prompt to change the process model.  So it seems like I should now have the latest data/step types from 4.1 included in the process model, since it updated and I saved, correct?  Therefore I should not have to duplicate the changes in the new base process model that shipped with 4.1, as this is the reason behind having the ability to update types in the first place, if I am understanding correctly.  At any rate, things work now and thanks for the insight, that makes sense.

Dave

[dug9000]

You might be ok with what you have now, however the 4.1 version of the process model types are not intended to be used with the 4.0 version of the process model. If you don't care about using the new features added to the 4.1 process model then I'd recommend using the 4.0 version of all of the process model files (not just the ones you modified) by copying the entire 4.0 'Models' directory to your public 'Models' directory in 4.1 and overwriting the files you customized in 4.0 with your customized version (but before you resaved them with the 4.1 types). If you do this you will then be using the 4.0 version of all of the sequence files and code modules used by the process model (including the process model types).

Basically, the recommend way of modifying the process models is to copy the entire Models directory to the equivalent public\User location for the Models directory and make your changes there. This ensures that you have all of the files used by that version of the process model so that you won't get this mismatch of versions that you are experiencing now.

It's quite possible in this case that the changes from 4.0 to 4.1 are small enough that things might end up working ok with this mismatch, but it is not the recommended approach.

Hope this helps clear things up,
-Doug

[david_jenkinson]

Doug,
Our customized version of the process model sequence lies in a completely different directory, changed under the station options/model dialog.  We did have it in the component/user for a while, but that became problematic and inconvenient for source control purposes the details of which I won't go into here.  The station options/model dialog lets you change the path to your custom model, so it ought to work.  I think that the whole idea behind having a type palette in the first place, is to resolve type conflicts in sequences no matter where they lie, and being the central repository of the type definitions by which all other sequences are modified.  I think the system worked fine.  I think the root of my confusion came from the fact that the error message was a bit misleading, as it stated a different sequence that needed to be modified and saved than what was really the case (the process model).  I think the fact that the process model itself was saved with the new type fixed the problem, and as you mentioned before the error itself originated from the fact that it was unable to resolve the conflict at run time, and needed the process model open prior to run time to resolve the conflict. 

Hopefully this thread will give someone else an idea in the future what to look for.

Thanks for the help.

Dave