How can I restore FileGlobals in a Client Sequence File that is reloaded?

[Hans Olsen]

Hi,

I'm using TS2.0.1f1 and dynamic client files (search "DynamicClientModel" to see an example) in order to load different test sequences depending on what product should be tested.

We do something like this,


newseq = IEngine.GetSequenceFile(...)
Execution.ClientFile = newseq
...
Do testing
...
IEngine.ReleaseSequenceFileEx(newseq)
Goto

The first time a client sequence file is loaded it will copy the default FileGlobals from RunState.ProcessModelClient.Data.FileGlobalDefaults (TS does this automatically).

The problem though is that after calling ReleaseSequenceFileEx() the actual sequence isn�t really disposed. Since when we later start over with another prod
uct that uses the same client sequence file the GetSequenceFile() call returns the same copy that was used before and doesn�t copy the FileGlobals from RunState.ProcessModelClient.Data.FileGlobalDefaults, there by the second time the same sequence file is used, the FileGlobals don�t have there default values.

So, to get back to the subject, how can I make sure that the second time around the FileGlobals have there default values?

(Keep in mind that all this is done within the same execution of the processmodel.)

I�ve included a short demonstration of this in the attached zip file.

Any help appreciated.

Cheers,
Hans

[Scott_Richardson]

Hans -
By design, an execution maintains a run-time copy of the sequence file globals for the lifetime of the execution. I am not sure if it is possible to get the execution to drop its run-time copy. Your options are:

1) to have a controlling/loopin execution launch the model file and client file in a new execution.

2) update the globals manually via an expression. In the PreLoop callback of the client file, I added a Statement step that had an expression as follows:
FileGlobals = RunState.SequenceFile.Data.FileGlobalDefaults

Scott Richardson (NI)

[Hans Olsen]

Hi Scott,

Thanks for the answer, I had been thinking about option nr 1 in particular but that would require more changes than I'm prepared to do right now.

I tried option nr 2, but instead of adding that line to the client sequence file I made the copy operation in the process model like this.

...
Execution.ClientFile = Locals.ClientSeq
Locals.ClientFileGlobalsRef = Execution.GetFileGlobals(Locals.ClientSeq)
Locals.SerializedCopy = ""
[RunState.ProcessModelClient.Data.FileGlobalDefaults] PropertyObject.Serialize(Locals.SerializedCopy, "Test", 0)
[Locals.ClientFileGlobalsRef] PropertyObject.Unserialize(Locals.SerializedCopy, "Test", 0)
...

This seems to do the trick, although option nr 2 does seem a bit like doing things the way they weren't
supposed to be done.

Regarding option nr 1, are there any �Best Practice� documents, guides or examples on how one should best manage Engine and Execution lifetimes? Or to put it differently when to spawn new Executions and or Engines during the span of working with several units of the same product type and/or different product types?

Cheers,
Hans

[Scott_Richardson]

Hans -
Your serialize and unserialize will work fine. My option 2 is just a simple way to do it from within the context of the running sequence to "reset" the globals to their default values.

I am not aware of any documentation to suggest how to manage the engine and its executions. Our default parallel and batch models are the best "example" of execution management, but really whether you launch a thread or an execution is arbitrary and TestStand will handle it. The key issue is to not use a separate execution when a thread will work. Or don't use a separate thread if a serial sequence call will work. Keeping it simple goes a long way.

Scott Richardson (NI)

[Wojtek]

....Is is possible in TS3.0 to use the "Engine.ReloadGlobals" method to pull in the globals again from the sequnece file?

[Scott_Richardson]

Wojtek -
Engine.ReloadGlobals reloads station globals and not file globals.