Basic Concepts

slave uses three layers of abstraction. The transport layer resides at the lowest level. It’s responsibility is sending and receiving raw bytes. It has no knowledge of their meaning. The protocol layer on the next higher level is responsible for creating and parsing messages. The driver layer is at the highest level. It knows which commands are supported and maps them to python representations.

Transport Layer

The slave.transport module implements the lowest level abstraction layer of the slave library.

The transport is responsible for sending and receiving raw bytes. It interfaces with the hardware, but has no knowledge of the semantic meaning of the transfered bytes.

The Transport class defines a common api used in higher abstraction layers. Custom transports should subclass slave.Transport and implement the __read__() and __write__() methods.

The following transports are already available:

  • Serial - A wrapper of the pyserial library
  • Socket - A wrapper around the standard socket library.
  • LinuxGpib - A wrapper of the linux-gpib library
  • Visa - A wrapper of the pyvisa library. (Supports pyvisa 1.4 - 1.5).

Protocol Layer

The slave.protocol module implements the intermediate abstraction layer of the slave library.

The protocol knows how to create command messages and how to parse responses. It has no knowledge of which commands are actually supported by the device and does not care what kind of connection (e.g. ethernet, gpib, serial, ...) is used to communicate with the device.

The common protocol api is defined by the slave.Protocol class. Custom protocols must implement the query() and write() methods.

The following protocols are already implemented and ready to use:

Driver Layer

The core module contains several helper classes to ease instrument control.

Implementing an instrument interface is pretty straight forward. A simple implementation might look like:

from slave.driver import Driver, Command
from slave.types import Integer

class MyInstrument(Driver):
    def __init__(self, transport):
        super(MyInstrument, self).__init__(transport)
        # A simple query and writeable command, which takes and writes an
        # Integer.
        self.my_cmd = Command('QRY?', 'WRT', Integer)
        # A query and writeable command that converts a string parameter to
        # int and vice versa.
        self.my_cmd2 = Command('QRY2?', 'WRT2', Enum('first', 'second'))

IEC60488 Compliant Drivers

The slave.iec60488 module implements a IEC 60488-2:2004(E) compliant interface.

The IEC 60488-2 describes a standard digital interface for programmable instrumentation. It is used by devices connected via the IEEE 488.1 bus, commonly known as GPIB. It is an adoption of the IEEE std. 488.2-1992 standard.

The IEC 60488-2 requires the existence of several commands which are logically grouped.

Reporting Commands
  • *CLS - Clears the data status structure [1] .
  • *ESE - Write the event status enable register [2] .
  • *ESE? - Query the event status enable register [3] .
  • *ESR? - Query the standard event status register [4] .
  • *SRE - Write the status enable register [5] .
  • *SRE? - Query the status enable register [6] .
  • *STB - Query the status register [7] .
Internal operation commands
  • *IDN? - Identification query [8] .
  • *RST - Perform a device reset [9] .
  • *TST? - Perform internal self-test [10] .
Synchronization commands
  • *OPC - Set operation complete flag high [11] .
  • *OPC? - Query operation complete flag [12] .
  • *WAI - Wait to continue [13] .

To ease development, these are implemented in the IEC60488 base class. To implement a IEC 60488-2 compliant device driver, you only have to subclass it and implement the device specific commands, e.g:

from slave.driver import Command
from slave.iec60488 import IEC60488

class CustomDevice(IEC60488):

Optional Commands

Despite the required commands, there are several optional command groups defined. The standard requires that if one command is used, it’s complete group must be implemented. These are

Power on common commands
  • *PSC - Set the power-on status clear bit [14] .
  • *PSC? - Query the power-on status clear bit [15] .
Parallel poll common commands
  • *IST? - Query the individual status message bit [16] .
  • *PRE - Set the parallel poll enable register [17] .
  • *PRE? - Query the parallel poll enable register [18] .
Resource description common commands
  • *RDT - Store the resource description in the device [19] .
  • *RDT? - Query the stored resource description [20] .
Protected user data commands
  • *PUD - Store protected user data in the device [21] .
  • *PUD? - Query the protected user data [22] .
Calibration command
  • *CAL? - Perform internal self calibration [23] .
Trigger command
  • *TRG - Execute trigger command [24] .
Trigger macro commands
  • *DDT - Define device trigger [25] .
  • *DDT? - Define device trigger query [26] .
Macro Commands
  • *DMC - Define device trigger [27] .
  • *EMC - Define device trigger query [28] .
  • *EMC? - Define device trigger [29] .
  • *GMC? - Define device trigger query [30] .
  • *LMC? - Define device trigger [31] .
  • *PMC - Define device trigger query [32] .
Option Identification command
  • *OPT? - Option identification query [33] .
Stored settings commands
  • *RCL - Restore device settings from local memory [34] .
  • *SAV - Store current settings of the device in local memory [35] .
Learn command
  • *LRN? - Learn device setup query [36] .
System configuration commands
  • *AAD - Accept address command [37] .
  • *DLF - Disable listener function command [38] .
Passing control command
  • *PCB - Pass control back [39] .

The optional command groups are implemented as Mix-in classes. A device supporting required IEC 60488-2 commands as well as the optional Power-on commands is implemented as follows:

from slave.driver import Command
from slave.iec60488 import IEC60488, PowerOn

class CustomDevice(IEC60488, PowerOn):


[1]IEC 60488-2:2004(E) section 10.3
[2]IEC 60488-2:2004(E) section 10.10
[3]IEC 60488-2:2004(E) section 10.11
[4]IEC 60488-2:2004(E) section 10.12
[5]IEC 60488-2:2004(E) section 10.34
[6]IEC 60488-2:2004(E) section 10.35
[7]IEC 60488-2:2004(E) section 10.36
[8]IEC 60488-2:2004(E) section 10.14
[9]IEC 60488-2:2004(E) section 10.32
[10]IEC 60488-2:2004(E) section 10.38
[11]IEC 60488-2:2004(E) section 10.18
[12]IEC 60488-2:2004(E) section 10.19
[13]IEC 60488-2:2004(E) section 10.39
[14]IEC 60488-2:2004(E) section 10.25
[15]IEC 60488-2:2004(E) section 10.26
[16]IEC 60488-2:2004(E) section 10.15
[17]IEC 60488-2:2004(E) section 10.23
[18]IEC 60488-2:2004(E) section 10.24
[19]IEC 60488-2:2004(E) section 10.30
[20]IEC 60488-2:2004(E) section 10.31
[21]IEC 60488-2:2004(E) section 10.27
[22]IEC 60488-2:2004(E) section 10.28
[23]IEC 60488-2:2004(E) section 10.2
[24]IEC 60488-2:2004(E) section 10.37
[25]IEC 60488-2:2004(E) section 10.4
[26]IEC 60488-2:2004(E) section 10.5
[27]IEC 60488-2:2004(E) section 10.7
[28]IEC 60488-2:2004(E) section 10.8
[29]IEC 60488-2:2004(E) section 10.9
[30]IEC 60488-2:2004(E) section 10.13
[31]IEC 60488-2:2004(E) section 10.16
[32]IEC 60488-2:2004(E) section 10.22
[33]IEC 60488-2:2004(E) section 10.20
[34]IEC 60488-2:2004(E) section 10.29
[35]IEC 60488-2:2004(E) section 10.33
[36]IEC 60488-2:2004(E) section 10.17
[37]IEC 60488-2:2004(E) section 10.1
[38]IEC 60488-2:2004(E) section 10.6
[39]IEC 60488-2:2004(E) section 10.21