Skip to content
Matthieu Dartiailh edited this page Feb 8, 2015 · 9 revisions

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 or implementation, an instrument property will be referred to as a feature.

  • 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)
  • Features should be easy to customize we can't possibly cover all corners cases. @MatthieuDartiailh
  • 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
  • Base driver should be able to be composed to avoid too much code duplication. @MatthieuDartiailh
  • 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).
Clone this wiki locally