Is there a way to run Open's and Close's on certain order?

Opens and closes are ran in parallel but sometimes it would be better to prioritize some resource to run Open and/or Close before other. As an example if I would like to cut power before switching relays.

4 Likes

@mikko.ala-kojola resources can have dependencies on each other. This is done similar to a Test Step where your top level instrument has a setting that points to another instrument:

[Display("Open Prior Instrument", Groups: new[] { "Examples", "Plugin Development" }, Description: "An instrument containing dependent instruments of resource open before & ignore behaviour type.")]
    public class OpenPriorInstrument : Instrument
    {
        [ResourceOpen(ResourceOpenBehavior.Before)] // This is the default behavior
        public Instrument PriorSubInstr { get; set; }

        [ResourceOpen(ResourceOpenBehavior.Ignore)]
        public Instrument IgnoreSubInstr { get; set; }

        public override void Open()
        {
            TapThread.Sleep(2000);
            Log.Info("Opening Prior Instrument");
            base.Open();
            PrintSubInstrStatus();
        }

What if there are multiple instruments dependent on the same instrument? Like if multiple RF instruments are dependent on the same switch matrix, and you’d like to make sure the switch matrix opens first and closes last to prevent hot switching.

2 Likes

@john.berlien interesting question. @mikko.ala-kojola is this the case for you? Sounds like it might be. In that case, it may be better to use the PostPlanRun method of different Test Steps. Similar to having a cleanup function. This is called before all Instrument Closes. So in your Power Supply case you could have a Test Step that turns the Power Off in PostPlanRun, that way when the Closes are called they can all still be run in parallel and no dependencies are needed.

image

@rolf_madsen maybe you have some other thoughts on what could be done?

Welcome to the OpenTAP Forum @john.berlien!

2 Likes

Thanks Jeff!

So @brennen_direnzo is PostPlanRun always executed, even in Error and Abort?

Correct. You can think of PostPlanRun as kind of a Cleanup, and that is the reason for not having it broken out as its own individual Test Step. As long as the PrePlanRun method of the Test Step was called, the PostPlanRun method will be called, regardless if the Test Plan ran to completion, Errored, Failed, or Aborted.

So the PrePlanRun method must be overridden?

Yeah, because by default it is a NoOp

Okay thanks Brennen! I think that’s the best option for now.

In the future, could we make some additions to support an instrument hierarchy? Like an instrument having multiple dependencies, and multiple instruments dependent on an instrument?

2 Likes

Yeah I don’t have any good thoughts on how this could be done, but I can see the potential value. Can you submit a request here?
https://gitlab.com/OpenTAP/opentap/-/issues/new?issue[assignee_id]=&issue[milestone_id]=

2 Likes

How about implementing this interface for each resource that needs its closing order controlled:

    public interface IClosedEvent
    {
        ManualResetEvent ClosedEvent { get; }
    }

Call ClosedEvent.Reset() within the Open method.
Call ClosedEvent.Set() at the end of the Close method.

Then at the beginning of each resource’s Close method, add your logic for deciding which other resources need to be closed first, collect all their ClosedEvents into an array, and call ManualResetEvent.WaitAll(arrayOfClosedEvents);

This would support hierarchies too, like resource A waits for resource B, which waits for resource C, etc.

1 Like

Actually we have support for a feature we call ‘stacked resources’.

If resource A refers to resource B, then depending on some property attribute, B can be opened before A is opened and only closed after. It can also happen in parallel.

You can also have C → B ->A, which means C opens before B opens before A.

public class TestInstrument : Instrument{
// see [ResourceOpenAttribute]
  public TestInstrument OtherInstrument{get;set;}
}

There should be an example called something like PluginDevelopment/TestSteps/Attributes/ResourceOpenAttributeExample.cs

Essentially, the behavior of this is similar to what @david-wsd is suggesting with IClosedEvent.

2 Likes

Thanks Brennen and Rolf, I will look into ResourceOpenAttribute.

2 Likes

@rolf_madsen would this work if you had say: B, C, and D that all had a dependency on A being opened first?

@brennen_direnzo, Yes, it should work in this case as well. It also works with “lazy resource management”.

@mikko.ala-kojola, the default behavior is that B waits for A to open. and A waits for B to close. Of course in the case that B depends on A. ResourceOpenAttribute can be used to modify that behavior. So most often you do not need to put ResourceOpenAttribute

1 Like

It seems I can get the wanted behavior with ResourceOpenAttr. However I have a problem when I tried adding into my own baseclass. I have class hierarchly like this: Instrument → MikkosBaseClass → Driver. If I have ResourceOpenAttr in driver it is fine. But I wanted to have in MikkosBaseClass. It does not work from there. I get “Unable to serialize property …” exception from ObjectSerializer.Serialize and the reason is that object val = subProp.GetValue(obj); throws exception as the value is null.

I tried investigating it a bit, but could get to the root of it. I do not wish to add ResourceOpenAttr to all of my drivers because, eventually developers forgets to add it into their new instruments and I would need to be wathing after them =) By having it in baseclass is easier as I only need to watch that drivers are derived from correct baseclass.

I have another question on this as well. What if the open/close order depends on the specific plan? Like, you want the instruments to open in a specific order in one plan, but another order in a different plan. Then you’d need a new driver for each plan, to create different instrument dependencies! This seems overly cumbersome and not a good solution. Also, you’d still want to use the ResourceOpenAttribute instead of PrePlanRun/PostPlanRun in the case that the instruments are in an unknown state prior to running the plan. What if there were some way to store in the test plan or test bench configuration the instrument open and close order? Because also - you may not always want the instruments to close in the reverse order they open.