Can a test step, or plugin a test step calls, access the list of open instruments in a test run?

Technical
1

The default test step design is to configure a member to receive instrument instances at runtime, which requires the test plan editor to assign that instrument at edit-time.

I would like to research what is possible for more generically associating a set of signal names with a list of instrument names, and have a test step lookup and access the opened instrument that is associated with the signal name (and any switching information too).

For example, if I am managing a signal to instrument mapping in an external file and my test wants to access one of those pins, I would like the test step to lookup which GPIO instrument, its channel, and potentially MUX routes to assess that signal to perform the operation.

Technically I could create custom instruments that register themselves on Open, but that seems duplicate of what OpenTap is already managing internally for test runs.

How can I access the opened instruments when running a test plan from within a test step, or design some plugin that a test step uses?

[Edit] Just found a similar unaswered post: “Programmatically accessing an instrument in OpenTAP”…

2

Hi @scottri,

This is not an API that we normally recommend implementing, but the ILockManager gives you an opportunity to access and modify resources just before they are opened and just after they close.

So if the test plan starts with some place holders assigned to those resources, you can replace them with concrete resources just-in-time. They should be assigned back to the place holder at “AfterClose”.

To get started with that API, I suggest you just create an implementation and just log what happens or use break points to understand when you get the callbacks. Simply creating an empty implementation should not affect how the test plan executes, but gives you an insight into how it works.