Skip to content
mvanriet edited this page Nov 25, 2024 · 1 revision

Easy to Use

For the user, it must be easy to connect to an instrument and to use it. It is not necessary to study the architecture of the library first, or to know anything about the communication protocols.

The programming paradigms must be very simple : just creating an object, setting/getting properties en calling methods.

Pythonic API

An instrument may consist of different parts, e.g. an oscilloscope has channels, a trigger, a timebase, ... It is natural to represent each using classes with their own properties and methods.

Instruments are a lot about getting and setting values (voltages, currents, ...). Properties are the most convenient for this.

Common Basic API

Similar instruments have the same API for common functions. E.g. setting a voltage and current on a power supply is the same for all supplies.

More instrument-specific functions are foreseen on an as-needed basis, and will differ between instruments. Consistency will be a 'best effort'.

Easy to Extend

It must be easy to extend the library with a new instrument.

Thread-Safe

It must be safe to use different instruments from different threads, or one instrument from different threads.

Support Configuration Files

This is typically necessary for connection information : what is the serial port or IP-address of the instrument ?

Instead of hardcoding, it must be possible to provide this information in one or more .ini-files. All necessary information can be retrieved automatically from these, without the need for the user to write any code.

GUI-friendly

It is typically also necessary to display the actual value of some instrument settings in a GUI. This must be possible without the need for any user code to keep track of the values or changes thereof.

Clone this wiki locally