Why did TestStand modify my Sequence File

[Scott754]

Greetings Everyone,

     I'm seeing something new all of a sudden.  We have five different Client Files that are available to the Operators for use.  Two of the files were done by a co-worker and the other three by myself.  Lately, whenever the operator finishes using one of my co-workers file and loads up one of mine the is a "*" after .SEQ" in the tab.  Please be advised that all five of these files are password protected so no one can change the file.  Since the operator has been given absolutely no privledges.  So when he attempts to close the file, they are greeted with a Sequence Editor dialog box that of course states that they "You do not have sufficient privledges for saving this file. Closing now will discard changes to the file".

     When I try the same thing, but logged in as administrator, I receive a different dialog box that asks "The file xxxxxxx.seq is modified because of automatic conversions that TestStand performed when loading the file.  Save the changes?".  This also shows and "*" after the model name on the bottom of the display.  When you try to close TestStand you are greeted with yet another dialog box "Modified Files", which shows the Client File and the Model.seq.

     Why is TestStand doing an automatic conversion on something that theorectically didn't change since the operator can't do things that would cause this to happen?  The model sequences are independent of each other.  Is there a way like in Labview, when the library a grabbed from a different location and advises you of the fact, in TestStand that I may be able to see what is going on.  My fear is that is I save the changes that A) this is not going away and will be like this and B) will cause undo harm to the client file and cause production down time that I can't afford. 

     Thank you for reading and sorry that I'm very lengthy in this post.  I look forward to hearing from some of you with you thoughts and direction into understanding what this conversion is doing.

Regards,

Scott

[dug9000]

Most likely one of the sequence files has a newer version of a type and thus is modifying that type when it is loaded. What version of TestStand are you using? In newer versions of TestStand sequence files are not allowed to modify types in a type palette by default without the user explicitly choosing to do so.

-Doug

[Scott754]

Hi Doug,

     Thanks for the reply.

     We are using TestStand 2010 (Version: 4.5.0.310) and Labview 2010 (Version: 10.0.0).

     Is there a way of finding out what file(s) are affected as you can with Labview and it libraries (ex: View/Load and Save Warning List)?

Regards,

Scott

[dug9000]

---

@Scott754 wrote:

Hi Doug,

     Thanks for the reply.

     We are using TestStand 2010 (Version: 4.5.0.310) and Labview 2010 (Version: 10.0.0).

     Is there a way of finding out what file(s) are affected as you can with Labview and it libraries (ex: View/Load and Save Warning List)?

Regards,

Scott

---

When you open the file in the sequence editor is it also marked as modified? If so you can then do Edit->Diff Sequence File Against.. (menu item). Browse to the file (to diff versus the in memory) version. When the differ comes up. Go to the options and uncheck the option to "Automatically Merge Types" if needed. The differ should then be able to show you what's different.

Note that the modified indicator will also show up if the file is saved with an older version of TestStand. Conversions due to the file being from an older version of TestStand will not be shown by the differ since it will always be updating the file to the current version of TestStand.

Another way to see the differences is save both versions of the file as XML and diff with a text based differ (basically the same thing, but the TestStand differ is better at diffing teststand files then a text based differ can diff the XML format).

Hope this helps,

-Doug

[Scott754]

Hi Doug,

     Once again thats for the reply.

     That helped me out with regards to seeing what is changing.  Yes the client file is showing that it was modified as well.

     Let start with how this all came about.  As I mentioned already, my co-worker has two (2) clients and I have four (4) clients on the same Test Station.   When you load up one of my co-workers file (using SequentialModel.seq) everthing is fine no "*" next to either file.  Now you close that file and load his other file and the tab with client name is OK, but the SequentialModel.seq has an "*" next to it.  The funny thing is that when you close that file it closes with no indication that something changed.

     Now you load any of the four that I created, using a renamed/modified file (CCAxxSeqModel.seq) and this is where the fun begins.  Both the cllient and model have "*" next to them and as mentioned when you attempt to close the file the insufficient privledges pops up.  I guess the real question is why is the client file being automatically converted.  Looking at the comparsions (differs) there are 2 insertions related to the Report Options, which for some reason TestStand is adding a Parameter to my client.  Also it looks like all values in the Step Setting Tab "Limits" are change back to default (blank). It looks like one of my co-workers file may be causing this but he insists that I should save my Model file only and that will fix it and the client will be fine, what to you think?  We're at a point that I can't afford a problem since the production floor will be impacted.

     Thank you for the assistance so far, it's greatly appreciated.  Look forward to hearing what you can think of with regards to what if mentioned to this point.

