Instrument Configuration and Discovery

Problem

#61 Has highlighted that the auto detect mechanism in place can cause some serious issues as random data to unknown ports can be disastrous.

Highlights

• Removing auto detect.
• Change how the instrumentation config is stored
• Creating a tool to create the instrumentation config
• Maintaining or breaking backwards compatibility
• Hooks into Resource Manager

Removing auto detect

Auto detect as it stands for the visa instruments does a *IDN? query to each device found via the PyVisa library. Unfortunately, devices found by PyVisa are not guaranteed to be Visa Compatible and as such may not be safe to write the *IDN? query to. Alternatively, there are some devices such as the SPD3303X which have different line terminators and will not respond to the typical *IDN?/r/n query that most other visa compatible instruments would. There is a place for using some sort of intelligence in working out what instruments are detected and what they are.

Any sort of intelligent detection mechanism should do the following:

• Prioritize searching for instrumentation from the config
• Ensure no data is written to the device before identifying if it is capable of receiving the data safely.

In the case of serial port devices, this would play out by only reading from the config. In the case of USB devices, hints could be derived from the USB identifiers (VISA String, manufacturer id, product etc.)

• Change how the instrumentation config is stored Currently the config is just the response to the *IDN? and the USB identifier. The appropriate driver is then selected based on the *IDN? string (or other identifier) via regex. If we are going to be more configuration based instead of auto detect based then it makes sense to restructure the config to be more explicit and can remove a lot of middle processing to determine the appropriate class for each instrument.

Currently

{
    "INSTRUMENTS": {
        "serial": {},
        "visa": [
            [
                "Siglent Technologies,SPD3303X,SPD3XHBX2R0898,1.01.01.02.05,V3.0",
                "USB0::0x0483::0x7540::SPD3XHBX2R0898::INSTR"
            ],
            [
                "AGILENT TECHNOLOGIES,MSO-X 3014A,MY51360314,02.41.2015102200\n",
                "USB0::0x0957::0x17A8::MY51360314::INSTR"
            ],
            [
                "RIGOL TECHNOLOGIES,DG1022 ,DG1D141401378,,00.03.00.08.00.02.10\n",
                "USB0::0x09C4::0x0400::DG1D141401378::INSTR"
            ],
            [
                "FLUKE,8846A,3553022,08/02/10-11:53\r\n",
                "ASRL52::INSTR"
            ]
        ]
    }
}

I think it should be more like

dmm: # Alias used. Could be anything but keeping consistant 
     # naming conventions means it can be the same in each test script
  cls: fixate.drivers.dmm.fluke_8846a:Fluke8846A # Import line with : for Class to instantiate
  params: # Optional params that are class specific needed for connecting to the resource
    visa_id: ASRL52::INSTR
pps:
  cls: fixate.drivers.pps.siglent_spd_3303x:SPD3303X
  params:
    visa_id: USB0::0x0483::0x7540::SPD3XHBX2R0898::INSTR
dso:
  cls: fixate.drivers.dso.agilent_mso_x:MSO_X_3000
  params:
    visa_id: USB0::0x0957::0x17A8::MY51360314::INSTR
funcgen:
  cls: fixate.drivers.funcgen.rigol_dg1022:RigolDG1022
  params:
    visa_id: USB0::0x09C4::0x0400::DG1D141401378::INSTR

This also gives us the flexibility of using non-fixate drivers just by changing

Creating a tool to create the instrumentation config

As the config won't be generated on first run. A tool to leverage the existing auto detect alongside user prompts to help build out the config. Being able to check the existing devices in config and check they are configured correctly as well as removing or adding entries to the config.

Maintaining or breaking backwards compatibility

This is the hard one. Currently most scripts will use the drivers with

from fixate.drivers import dmm
d = dmm.open()

This did a complex auto detect to determine what DMM drivers were available and what instrument could identify itself as a dmm. Using the alias in the proposed new config could create a new way of accessing the drivers. Eg.

from fixate import drivers
d = drivers.find(alias='dmm')

Backward compatibility could be maintained by each driver just calling the equivalent of the new driver

dmm.py
def open():
   return fixate.drivers.open(alias='dmm')

Hooks into Resource Manager

Consideration should be made with the eventual ResourceManager to be implemented. If we are using aliases then the resource manager could magically know about all the configured equipment. We could do

rm = ResourceManager()
rm.dmm.voltage_ac()

And the resource manager would know where to find the dmm