In the IOC, the application program is made of several layers (Figure 3.1), the record put itself between the outside world (through channel access) and the hardware level (device support). Many records are already made, ready to be implemented in new databases definition, as required by the problem to solve. If one needs to control several motors and some scalers, one has to create a database containing one record per device to control. Many records are part of the standard EPICS distribution, and some are custom-made. In the currently developed application, there was no need to create new records, because they already existed for the devices we wanted to control.8
Records are made of fields that are elementary cells that can hold a value of a given type (an integer, a float, a string...). Even the simplest record already has around 30 fields that are the minimum set of values that EPICS requires to process it. It contains such variables as the name of the record, the way it has to be processed by the EPICS monitors (periodically, on some I/O event, or only on request) and so forth. There is no limit, except hardware, to the number of fields a record can hold.
The Analog Output record is one of the records that is used mainly as interface between SNL subroutines and the UNIX side. For example, when someone clicks a button to move the Harp (see table 4.4) it writes a coded value into an Analog Output record that the SNL program catches and starts the corresponding routine. The most used field is certainly the ``VAL'' field, to transmit a numeric value.
The Binary Output record has almost the same description as the Analog Output record , but it can only be set to ``true'' and ``false'' instead of an arbitrary real value. It also has 2 field strings, to store the meaning of those two states, like in the scaler GUI, the button [7.a] (see table 4.4.3 and Figure 4.4) the strings are ``done'' and ``count''. Sometime the fields string have been used to pass a string from the IOC to the UNIX client.
A lot of calc records were used in the scaler GUI
4.4 to compute the output of the ``normalized'' and
``hertz'' mode from the raw data given by the scaler. This record
allows an arbitrary calculation written as a C-like mathematical
string (like (a>)?sin(a):-a/b) to be performed between any
numerical fields of any record.
The motor record can be used with various motor drivers, we use the VME44 system from Oregon Microsystem [4]. This VME card is a slave of the IOC on the VME bus of a crate. The most important output and input controls provided by this card are :
The VME44 card can control up to 4 drivers connected to its port. Two different drivers from Oregon Micro Systems where used. The main difference between the two, was the step subdivision they provided. The standard model subdivides each physical motor steps (typically 200 for a revolution) by 10, and the advanced model was able to subdivide by up to 150.
These drivers have to be connected on one side to the VME card (by the A and C row of the VME connector) and on the other side to the motor. They also have to receive a power supply connection. A connection standard was established. Two boxes with 4 connectors each were designed and realized. One of them actually uses the 4 axes and the other one has been filled with only one controller for now.
Many different stepper motors were used, ranging from 5 to 30 watts, the main difference between them was the presence or absence of an encoder on the motor. The encoder allows feedback as the motor moves, acknowledging each step physically made by the motor9.
The Joerger Scaler VSC16 is a VME card that can be placed in any VME slot, it uses the VME bus and interruption mechanism to talk with the Master IOC. The scaler has 16 NIM logic channels that can count pulses on a 32 bits at a rate of more than 40 MHz.
It has it's own 10 MHz clock, and in our configuration, we connected it
to the first of the 16 input channels of the scaler. The scaler can
be set up such as making all channels to stop automatically when a
certain value is reached by the first counter. By appropriately setting this
value into the first counter, we can use the 10 MHz clock as a time
base. It gives us a very precise sampling gate that would obviously
not have been reached by a 'real time' Operating system. Looking at
Figure 3.2 we can see how the timing of an
endless loop that read a timer is affected by interruptions and other
processes. This loop is a brute program. Almost every other
process is blocked, because we were bypassing the EPICS and
VxWorks sharing system. If we had to use the standard SNL language
delay() function, the error bars would go from a usually
acceptable millisecond range to some hundredths of a second, without
having any way to know what the actual value really was.
 |
The 10 MHz quartz provides a stable clock, that defines the acquisition gate for the scaler and the IOC comes to read it from time to time, typically reseting the values and launching another sampling. By this way an acquisition rate of 60 events per seconds is reachable. A more tricky (and experimental) way to do it can go up to rates of the order of the kHz (see section 4.8).
The main goals of these counters is to count the activity along the beamline. This was achieved by installing scintillator detectors along the beamline (see Figure 2.9) connected to a scaler entry.
The version of devScaler.c we have installed in production
has been hacked from the standard distributed version (v1.2),
the original version assumed 17 channels on the scaler by reading it's version
number in ROM, but it is incorrect, we only have 16 channels with
the NIM version of the scaler.
So in the source file devScaler.c we had to change the line in
function scaler_init() (line 294 :
scaler_state[card]->num_channels = *p16 & 0x1f;
to :
scaler_state[card]->num_channels = *p16 & 0x18;
If the problem is not otherwise fixed, this would have to be made again if a new release of the Scaler Record were to be installed.