Regards,

Scott

PS.  with the SequentialModel.seq*, I dug around and discovered that for some reason the ModelSupport.seq and reportgen_xml.seq (which we are not using) have "*" as well.  Also the differ showed Custom Data Types/ReportOptions Version of 4.5.0.223 (not in memory) and 4.5.0.225 (Modified) which is where one of the insertions is.

[dug9000]

It sounds like one or the other of you has changed the ReportOptions type. When you change a type, all instances of that type must conform to the type definition, thus the instances of that type that exist in the files must get modified to match the type definition if they don't match it already. That is why files are getting marked as modified. I recommend you settle on a specific version of the ReportOptions type that everyone can use. You might want to diff every modified file first (after loading all files involved) to make sure that is the only change and that the change shouldn't break anything, if so, then I'd recommend one of the following:

Either:

1) Put the latest version of the ReportOptions type in a type palette file (e.g. MyTypes.ini) and have that be the main way the type gets updated (maybe put the palette in source control). If you do this then files loaded with older versions will still show up as modified when in an editor, but when in an operator interface running in operator mode I do not think it will show them as modified or give any errors when closing them. This also ensures that everyone always uses the latest version of the ReportOptions type.

Or

2) Load all files involved and resave them. This could get to be a maintenance problem though if you are modifying the ReportOptions type on a regular basis.

Hope this helps,

-Doug

[Scott754]

Hi Doug,

     Sorry for the delay.  I looked over a few things and I'm still kind of confused as to what has evolved between my co-workers workstation and mine.

     Is there some kind of update to TestStand 2010 that would affect the ReportOptions Callback?  I looked at "View/Types" and when clicking on the Client file I clicked on Custom Data Type/ReportOptions and found a NEW entry labeled "IncludeTSExtensionElements".  I noticed that one of my co-workers files (most recently created) has the ReportOptions Callback inserted, but nothing in the Callback is any different than the stuff I have in mine.  Neither one of us has changed the types.  My thinking is that he may have installed some kind of update which altered his ReportOptions Callback and possibly cauing this issue.  I'm trying to understand were this change could have come from.  Searching the Internet shows that it has something to do with ATML Reporting, which we are to doing (ASCII Text File).  I also compared the Configure/Report Option/Contents tab in both of our Desktop computers and they are the same.  My search also unveiled that in the 2012 version they've added an additional check box between Include Attributes and Include Measurements in the Include Step Results section, which says Include TS Extension Elements.

     It looks like I may have to re-save all of my stuff, both the Clients and Models for each to conform with this interesting change of events.  I'd still like to figure out what happened that makes my co-workers TestStand 2010 different than mine.  Another tidbit, If I take his client file and copy the contents of his ReportOptions callback and delete the callback and save, Configure/Station Options/Model Tab and delete the Station Model and re-load his client, insert ReportOptions callback and paste what was there before and repeat the process mentioned of deleting the Station Model and re-load again, every file is fine with absloutely no "*" to talk about.

     Thank you very kindly for you help with this issue and I'll leave it open waiting for your final reply.  Again many thanks for helping me with this and look forward to you assistance in the future.

Regards,

Scott

[dug9000 · Accepted solution]

I think this type modification of ReportOptions is from the ATML toolkit. Perhaps your co-worker has the ATML toolkit installed. At any rate, what I said in my previous email should still work. I recommend either putting the version of the type you want in a type palette file or re-saving all files with the verison of the report options type that you want.

Deleting and readding the reportoptions callback like you described is just getting rid of the usage of the new type and replacing it with the older version (i.e. the parameter of the callback is an instance of the ReportOptions type). If you can do that everywhere that's fine too, though an easier way to accomplish the same result is to just put the version of the ReportOptions type you want in a type palette file (e.g. MyTypes.ini). Then when you load a file with a newer version of the type, teststand will alert you that there is a type conflict and you can choose to resolve it by using the already loaded type (i.e. the one in the type palette that you want). It's probably a good idea to keep the one you want in a type palette to avoid unintended usage of the wrong version of the type.

Hope this helps clarify things,

-Doug