This EPICS driver supports the use of the PicoQuant PicoHarp 300 for fill pattern measurement.
To build this support module edit configure/RELEASE for the following dependencies:
You will need to ensure that the PicoHarp 300 instrument is configured for remote USB operation, this is a separately purchased option. You will also need to configure your target system so that when the PicoHarp is connected its USB device nodes are user writeable: the corresponding USB id is 0e0d:0003.
The makefile for this module expects to find the three header files errorcodes.h, phdefin.h, and phlib.h in the directory $(PHLIB)/include and expects to find phlib.so with the name libphlib.so in $(PHLIB)/lib. I suggest that this library be installed manually in a suitable directory, and that you don't attempt to run the install script provided with the library.
The docs/example_ioc directory contains a simple IOC which implements support for a single PicoHarp. Creating the IOC is automated through the IOC_Builder [4] tool, but unfortunately this has too many Diamond specific dependencies for practical use elsewhere.
To configure a PicoHarp we must first perform some calculations. The two basic parameters are the bunch number (called buckets in the code) and the machine revolution frequency. At Diamond we have:
From these numbers we need to compute the following three numbers to configure the driver:
bin_size | Control parameter (in range 0 to 7), determines PicoHarp sample size in nanseconds via equation:
\begin{equation*}
sample\_time = 4 \times 2^{bin\_size} \,\text{ps}
\end{equation*}
Compute this as the smallest number in the range 0 to 7 such that \(valid\_samples < 65536\) . |
valid_samples | Number of valid samples, must be no more than 65536, determined from bin_size as:
\begin{equation*}
\frac{10^{12}}{f_{rev} \times sample\_time}
\end{equation*}
|
samples_per_bucket | Lower bound on valid samples per machine bunch, computed as
\begin{equation*}
\lfloor{valid\_samples / buckets}\rfloor
\end{equation*}
|
From these values the startup script and substitution file can now be computed.
The following calls must be made before iocInit:
This takes the following 9 arguments, which we have just determined:
asyn_port | This is an arbitrary string used internally to identify PicoHarp instance: a single IOC can operate multiple PicoHarps if ports are assigned. |
serial_string | The serial code printed out by scanPicoDevices for the PicoHarp of interest should be passed here as a string. |
event_fast, event_5s | The driver uses two EPICS event codes internally, they must be unique to each PicoHarp instance. Event codes 100 and 101 seem to work ok. |
buckets | Number of bunches in the ring. |
bin_size | Number in range 0 to 7 corresponding to selected bin size, computed above |
valid_samples | Number of samples used for fill pattern measurement, computed above |
samples_per_bucket | Samples per bucket as computed above. |
f_rev | Machine revolution frequency in Hz. |
One substitution instance for db/picoharp.db must be made for each PicoHarp controlled by this IOC. Note that the array sizes in the substitutions must be correct as otherwise a segmentation fault is quite likely to occur!
Instantiate with the following parameters:
DEVICE | Prefix used to name the PicoHarp instance. Should be the same for all substitution instances for a single PicoHarp. |
PORT | This must be identical to the asyn_port parameter passed to initPicoAsyn. |
CURRENT | This should name an EPICS PV which provides an and up to date reading of the machine beam current in mA. This will be used to scale the computed fill pattern. |
EVENT_FAST | The event_fast value passed to initPicoAsyn |
EVENT_5S | The event_5s value passed to initPicoAsyn |
BUCKETS | Must be buckets, ie number of bunches per turn. |
BUCKETS_1 | Must be buckets-1. |
PROFILE | Must be samples_per_bucket. |
The directory opi/sr contains three EDM screens which can be used to control and view the fill pattern computed by the PicoHarp. The top level screen is fill.edl, with fillconfig.edl used to edit configuration settings and fillwf.edl to provide a view on the raw PicoHarp data.
The PVs provided by the PicoHarp are documented below. All of the PVs have names of the form device:pv where device is the DEVICE name configured in the database instance. In the documentation below the device: part is omitted from each name.
The following PVs are used to control the PicoHarp configuration.
This needs to be left at the bin_size parameter determined above. This can be changed in order to capture raw data with differing PicoHarp bin sizes, but the computed fill pattern will be wrong.
The picoharp bin size is equal to \(4\times2^{RANGE}\) ps.
All of the PVs listed here have names of the form device:pv_rate where rate is one of FAST, 5, 60, 180, or ALL. The PVs with a named rate represent a rolling history as follows:
FAST | PVs with this suffix update at the rate determined by the TIME PV. This should be set to an integral fraction of 5 seconds. |
5, 60, 180 | These PVs update at 5 second intervals and deliver data integrated over the corresponding number of seconds. |
ALL | These PVs also update at 5 seconds, delivering data integrated since the PV RESET_ACCUM was last processed. |
This waveform shows the pattern of PicoHarp bins within a single bunch, averaged over the entire fill. The peak of the bunch should be centred, as bucket measurement will only occur within this region.
If possible fine tuning of the PicoHarp trigger should be done to keep the centre of this profile away from the edges.
[1] | http://www.picoquant.com/products/category/tcspc-and-time-tagging-modules/picoharp-300-stand-alone-tcspc-module-with-usb-interface |
[2] | http://www.picoquant.com/dl_software/PicoHarp300/PicoHarp300_SW_and_DLL_v3_0_0_1.zip |
[3] | http://controls.diamond.ac.uk/downloads/python/epicsdbbuilder/ |
[4] | http://controls.diamond.ac.uk/downloads/python/iocbuilder/ |