Be abble to flush result recording, using TestStand API ....

[manu.NET]

Hello,

I have a sequence which must loop a very long time, with cyclic access to hardware components.

In order to limit the amount of memory used by my application i decide to use the famous "Disable result recording" flag.

Beside this problem, my sequence don't have to collapse in case of runtime error (Due to hardware manipulations during execution),

and operators don't have to aknowledge the "error dialog box" ... every time an error occurs !

To handle my runtime errors, i deceide to :

• The main sequence is a loop calling the different fonctionnalities by sequence calls 
• I configure the sequence calls with "ignore RTE", so my mainSequence never stops on runtime error 
• I Configure the "runtime error handling" with the Run cleanup ... so no popup disturbs the operator

This is OK, but i also want to treat my errors (Tracing at least) ... and then i get the folowing problem ...

• The errors are no more accessible using Runstate.previousStep.result.error... ... Runstate.sequence.main.... .... , because i have used the "Disable result recording" flag.
• Storing a runtime error in locals is not possible in post expressions ... because post expressions are not executing after a runtime error

Perhaps the only way to handle my problem would be to use the SequenceFilePostStepRuntimeError callback ... 

But doing so, would need to use stationGlobals or FilesGlobals to get back the error in my main sequence. (A complicate architecture only to get an error !)

So, it would be nice, to be abble to ...

• Let the result recording working
• This make the runstate.previousstep.result.error... works fine
• And sometimes, be abble to flush the result tree (Using a new API function. Something like <Execution>.FlushResults( ....) )

PS : My sequence don't use any report, database writing ... thats why disabling results recording is possible !

I don't know if i am clear ? (And with my bad english ???) 

Manu.

[warren_scott]

have you tried something like "SetNumElements(Locals.ResultList,0)"?

It's got limited scope, but might get you pretty close to what you are looking for.

[manu.NET]

Hello Warren,

Are you sure i can do this ?

I would do so, for Arrays created by me ! But ResultList ???

Your idea is simple ... but i need a NI expert confirmation, to confirm that i won't break something by doing so !!!

I would need something stronger than locals.ResultList shrink .... something like SetNumElements( Execution.resultList , 0 ) ?????

Thanks a lot for your answer.

Manu.

[Romain_Duval]

Hi Emmanuel,

Instead of implementing such a functionnality, would it be possible for you to use the custom-step type wrapping for your step?

Indeed, the Post-Step is called even when a runtime error occured : execution step order for CST

could you try at least to wrapp the sequence Calls step used in your main and implement a custom Post step to catch and handle the error to see what happens?

Regards

[manu.NET]

Hello Romain, So, as i undestand, i will have to create my own wrapper over all existing steps in order to do what i want ? What a big work !!! And what about standard TestStand steps ... do i also have to create a wrapper ??? LOL ! Manu.

[Romain_Duval]

Hi Manu,

I don"t think it would be such a huge work. You can use the "combine with step type." and TesStand will handle the merging for you automatically following these rules:

The Step Type option creates a new step type that has all of the custom properties and substeps both step types define. If both step types define a property  the same name or if the value of an inherent step property conflicts, the Step Type option uses the property or value for the step from which you initiate the operation. The new step type uses the default built-in step properties and the default module settings from the first step type. 

Otherwise, it would be possible with some work to do it programmatically using the method called StepType.AddSubstep ( newSubstep) .

Another workaround would be to modify the ReportGenerator.seq process model plugin to handle the ResulList by yourself. If an error is listed in results then log it and flush it.

Regards

[dug9000]

Ignoring runtime errors is what's keeping errors from being generated and propagated, not disabling results. If you want the flow of execution to do the normal cleanup behavior and error propagation, you should not ignore runtime errors, instead you can set the station option "On Run-Time Error" to "Run Cleanup" instead of "Show Dialog". That will work and will give your UUT an error status even if results are all disabled.

[manu.NET]

Thanks Dug9000,

Ignoring runtime errors is also not my cup of tea !

I have found an other way to solve my problem : For Labview Action Step !

Instead of using the default mapping of errorOut to Step.result.Error, i replace it by a Locals.error container.

Doing so ... there are no more runtime errors ... and i can test, using standard flow control (If, while ... ), the result of LabVIEW calls, without having to modify the default runtime error option.

So ...

-> I can keep : On runtime error, show dialog Box

-> I can handle Labview errors manually, without disturbing the operator ! (When it is no needed)

But i cannot do the same with standard steps like sequenceCalls !

Manu.

[WireWeaver]

I'm declining this idea due to lack of community support