Resource Driver Manager Ideas

This is a brain dump of various thoughts around the concept of a driver manager.

Why do we want a uniform driver/resource manager?

• So at the sequence level we can log what equipment was used for a given invocation of a test script
• So intialisation and retry logic can be driven by the sequencer. Largely, we want scripts to be robust without having to deal with resource cleanup/initialisation in scripts.

Things that are related to this general concept:

• API for each instrument type
• How to declare what resources/instruments are needed in a script?
• How to define what resources/instruments are installed on a computer?
• How to override and extend the 'fixed' resource/instrument definition?

Should the driver try to specify the specific API for a given instrument? Ideally, if a consistent API is used, it will help instruments be interchangeable. IVI is a potential choice. If we don't use IVI, then we should do something that is equivalent. However, it's not really Fixate's job to dictate APIs for the whole spectrum of different instruments that exist. As consumers of the Fixate API and writers of scripts across many jigs/instruments, we want to uses consistent driver APIs in our scripts.

(work related) For existing test scripts, keep the existing driver and deprecate them. Or move to the IVI API and write wrappers that emulate the old API.

(most?) Drivers don't belong in fixate! Even if fixate provides some drivers built in, it should be simple to incorporate external drivers into a test script, while taking advantage of the logging/initialisation management that we want the resource manager to provide.

The easier it is to get a basic script working, the better.

We need to be able to connect arbitrary interface to a resource (a.k.a. instrument driver) to the sequencer. The resource will need to implement an minimum FixateDriver interface to the FixateDriverManager. (open, close, name, serial_number, cal_data, capabilities)

Because there are physical connection between resources and other equipment, the specific resource must be referenced. (e.g. even if there are two power supplies with the same capabilities, they can't be use interchangeably, because they are probably connected to different things)

How to 'connect' external code so that a 'driver manager' (or the sequencer) knows about it.

We want scripts to be specific about an instrument that is connected, but only (optionally) specific about the particular instrument.

For a measurement instrument, we should be able to interchange instruments with equivalent capability. (fluke 8846 & keysight 34401). At least, assuming the base driver we have available follows a compatible API.

For jigs, there is there is no interchangeable equivalent. If we need JIG1234, it must be JIG1234.

There most likely need to be some global config for "these instruments are connected to fixate on this computer". This unravels the visa resource/IP address/com port/etc addressing to the naming scheme used in the fixate driver manager. (At the moment, this is via the auto detect on driver import, which creates a local config cache of instruments discovered)

In test scripts, we shouldn't have to know/specify how to find an instrument. But we might need to specify how to find resource that is specific to that script.

Two resource types: Those related to a particular script and those related to the (fixed) installation. Note that for different users of fixate, that boundary might change. e.g. our work test bay will typically have core instruments specific to the fixate script, but jigs specific to the script. For fixed test stations (i.e. dedicated to one product) you could probably do it either way.

There is some overlap. We might make a script specific driver, than composes or extends an existing driver. (e.g switching jigs typically use ftdi to interface to relays, but we want to treat the jig definition as a driver)