writing Locals.ResultList to disk to save memory during execution

[pdobratz]

TestStand 2.0.1

We have tests that generate a lot of results for each UUT. This causes TestStand to run out of memory either before the sequence finishes executing, or while the report is being generated. We have already Eliminated "record results" for each step where it is not absolutely necessary, but still the results are taking up too much memory. We have looked at and incorporated OnTheFlyReports, but we still need the finished report in correct heirarchical form.

We are currently investigating writing the results to disk after every step in MainSequence completes. To do this, we call PropertyObject.write on the first element in RunState.Main.Locals.ResultList from ProcessModelPostResultListEntry
. Then we delete this element from the array to free up memory. (After this we check for and write all other results from looping to disk using the same technique as well.) In the report generation, we then call PropertyObject.read to read the results in from a file before we process them.

Now we are finding that in some cases, the contents of the ResultList are not exactly preserved on the transfer to and from disk. Particularly, when we have a multi-numeric limit step (of type NI_MultiNumericLimitTest), certain fields get created regardless of whether or not they existed in the original ResultList entry. Specifically, elements in the Measurement Container (instances of type NI_LimitMeasurement) have properties Limits.High and Units, regardless of whether these properties existed in the original copy of the ResultList entry. For this specific case, we can tailor the report generation to ignore Limits.High or Units appropriately.

Are there any other types that we should look
at that may not be the same after they are written to and read from disk using PropertyObject read and write?

Thanks,
Peter Dobratz

[Scott_Richardson]

Peter -
You are seeing this behavior because when TestStand copies the result from the step to the result array, it sees that the property "Limits.High" has the flag "PropFlags_DontCopyToResults" set, so it excludes this from the copy. If you looking at the stream, the "Measurement" property still has its type specified, "NI_LimitMeasurement". So when the read code tries to recreate the result array element, it first creates the default type which includes the excluded property and then assigns the value contents from the stream to the object.

Doing a search on the step type code, I found the following step types that use this flag:
Message Popup
Multi-Numeric Limit
Numeric Limit
Ivi Dmm
Ivi Scope
Ivi DCPower

Scott Rich
ardson (NI)

[pdobratz]

Scott,

Thanks for the help.

One other problem we are seeing is when we have a Wait step. For example, we have a sequence call from MainSequence execute in a new thread. Then later there is a Wait step that waits for that sequence to complete. The original ResultList entry for the Wait step contains the following properties:

TS.SequenceCall.ResultList
TS.SequenceCall.SequenceFile
TS.SequenceCall.Sequence
TS.SequenceCall.Status

After this is written to and read from disk, the TS.SequenceCall.ResultList property is missing. We need this in order to report the results of the sequence call we are waiting for. Any ideas on why this gets stripped after the write/read operation?

Thanks,
Peter Dobratz

[Scott_Richardson]

Peter -
The PropertyObjec.Write function internally uses the same code as PropertyObject.Serialize. The TestStand 3.1 online help for Serialize says that the method "...does not include alias subproperty objects in the stream. Refer to IsAliasObject for more information about alias objects." The result list in this case is an alias object. This means that the object is being skipped by Write and not persisted to disk.

The only way around this is to stream the alias object separately from the other parent container and store it into the same file using a different "object name". Another option is to use GetXML/SetXML in TestStand 3.1. GetXML has an option to exclude alias subproperties, but includes them by default. You would hav
e to write the stream to file yourself.

Scott Richardson (NI)

[grafne]

Hi scott,

Thanks for the tip here. I am currently takign my station globals and want to write/read from an xml file (this is  station config generated in xml).

My only issue is how I write the xml produced by getxml() to a file.  Can you give me an isea of how this would be done?

Thanks,

Graeme