ProcessSetup Callback

[PXXXI]

Hi everybody.

I'm going to use standard sequentialmodel.seq in order to test my UUTs. I use ProcessSetup and ProcessCleanUp in order to execute one time the setup and cleanup phases while I'm testing UUTs with TestUUT entry point. I want to include result of some tests running in callbacks in my report XML.

I opened the sequential model and I checked record result and enabled tracing for callbacks.

The tracing runs and the recording too but my test doesn't record result from the test body in main sequence.

Does anyone explain to me why?

Thanks.

[Norbert_B]

It doesn't make sense to try ProcessSetup and ProcessCleanup to add stuff to the report.

Both callbacks are connected to functionality of the test system, not specific to certain DUTs you are testing.

As reporting focuses on information on the DUT (not the test system), ProcessSetup and ProcessCleanup will not put anything in reports.

Question: What data do you want to record? Esp. Cleanup: How does that concern specific DUT results?

Norbert

[PXXXI]

Thanks for your response.

Sure, core data to store in report is contained in the mainsequence. My system is interfaced with a power control drawer that also allows to identify test adapters, manage

power distribution and so on. I idenitfy adapter IDN only one time in the process setup and then I want be able to store this result or eventually a failure notices as step.result.reporttext of

the related step.

The checking of "record result" is already done for other callbacks as I found on this forum. I don't understand why my system doesn't record any other results.

[Norbert_B]

Hm, do i get that right?

- In ProcessSetup, you power up the hardware interfaces for the DUT. If anything goes wrong, you want that in the report.

- In the MainSequence of your execution, you interface to the DUT. Power consumption is something you might want to record. This is a parameter supplied by the power supply which was initialized in ProcessSetup

- ProcessCleanup will power down the system, nothing to record here.

My recommendation is to keep the handle to the power supply as globally accessable source (globale variable or pass as parameter each time). With that handle, you can acquire any data from the power supply within your client DUT test execution, hence it is very easy to get this value in the report.

hope this helps,

Norbert

[PXXXI]

Hi Norbert.

Your resume fits quite well; any instruments or resources is already globally shared. I only want to store four test result done in process setup callback.

1) During my process setup I initialize all resources and I perform a self test routine. Finally I identify the test equipment.

2) Main sequence that loops for execution entry point TestUUT; each subsequence only takes the required instruments and resets them during itself cleanup.

3) Process CleanUp, where I release all instruments and power off all resources.

If I check "record result" for process setup in the process model, TS effectively stores this results in my report. I can't explain why TS doesn't record results from main sequence.

Is it possible that a simple check in the process model casuses this problem while TS is collecting results during execution?

I can't explain this.

Thanks.

[Norbert_B]

Which TestStand Version are you working with?

Norbert

[PXXXI]

TS 4.0.

I had a lot of problem to fill step.resul.reporttext, anyway is done and runs.

From newer version, 4.1 and others, is possible to use the additional result tab and updated API.

Thanks.

[RaviShrigiri]

Attached a sequence which is a round about way of doing this.

Create a sub-sequence and add all the steps you need to put in process setup callback.

Create a fileglobal of result list type ( you can copy from locals).

The last statement of the sub sequence should be fileglobals.resultslist = locals.resultlist.

From process setup callback just call this sub sequence.

In the main seqeuence the first statement should be  locals.resultlist  =fileglobals.resultslist

Explanation :

Processsetup callback does not record results hence creating a new sub sequence.

The results are always stored in locals.result list.

This list is temporarily copied to fileglobals and re copied in the main sequence to be reflected in reports.

Hope this helps.

[PXXXI]

Run!

Thanks for your explanaition.

Davide.

[SachaE]

Hi all,
To explain what you're achieving here a little, the default (pre 2012) sequential model process model TestUUTs or Single Pass execution entry points pass on ONlY the process model 'locals.resultlist[0]' variable on to the report generation callback sequence as it executes through. This is after the 'mainsequence' call has been made and since this single sequence call step in that execution entry point is the only step that is set to record it's results then it is the only item (hence [0] ) in that locals.resultlist.
This singular element is a result container type which is processed to make the report.
There are several parts of other information that make it through to the reporting section too, such as the user who is logged in, or the UUT container which has the serial number included inside of it.
The point in time when you need the data from process cleanup or process setup callback sequences is the point of report generation AND you need to get it passed in to that sequence call.
The options are therefore 6 fold (always 6 places to implement stuff in TS)
1) modify the process model (e.g. Customise the locals.resultlist to capture that extra data and mark it as include in report flags. )
2) modify the client sequence file (e.g. To override the report generation to do it yourself assuming you have access to the process setup generated data)
3) modify the steps to record the extra information each time as necessary (e.g. have a none adapter step that uses the 'add extra results' options or ActiveX to include the values currently stored more globally)
4) modify the module code to include the extra data (e.g. Writing code to solve the problem to be called from TS)
5) use the OI to call specific sequences (e.g. not using process setup and cleanup per se, but forcing calls or grabbing the data at the OI level and passing that on
6) use the variables that are already being processed (e.g. Piggy back the data in through the runstate.root.locals.UUT container so it at least makes it to the report generation section.

Option 6 is effectively implemented in The example from SunRS.

Think carefully about what this implementation will mean for you in the future - I.e. how often will you re-use this architectural method and when will it need changing.

Just my 2 cents.

Thanks
Sacha