Instrument drivers

This page is dedicated to listing the requirement of an ideal driver library. All person contributing should tag their proposal with their github pseudo. For the time being, I (MatthieuDartiailh) have no idea about how to organize the suggestions for the time being they will just listed, we will re-organize them later on :

Without making any assumption about the final name, implementation or existence, here are some definitions so that we can understand each others:

• an instrument property is referred to as a feature.
• the transport layer takes care of the low level communication (reading, writing bytes)
• the protocol layer handle the formatting of messages and answers
• a channel refers to a logical or physical part of an instrument which has an id use to route commands to it. The term is used by extension for how we implement it in the driver.
• a subsystem is a kind of subdriver which can be a way to get a hierarchical structure in a driver.

#Ideas :

• The library should support all kind of communications (not only text based). So far, the supported methods should be : @MatthieuDartiailh
  • text based (relying on VISA or not, and I mean the standard not the dll)
  • registry based (even if for those ones features might make less sense)
  • relying on a vendor dll
  • relying on the COM protocol
• All the features values should be cached to avoid useless communication. @MatthieuDartiailh
• Setting a feature should invalidate the cache of affected features. @MatthieuDartiailh
• To avoid cache corruption, a single driver should exists per instrument. @MatthieuDartiailh
• Communication failures (unexpected timeout) should lead to a new attempt as some instruments are dumb. This behavior should be optional. @MatthieuDartiailh
• Features should support a large range of possible validation methods (list of values, range, automatic conversion between user meaningful values and instrument values). @MatthieuDartiailh
• Features should support units. @MatthieuDartiailh (Pint is a nice way to do that)
• Use of units should be enabled/disabled through a configuration parameter. @alexforencich
• Features should be easy to customize we can't possibly cover all corners cases. @MatthieuDartiailh

##Driver organisation :

• Drivers must support a hierarchical structure and multiple channels (corresponding either to the internal behavior of the instrument, or to the fact that it is indeed composed of different cards or components). This is not trivial for non-text based instruments. @MatthieuDartiailh
• An array like container storing channel and supporting iteration would be nice. @MatthieuDartiailh
• Drivers may be written in a single 'flat' class for simpler inheritance and ease of extending for related instruments, but still provide a hierarchical interface. @alexforencich (using something similar to python-ivi's PropertyCollection and IndexedPropertyCollection)
• This might not always be possible for drivers needing channels because they are made of multiple cards (I have one use case in which the card to talk to must be selected before sending any order so I need a way to customize how the channel interact with the base driver). But we should provide a way to easily customize the channel when subclassing the driver. @MatthieuDartiailh

##Driver inheritance :

• Base driver should be able to be composed to avoid too much code duplication. @MatthieuDartiailh
• Interface and implementation should be separable to encourage uniformity among similar instruments. @alexforencich (similar to python-ivi's base classes)

##Communications :

• As far as possible communication should be delegated to existing libraries to avoid re-inventing the wheel. @MatthieuDartiailh (I think Pyvisa with its multiple backends would be a nice choice).
• Separate transport and protocol layers to reduce duplication. @alexforencich (similar to slave)
  • Not sure what sense protocol makes for non-message based drivers @MatthieuDartiailh