The harp device can be seen in Figure 4.3, the 2 wires supported by the harp can go into the beam under the action of a stepper motor. Then the wires cross a beam section, and the counting rates in PMTs around the beam line increase.
The software implementation requires a communication between the Harp application and the Scaler application. Fortunately, under EPICS, a SNL program can transparently access any database on the local network (in the present case, both application are running in the same IOC).
There are several subroutines involved in the generation of a beam scan, the heart of the program is very simple by itself.
Let's imagine that the harp is moving into the beam, and the scan initializations have been done. We are in a routine that looks like the following :
Several things have to be said on this quite simple routine. First, the Harp never stops during the scan so that the scan can be more homogeneous. This means that the acquisition time has to be carefully chosen. Actual values selected are, Motor Speed = 1000 steps/sec (it is 1.27mm per second for the Harp), Number of steps between scans = 100 (so one scan every tenth of a second) and the time of acquisition for the scaler is set to 0.07 s. There is 3.10-2 seconds for the IOC to recover (that is storing the data, completing the loop, reseting the scaler...) between each scan. It seems to be the best reachable value. To have a more precise scan, one has to decrease the motor speed. All these values are the one displayed on the scan window of the Harp and converter GUI.
A chronogram (figure 5.1) shows a little bit better how it happens, and where the uncertainties are. If we have allowed enough dead time, then we are sure that there will be a scan of a very precise duration between each theoretical scan position (that is each 100 steps in our case), but we cannot know for sure where it will exactly be in this interval.
The values we got are not sent to any UNIX client by the standard channel access procedure. This is because it is too fast for it, and we found an alternative to storing the array locally and then sending it over the network 13. The retrieved data are directly written on the UNIX disk using the standard C file handling routines, that VxWorks does have in it's C standard Library. This is fast and transparently bufferised by the file manager. More, we automatically get a file on each scan, and the achieving of scans is then easier.
The created file has a very simple structure, shown on the excerpt 5.1. It is logically divided in lines, one line per acquisition. the first number is the position of the harp at the time of writing. This give an easy way to check that we already have a scan each 100 steps, for example. If the dead time was inadequately chosen, we could miss scans. The next 16 numbers are scaler channels. The first one is the clock and also gives us a check. If the dead time was wrong, the clock wouldn't have counted up to 700000 (0.07 seconds) and the number would be incorrect. Then the scaler counting data are represented.
This file is the analyzed by several Perl and tcl/tk scripts (a sample of the the tcl/tk output is on Figure 5.2) to give the user a feedback of the profile and position of the beam scans. These scripts have been written by Arne Freyberger.
The EPICS application scaler (Section 4.4) monitors 15 analog inputs. The current configuration is :
We are interested in the beam counters, and for the scans, the upstream counters are usually far better as they are closer to the Harp (see Figure 2.9).
