Always run steps(s)

Say I have a safety tester situation, where I need to prevent physical access to the DUT while the test is running, and a test plan something like this.

If I have Break on Fail in Engine Settings, and ‘Some Test’ fails, how can I ensure ‘Remove Power’, ‘Delay’ and ‘Unlock Interlock’ still run?

I thought I might be able to have the Enigine Settings only on ‘Break on Error’ then define ‘Some Test’ etc in a Sequence with Break on Fail and still have the controlled shutdown steps run but no luck, unfortunately.

I could always just execute a plan after this that waits a bit and then unlocks the interlock, is that going to be the more sensible approach?

One way would be to implement the PostPlanRun() method in the ‘must-always-run steps’ and do the
clean-up there. If implemented, PostPlanRun() will be executed after the last teststep even if testplan fail or error.


Similiar to @GoranJohnsson 's answer, you can implement the required operations in the Close() method of the DUT resource.

1 Like

Thanks for the suggestions, pretty much what I was thinking.
It doesn’t quite feel right to implement this in the PostPlanRun for the ‘Apply Power’ (yet) as it’s just a generic SetDigitalOutput step. Maybe if I made a dedicated ApplyPower step with Connection and Delay properties it might be a better fit.

I think it’d be nice to be able to build this kind of functionality out of lower-level test steps, though. Just from the perspective of someone examining/modifying the plan in Editor.

I think I’ll just add a delay after executing the plan in my GUI for now while I mull it over.

I think what was already stated are good suggestions, but you can also try this:

Since you have already programmed a Lock/unlock procedure, I suggest you turn that into one step that locks during child step execution. For example like this:

public override void Run(){


Then you just need to nest all the other test logic inside that.


Thanks, Rolf.
I settled on a ‘With Connection’ step, very similar your sample, that makes the connection before running child steps then breaks the connection with an optional delay in the finally block. I use the connection that applies power, since it’s really a delay after removing power that I want. Then I hand off to the app that runs the plan to deal with unlocking the interlock.