Because we are using hardware that is already supported by VMUSBReadout, the only tasks left are to create the daqconfig.tcl and ctlconfig.tcl scripts.
The ctlconfig.tcl script is the configuration file for the slow-controls subsystem. In this situation, it will be an empty file because we are not attempting to use slow-controlled capabilities. We can quickly generate an empty file with the touch program at the command line. Here is how that works.
spdaqXX> touch ctlconfig.tcl
The next step is to build our daqconfig.tcl script. In that file, we will declare the V785, V775, and SIS3820 and add them to stacks. Doing so will cause them to be initialized at the beginning of each run, read out during triggers, and then transitioned back to an inactive mode at the end of each run. The V785 and V775 will be read out using a chained block transfer for each event trigger, and the SIS3820 will be periodically read using an internally generated trigger. We will therefore, need to define two separate stacks.
We will begin with defining the stack that will read out our digitizer. Because this stack will read out the event data, we will refer to it as the "event stack". To begin setting up this stack, we have to first construct the device instances for the V785 and V775. Both of these conveniently share the same Tcl command ensemble, because they are essentially identical pieces of hardware. The command ensemble that create their device instances is called adc. It takes a set of options that are accepted for both V785 and V775 devices and then some more specialized options only valid for either the V785 and V775. The first module we will create is the V785. To do so we add the following lines to our daqconfig.tcl file:
set adcThresh [list 10 10 10 10 10 10 10 10 \ 10 10 10 10 10 10 10 10 \ 10 10 10 10 10 10 10 10 \ 10 10 10 10 10 10 10 10 ] adc create v785 0x11110000 adc config v785 -geo 10 -thresholds $adcThresh
-thresholdoption. Each integer corresponds to the threshold for a channel. The first element of the list corresponds to channel 0 and the last to channel 31. For making our code more organized, we define a variable named adcThresh that will hold the list of 32 integers we created. Note that we created the list using a Tcl list command. This simply just returns a properly formatted Tcl list. The set command assigns the list to the variable.
-geooption which slot it lives in. This value will label the data outputted by the device during each readout cycle. It is important that this corresponds to the correct slot index the card is situated in. We also pass the list wof thresholds to the
-thresholdsoption. The $ syntax dereferences the variable adcThresh and returns the list that it refers to.
Using an an almost identical recipe, we will create a device instance for
the V775. We want to define the time range of the TDC so we will configure
set tdcThresh [list 10 10 10 10 10 10 10 10 \ 10 10 10 10 10 10 10 10 \ 10 10 10 10 10 10 10 10 \ 10 10 10 10 10 10 10 10 ] adc create v775 0x22220000 adc config v775 -geo 11 -thresholds $tdcThresh adc config v775 -timescale 150
We now have two device instances defined in the configuration script. If we wanted to, we could immediately construct a stack using the stack command ensemble and pass our v775 and v785 device instance to it. However, we intend to read out our devices using a chained block transfer technique. A chained block transfer is an optimized means for reading out multiple devices. Instead of having to set up a block transfer from one device and then again from the second device, we can set up one block transfer and that reads out all of the devices in order. This functionality is implemented by the V785 and V775 rather than the VM-USB. To the VM-USB, this is just like a normal block transfer. To set this up in our daqconfig.tcl file we need to use the caenchain command. Here is how we do that:
The caenchain extends the idea of a device instance, because it does not really reflect a piece of hardware. Rather it is more of a virtual piece of hardware that handles the readout of multiple physical pieces of hardware. With it created and configured, we are ready to create our stack and we will only register the chain to the stack. Here is how that works
-triggeroption is passed a value of nim1 to indicate that the stack will be triggered for execution whenever a logic pulse arrives at NIM input 1.
With the event stack already defined, we now turn to the definition of the stack responsible for reading out the SIS3820. Because this stack will deal with scaler data, it will be referred to as the scaler stack. The procedure for setting up the scaler stack is the same as for the event stack. First we create a device instance for the SIS3820 and then we add it to a stack.
The Tcl command ensemble responsible for creating, configuring, and
querying the state of an SIS3820 is named sis3820.
There are two options that can be configured for the device instances it
creates and we will only use the
-base option. This
will take the base address of the actual VME module. When this is added
to a stack, it will cause the VM-USB to read all 32 channels of the
device it is associated with. Let's add the following line to the bottom
of our daqconfig.tcl file:
sis3820 create sclr 0x38000000
The scaler can then be added to a stack later by its name sclr. We will do that right now. Creating the stack for the scaler readout is done as normal using the stack. However, to define this a scaler stack that gets periodically read out we need to specify different values for the options.
-triggerargument. Not only does this enable periodic execution of the stack, but it also labels the stack as index 1. VMUSBReadout will treat the data read by this stack specifically as scaler data and turn it into ring items of type PERIODIC_SCALERS. The
-periodoption was passed a value of 2 to specify that we want the readout period to be 2 seconds.
The scaler stack is now complete.