POL: Hardware and software
Links
Hardware
The VME hardware for the new POL DAQ system is located in a VME crate in a blue rack on the ISAC1 experimental area floor underneath the BNQR platform.
The VME crate contains 3 modules:
Hardware Module ID | Purpose | Base Address |
---|---|---|
VMIC | CPU running linux | |
SIS3820 | MultiChannel Scaler (MCS) | 0x38000000 |
VME-PPG32 | 0x00100000 |
Other DAQ hardware required is the Galil RIO DAC/ADC. The VMIC communicates with this module via a private Ethernet connection.
Hardware Module | Purpose |
---|---|
Galil Rio-47120 16bit | DAC/ADC |
A diagram of the DAQ Hardware setup for the Pol Experiment is shown in Figure 1 below.
- Figure 1
- Diagram of the DAQ Hardware setup for the Pol experiment
Module | Name | I/O | Channel Number(s) | Purpose |
---|---|---|---|---|
SIS3820 | MCS | input | 21-24 | data channels (lemo)) referred to in this document as Scaler Inputs 0,1,2,3 |
input | 1 | control channel (LNE**) connected to PPG Output 1 (MCS Next) | ||
VME PPG-32 | PPG | output | 1 | MCS Next connected to MCS control input 1 |
output | 2 | Cntr Gate debug only | ||
output | 3 | Start TOF to experiment to start the TOF | ||
output | 4 | PPG Running debug only | ||
output | 5-8 | Duplicate of outputs 1-4 respectively for debugging | ||
input | Ext. Trig | External trigger starts PPG |
- ** Load Next Event
VME Crate
Four MCS (Multi-Channel Scaler) channels are enabled referred to in this document as Scaler Inputs 0,1,2,3. Input 1 is currently connected to a pulser to give a constant count. Two PPG Outputs (1 and 3) are used in the experiment (more are programmed but are used for debugging purposes). PPG output 1 (MCS Next) is connected to SIS3820 Input 1 (LNE). The PPG provides the "Load Next Event" pulse for the SIS3820, i.e. it advances the time bins. PPG output 3 (DAQ SVC) produces a pulse at the end of the PPG cycle to start the TOF.
Except for the first PPG cycle at the beginning of each SuperCycle, the PPG is started externally by an input signal from the experiment sent at the end of the TOF to the PPG External Trigger input.
- Note
- The minimum width of the external input "PPG start" signal is 10ns.
Debugging
- PPG output 2 (Cntr Gate) is true while the Scaler is counting (debug only)
- PPG output 4 (PPG Running) is true while the PPG is running. This is the complete PPG cycle length.
outputs 5-8.
Galil Rio 47120 DAC/ADC (16 bits)
Galil Rio Documentation can be found on the galil website. Local copies can be obtained at the links below:
The Galil Rio used by Pol is 16 bit, meaning the LSB is .0003V.
The IP address of the Galil rio device is currently defined as "192.168.1.100" . This value is assigned in the file ~/pol/online/pol/pol_dac.h .
Table 4 shows the channels in the Galil Rio that are
currently used in the Pol Experiment and the typical ranges.
Module | Name | I/O | Channel | Range | Purpose | Connected |
---|---|---|---|---|---|---|
Galil Rio-47120 16bit | DAC | Output | 0 | +/- 10V | DAC Set Value | DAC Readback Value |
Output | 1 | +/-5V | DVM | |||
ADC | Input | 0 | +/- 10V | DAC Readback Value | DAC Set Value | |
1 | +/- 5V | User DAC Readback | HV Monitor | |||
2 | +/- 10V | User Readback | ||||
3 | +/- 10V | User Readback |
The Pol Experiment is presently set up so that the DAC set value is output on Channel 0 of the DAC. This is connected directly to Channel 0 of the ADC to provide a direct readback of the voltage output by the DAC, used by the DAQ frontend software to check that the DAC has changed. It is also connected to the HV power supply to drive the output voltage.
Channel 1 of the ADC is reserved for a user-supplied readback. This is connected to the HV power supply output monitor. This channel has been set to a range of +/-5V to improve the resolution.
The users can connect Channels 2 and 3 of the ADC as required for monitoring purposes. All the channels shown in the table above are read out into the data banks.
The ADC Average values are also sent out in one of the data banks.
DAC and ADC channel and range settings
The DAC and ADC channel numbers and range settings can now be changed by the users, rather than being hard-coded in to the frontend.
These parameters are stored in the ODB as shown below. They can be accessed from the alias button galil-rio on the Pol experiment Status page, or from the link ADC/DAC parameters visible on the pol custom page when the run is stopped.
DAC parameters | ADC parameters |
---|---|
DAC parameters
In the ODB dac params area, the key num channels used gives the number of dac channels used by the frontend (currently 2). The array dac channels lists the channel (output) numbers of the maximum of 2 enabled dac channels, where
- dac channels[0] is the channel number of the DAC output used for stepping in the POL experiment
- dac channels[1] is the channel number of the DAC output used to indicate when the POL DAC step (see above) occurs
For example, if the wiring is changed so that the stepping DAC output is now channel 5, and the indicator is now channel 8, change set dac channels[0]=5
and dac channels[1]=8.
The second (indicator) DAC channel is optional; the experiment can be run with 1 enabled dac channel (i.e. dac channels[0]) if desired.
The range of the DAC outputs is set by the dac range codes set in the dac range array. The meaning of the codes is indicated by the key dac range codes. The code set in dac range[0] refers to the stepping DAC output, and the code in dac range[1] refers to the DAC indicator output.
ADC parameters
The adc params area is similar to the dac params area, except that a maximum of 4 ADC channels are enabled for the POL experiment. Currently these must be the first four adc channels (0-3) if averaged values are to be used. There is no check on this in the frontend.
The adc channels to be used are set in the adc channels array, where adc channels[0] is the channel number of the ADC input used for the direct monitoring of the DAC output used for stepping, i.e. connected to the DAC output given by dac channels[0] adc channels[1] is the channel number of the ADC input used for the users' monitoring of the HV power supply used for stepping adc channels[2] and [3] are
the two channels used for users' input as required.
The range of the ADC outputs is set by the adc range codes set in the adc range array. The meaning of the codes is indicated by the key adc range codes. Note that the codes for adc and dac are not the same. For example, the code set in adc range[0] refers to the ADC direct monitor output, and the code in adc range[1] refers to the users' ADC monitor channel.
There is no check that the ADC channel values are unique. This feature can be used for test purposes.
ADC Averaging program
A program has been downloaded into the Galil Rio to perform averaging of the first 4 ADC channels (0-3). A copy of this program can be found in Appendix 1. It takes parameters Filter Window (W) in volts and Filter Factor (F) (both arrays). Default values are F[*]=100 W[*]=0.1 volts. The Filter Window and Factor values for each channel have been stored in the ODB so they can be easily changed. They can be accessed from the alias button galil-rio on the Status page, or from the link ADC/DAC parameters visible on the pol custom page when the run is stopped.
The program continually averages the ADC input values. If the difference between the average value and the latest readback is greater than W[i] for that channel i, the average is cleared and a new average calculated. This can be used to detect the DAC having stepped. The Filter Factor F is used tostart a new average after a certain number of readings.
These values for the 4 supported ADC channels can now be set in the
ODB (see below). They are available through the button
galil-rio on the Status page,
or from the link ADC/DAC
parameters on the POL custom page (visible when the
run is stopped).
Figure 3: ODB Parameters for adc averaging program
Software
Figure 4 is a diagram (not to scale) of the DAQ system show the PPG SuperCycle
(controlled in hardware by the PPG) followed by the Data Readout (done in software by the frontend program
pol_fevme.cxx ).
- Figure 4
- Diagram of PPG super-cycle and readout for Pol experiment
How the Frontend Program Works
The Frontend program pol_fevme.cxx controls the DAQ hardware in the VME crate and sends out the data in the form of MIDAS-format data banks. (See POL frontend code for location of code, and how to build the frontend).
At the beginning of run, the hardware is initialized and set up. The PPG program is downloaded into the PPG, with the input parameters input parameters e.g. number of bins per cycle, DAC sleep time, etc. set to the initial user-defined values. When the PPG is started, the PPG program will run for one PPG cycle, then stop. During the PPG cycle, the PPG outputs the desired number and sequence of pulses. A SuperCycle is the number of PPG cycles run with the DAC voltage constant. It may be one or more PPG cycles. After each SuperCycle is complete, the DAC voltage is stepped. At the beginning of each SuperCycle, the PPG is started by software.
During a PPG cycle, outputs the user-selected number of bins per cycle pulses as the PPG MCS_Next output signal. This signal is connected to the MultiChannel Scaler (MCS) LNE (Load Next Event) Input. The MCS has a register that is pre-loaded at beginning-of-run with the number of LNE (Load Next Event) pulses it must receive for one complete SuperCycle, i.e. Number of cycles per SuperCycle * Number of bins per cycle. These are both input parameters.
Once armed, the MCS will count data in each bin until the LNE signal causes it to move to the next bin. The MCS has an internal buffer in which it stores the data. The PPG will stop after it has completed the cycle, i.e. it has output the number of bins per cycle pulses and the Start TOF signal. At this point, during the TOF (time of flight), the PPG signal counter gate may be used to inhibit counting, otherwise the MCS will continue to count data in a single bin, since no LNE signal will be received until the next PPG cycle. In any case, the data from the first cycle and the first bin will be discarded. Once the TOF is complete, the PPG will be restarted by the external signal End of TOF, and will produce another sequence of pulses. The MCS will start counting real data into its bins. This process will be repeated until the MCS has received the expected number of LNEs preloaded in the register. The MCS ignores any more LNE signals until it is re-armed. At this point, the SuperCycle is complete and the data from the MCS can be read out.
While the SuperCycle is in progress, the frontend program pol_fevme.cxx monitors the MCS data buffer. It will read out the buffer to prevent overflow (the pol experiment does not usually have enough data for this to be needed). This task is performed by the software equipment "VME". The frontend program also determines whether the SuperCycle is ended by polling on a register in the MCS that counts the number of LNE that it has received. This task is performed by the software equipment "POL_ACQ".
Once the SuperCycle is ended, the frontend program increments
the DAC voltage. The software equipment "VME" reads out or flushes the last of the
data from the MCS buffer. This data is for the whole SuperCycle. If
enabled, it sends this raw data out as the Event 11 data bank
"MCS0" (debug mode). The equipment "HISTO" then decodes this
data into individual cycles. The MCS time bin data for all cycles
for the SuperCycle are added together to form the histograms.
At this point, the hardware is restarted for the next SuperCycle,
i.e the Scaler is re-armed, the external PPG start is enabled, and
the next SuperCycle is started by starting the PPG internally (by
software). Meanwhile, the histogram data is sent out as Event
5 data banks. Sometime later, the software equipment "INFO" runs, sending out various
statistical data as Event 3 data banks, and also updating the ODB.
Stepping the DAC
The Galil Rio DAC used by the POL experiment is 16 bit, meaning the LSB is 0.0003 V for a DAC range of +/- 10Volts. The frontend code pol_fevme.cxx checks that the Galil Rio is responding when the code is first run (in subroutine frontend_init) by setting the DAC to a value of 2.5 Volts, then checking that the difference between the set value and readback is less than 0.05V.
When the DAC is stepped during a run (unless the check on the DAC step is disabled), a more sophisticated test is performed (in subroutine incr_DAC) to verify that the DAC has changed, using the following algorithm:
set_diff = fabs(dac_val - prev_dac_val); // difference between the present and previous DAC Set values read_diff= fabs(dac_read - prev_dac_read); // difference between the present and previous DAC Readback values fdiff = fabs (set_diff - read_diff); // difference between the two // Check that DAC has changed if ( fdiff > fabs(ps.input.dac.jitter__v_) * 5 ) // jitter is usually set to the LSB of the DAC return (error);
Running the experiment (Real Data)
To change the input parameters, see Running the Pol Experiment.
- When running with real data, the following input parameters should be set as indicated:
- the first cycle of each SuperCycle should be discarded. The first TOF is started at the end of the PPG Cycle, so the data from every first cycle will not be valid.
- the first bin of every cycle should be discarded. If the data inhibit signal is not connected to the Scaler, this bin will have been gathering data (noise) during the time the PPG is stopped between each cycle. Otherwise it will read zero.
- External PPG start must be enabled
For maximum speed
- set DAC sleep time to zero. The Galil RIO DAC changes very quickly. It is stepped during the data readout (by software), and the first cycle of each supercycle is invalid. This gives it plenty of time to change.
- set TOF signal width to zero. The TOF start only needs an edge, and the PPG should stop as soon as possible.
this PPG is 30ns (3 clock cycles), so setting pulse widths and delays to zero actually gives 30ns.
The Galil RIO DAC responds so quickly that the "DAC sleep
time" parameter can be set to zero, setting the delay to the minimum
of 30ns (3 PPG clock cycles). The "Start TOF" signal width can also
be set to zero (i.e. 30ns). After sending the "Start TOF" signal,
the PPG stops running. It will now respond to the next "PPG start"
signal at the end of the TOF. External "PPG Start" signals that
occur when the PPG is still running are ignored, hence the "Start
TOF" signal width should be kept as short as possible.
The parameters in the information box should be set as indicated:
- Alarm system enabled TRUE
- Disable DAC Step checks FALSE
- DAC jitter (V) 0.005 (0.0003) DAC LSB (see above)
- DAC Minimum increment (V) should be set to > DAC jitter
When running with very small DAC Increments or for testing, Disable DAC Steps check can be turned off. This bypasses the DAC step check algorithm and the check on the minimum step size.
Testing the DAQ
For testing the DAQ, the TOF mechanism can be bypassed. The PPG is triggered internally (i.e. by a VME command) on each cycle (i.e. not just the initial cycle in each SuperCycle). In order to do this
- Change the input parameter PPG external clock from "n" to "y"
NOTE: remember to set this parameter back to external clock when finished testing.
When running in test mode, i.e. no TOF, the PPG is run with internal
start. In this case, the End TOF signal does nothing. The PPG
is restarted internally when the PPG stops at the end of each cycle,
until the SuperCycle is completed.
Timing tests of the software can be done more easily in this mode, where the uncertainty of the TOF is removed temporarily.
Experimental setup
The name of the MIDAS experiment is "pol" and it is currently run from isdaq01. Relevant Environment variables are set up as follows:
MIDASSYS=/home/pol/packages/midas MIDAS_EXPTAB=/home/pol/online/pol/exptab MIDAS_EXPT_NAME=pol MIDAS_PHYSICS_EVID=-1 MIDAS_EVENT_MODE=2 MIDAS_TRIGGER_MASK=-1 HOSTNAME=isdaq01.triumf.ca DAQ_HOST=isdaq01 VMIC_HOST=lxpol
The experimental clients are run on the host machine isdaq01 except for the frontend code pol_fevme.exe which is run on the VMIC lxpol in POL's VME crate. lxpol has access to the directory /home/pol/online/pol.
Building the POL Frontend
The code for the POL frontend is in the directory /home/pol/online/pol on the isdaq cluster.
The frontend code should be built when logged on to lxpol (not isdaq01) since the system architecture is different (32-bit on lxpol, 64-bit on isdaq01). 32-bit MIDAS libraries are built on isdaq01 for this purpose. All other clients are built on isdaq01.
The Makefile in this directory will build the frontend code pol_fevme.exe. It links in the PPG, SIS3820 and Galil Rio driver code.
To build frontend pol_fevme.exe
Log onto lxpol as pol, then
[pol@lxpol pol]$ cd ~/online/pol/
- NOTE
The frontend is built with experim.h saved from the pol experiment's ODB using the odbedit "make" command (see experim.h for more information). experim.h contains the C-structure of parts of the ODB to allow ODB data to be easily accessed by the C-code. In particular, this means that when adding or removing new values in the ODB under /Equipment/pol_acq/settings a new experim.h must be generated in this directory ( ~pol/online/pol) , and the frontend must be rebuilt.
To generate a new experim.h
[pol@lxpol pol]$ odb [local:pol:S] make [local:pol:S] exit
To rebuild the frontend code :
[pol@lxpol pol]$ make clean [pol@lxpol pol]$ make
This builds the frontend pol_fevme.exe.
Scripts
start-all
start-all is an alias to the script "/home/pol/online/pol/bin/start-daq-tasks". This script will start the various clients for the experiment, including the Midas web browser client mhttpd on port 8088. The experiment is controlled through the Midas web browser (see Main Status page).
start-all will also start the frontend program running in a pop-up window (see Figure 1 below).
- NOTE
- If this is not successful, or the frontend window immediately
disappears, there may be hardware issues. See #Troubleshooting">troubleshooting.
start-all can be run at any
time during the experiment, and will restart any of the clients if
they have died. Clients can also be restarted using the
mhttpd programs page.
show-windows
A script show-windows run on any terminal (logged in as pol to isdaq01) will display the frontend window. An alias show-fe has been set up to run show-windows.
Appendix 1: Averaging Program
This program by Donald Arseneau is downloaded in the Galil Rio module and performs averaging. It can also be found at
~pol/online/rio/POL.dmc.
REM Galil RIO used for ADC and DAC and digital IO by POL REM Version 1.01 20-Jun-2014 REM REM variables: REM AV[] filtered voltage readings REM F[] Filter number or factor (Set like F[0]=30) REM W[] Filtering window in volts. REM REM Query a filtered reading with "MG AV[i]" REM Query all four with "MG AV[0],AV[1],AV[2],AV[3]" REM ------------------------------ REM Automatic initialization. REM ------------------------------ #AUTO REM ------------------------------ REM Device configuration: REM Digital outputs logic-normal REM Analog inputs 0-3 range +-10V REM Analog outputs 0-3 range +-10V REM ------------------------------ IQ65535 AQ0,2;AQ1,2;AQ2,2;AQ3,2 DQ0,4;DQ1,4;DQ2,4;DQ3,4 REM ------------------------------ REM Set up filtering for readbacks. REM DFloop runs in thread 3 REM Default filter factor 50, REM Default filtering window 0.1V REM ------------------------------ DM F[8];DM W[8];DM AV[8] F[0]=50;F[1]=50 F[2]=50;F[3]=50 W[0]=0.1;W[1]=0.1 W[2]=0.1;W[3]=0.1 I=0 #IDF AV[I]=@AN[I];W[I]=1.0;F[I]=100;I=I+1 JP#IDF,I<8 XQ#DFloop,3 EN REM ------------------------------ REM The digital filter for analog inputs 0-4 REM AV[] The averaged voltages REM F[] The filter number REM W[] The window (volts) REM Query filtered readings with "MG AV[i]" REM ------------------------------ #DFloop I=0 #DFch IF(F[I]<1);F[I]=1;ENDIF VI=@AN[I];FI=F[I] IF(@ABS[(VI-AV[I])]>W[I]);FI=1;ENDIF AV[I]=AV[I]*(FI-1)/FI+(VI/FI) I=I+1 JP#DFch,I<4 JP#DFloop EN REM 56789 123456789 123456789 123456789