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 level handle the formatting of messages and answers

• 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
• Drivers may be written in a single 'flat' module 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)

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