The software structure is setup to mimic the hardware setup: each class in the software represents a module in the hardware. For example: the
D5a_module class and the
S4g_module class. The only exception to this is the
SPI_rack class. This class handles the communication with the rack. It can be seen as the representation of the controller module (C1/C1b). All modules in a rack communicate via the one controller. This is the same for the software: all the instantiated classes communicate via a
SPI_rack instantiation. The image below shows this in a block diagram:
As each SPI Rack can only have one controller, there is also only one
SPI_rack object per physical SPI Rack. You can have multiple SPI Racks connected to the same PC using multiple
SPI_rack objects. Each SPI Rack can have only one open connection (instantiation) on a PC. So to use the same SPI Rack in multiple measurements it either has to be a shared instance, or it has to be closed and opened again when necessary.
SPI_rack class is setup to accommodate for threading using the parameter
use_locks=True. This allows the user to setup threads using the module classes and not having to worry about simultaneous access to the connection.
Each module class represents a module type and, as explained above, communicates through a
SPI_rack object. This object needs to be passed as an argument to the module at instantiation of the module. The other crucial parameter is the module address. Each physical module has to have a unique module address in the rack. This address can be set by DIP switches inside the module. At initialization this address needs to set as a parameter.
For example: lets say that we want to initialize the SPI Rack at COM Port 4 with a timeout of 1 second and a D5a module at module address 3. We would have to do the following:
spi = SPI_rack("COM4", baud=9600, timeout=1) spi.unlock() D5a = D5a_module(spi, module=2)
For an explanation of the
SPI_rack parameters (baud, timeout and unlock), check the SPI_rack Class page.