Sharing a Resource (e.g., an Instrument) Across Multiple Sessions (Parallel Test Plan Runs)

Hello everyone,

I’d like to seek your advice regarding a challenge we’re facing in our test system architecture. To provide context, here’s a brief description of our setup and the problem at hand:

Test Scenario:

Our company develops test systems that feature multiple stations. This allows several operators to test DUTs simultaneously on a single system. Each station is equipped with a dedicated power supply, but neighboring stations share the same multimeter. Here’s how we’ve attempted to implement this setup:

  1. HMI Integration:
    Our Human-Machine Interface (HMI) connects to the OpenTAP engine via the Runner Client.
  2. Session Management:
    Each station runs its own unique session, allowing us to execute multiple test plans in parallel.
  3. Bench Profiles:
    We assign a dedicated bench profile to each session, which dynamically loads the appropriate hardware configuration. This enables all stations to share the same test plan while managing resources dynamically.

This approach works seamlessly when each station has dedicated instruments. However, challenges arise when stations share an instrument, like the multimeter in our case.

The Challenge:

When stations share an instrument:

  • Each session creates its own instance of the shared instrument.
  • Since these sessions run in separate processes, applying singleton patterns or similar instantiation management methods becomes nearly impossible.
  • Many instruments (e.g., multimeters) can only have a single open connection at a time. Moreover, sending commands concurrently from multiple sources can cause errors or even lead hardware damage (in case of an actuator for example).

Question:

Is there a way to share a resource, such as an instrument, across multiple sessions in OpenTAP? If so, how can this be achieved? I am open to any suggestions, including alternative approaches to implement this test scenario.

Thanks in advance for your insights!

Traditionally this would be handled by “locking” the resource in the VISA session to the instrument. How frequently are you switching over control of the test equipment? Do you plan on the Test Plan owning the instrument for the entire Test Plan, then returning it? Or do you need to lock it for a smaller period of time?

Thanks for the quick reply, @alan_copeland!

In most cases, each test plan run will require access to the shared resource only for specific steps, allowing it to yield control during the rest. However, there are scenarios where a resource will need to remain locked for the entire duration of the test plan run.

Here’s how I would approach implementing this:

  1. Use a system-wide lock to manage access to the shared resource.
  2. Disable the automatic opening and closing of the resource.
  3. For each session:
  • Acquire the lock.
  • Open the resource.
  • Perform the necessary actions.
  • Close the resource.
  • Release the lock.

This approach should be effective, though it does introduce additional complexity to the development of the resource plugin.