AccelNET provides three default users. Each user serves a specific function.

This procedure explains what to do to start an individual computer. If the system is operating correctly, things should pretty much happen as described. If there are problems, refer to the Linux manuals for more information.

Note that the file server computer should be the first machine started. Remember that the other computers use the file server.

Linux may decide to check the file system if it detects the computer was not shut down properly. If error messages appear while the file system is being checked, it indicates that there is a problem with the files contained on the disk. Usually it is safe to answer "y" to the questions fsck (the file system check program) asks. Sometimes the file system check will require a reboot of the machine.

When this sort of a problem occurs, it usually means that the computer was shut off or restarted in a disorganized manner. Perhaps the computer crashed, the power failed, or someone pushed the reset button. Consult the Linux manuals for more detailed information.

When the login prompt appears, the system is ready for operation.

The login name "csoperator" is provided as a default login for accelerator users. It is possible to customize the system to provide an individual login for each user. Please consult the Linux documentation for information on creating user accounts.

When the computer is powered up, it will go through a normal boot process containing messages that are usually followed by [OK]. Once the boot messages are complete, X (the graphical interface) will start up and prompt for a login.

Type in the username and password in the appropriate text boxes. The password field may not be shown on the initial screen, you will be prompted for it later if this is the case. During this time, you also have the ability to select a Window Manager. It is recommended that KDE or Gnome be used. These two selections provide the most user-friendly experience, being similar to Microsoft Windows.

This procedure explains what to do to stop an individual computer. If the system is operating correctly, things should pretty much happen as described. If there are problems, refer to the Linux manuals for more information.

Many Linux desktops have a method to shutting down using the graphical interface. Because the graphical method may vary, the command line method is described here.

Note that the file server computer should be the last machine stopped. Remember that the other computers use the file server.

In order to effectively to use the more advanced features of the accelerator control system, the user should be familiar with the process of logging into the system as well as the commands provided by the Linux operating system.

The concepts of pathnames, current directory, and i/o redirection are very important to a good understanding of how the Linux environment works.

Look in the Linux manual pages for descriptions of how these and other commands work.

This is a list of basic commands:

This is a list of more advanced and administrative commands:

This chapter explains the procedures taken to install AccelNET onto a RedHat Linux 9.0 system. All new accelerator control systems shipped from NEC should have AccelNET preinstalled.

To prepare the system you must be logged in, or su'd to root. If you are not root, then su - and type in the root password.

Now that you have postgres removed, you can begin the AccelNET installation.

Continuing on from the Preperation section (as root), you must mount the AccelNET installation media. There are 2 methods of doing this.

Method 1 (AccelNET CDROM):

root# mount -t iso9660 /dev/cdrom /mnt/cdrom

Method 2 (NFS share on kitchen):

root# mount -t nfs kitchen:/acc.base /mnt/cdrom

You should now have the AccelNET installation media mounted to /mnt/cdrom. Next, a few libraries must be installed that are not standard in RedHat 9.0.

root# cd /mnt/cdrom/redhat/8.0
root# ./install_libs

Now that the proper libraries are in place, AccelNET can actually be installed:

root# cd /mnt/cdrom/installation
root# ./install_accelnet

If all went well, all of the needed files should be located in /AccelNET.

First, set initial passwords for the csadmin and postgres accounts:

root# passwd csadmin
root# passwd csoperator
root# passwd postgres

Since you are using RedHat 9.0, the camac 'crate_24' command must be overwritten:

csadmin$ cp /AccelNET/necdrivers/rh9/crate_24 /AccelNET/sbin/crate_24
csadmin$ chown csadmin.cs_admin /AccelNET/sbin/crate_24
csadmin$ chmod 755 /AccelNET/sbin/crate_24
csadmin$ ln -s /AccelNET/sbin/crate_24 /AccelNET/sbin/crate

Next, the nec initialization script must be configured and installed.

root# /AccelNET/necdrivers/build_nodes
root# cp /AccelNET/necdrivers/nec /etc/init.d/nec
root# chmod 755 /etc/init.d/nec
root# cd /etc/init.d
root# vi nec

It is a good idea to reboot (type 'reboot' as root) at this point to make sure that the nec startup script is working and that postgres is starting properly. After rebooting, you can view the loaded modules by typing 'lsmod' and check for errors with 'dmesg'. To verify that postgres started properly, make sure that 'ps ax | grep postmaster' returns an entry with '/AccelNET/pgbin/bin/postmaster -S -D/AccelNET/postgres' or similar.

The control system is made up of devices. Examples of devices are Faraday cups, charging voltage supplies, bending magnets, and electrostatic quads.

A device is identified by what is called the Label. It is 8 characters long. By convention the label is usually (not always) made of three fields.

The first field is the device name and is 3 characters long. The device name is to be right padded with spaces if less than 3 characters are needed.

Examples:

The second field describes a region on the beamline.

Examples:

The third field is a serial number. It describes an occurance of a device in a region on the beamline.

A complete Label looks like this:

There are exceptions to this naming convention. For example, the label "SETUP" has as its parameters all of the particle related information such as total machine energy, species, charge state, etc.

A device is made up of a set of parameters. Parameters are considered single control and readback points. These parameters are identified by what is called a tag name. A tag name is a combination of the device label and a RefName.

Example RefNames (typical of a Faraday cup):

The complete tags for the parameters associated with first preacceleration Faraday cup are:

The AccelNET services must be started by the 'csadmin' user. The following instructions assume you have logged in as the 'csadmin' user. All clicks will be a single click unless otherwise noted.

Checks are in place to help prevent this, but are not fool-proof. If you are unsure whether the services are running or not, go through the stopping procedures before starting.

All of the tools listed here may be started from the AccelNET menu.

The graphical user interface for AccelNET is made up of two programs: crt and ts. The operator interacts with crt while ts runs in the background handling events. From this point on, these two programs will be referred to as Xcrt.

4.3. Organization of the Xcrt Display Window

The Xcrt display window is divided into three sub windows. The windows are called: the mouse window, the keyboard window, and the page window.

[D]

Example Xcrt Display.

4.3.1. Mouse Window

The mouse window consists of two display lines. It is used to show the readback and control parameters currently assigned to the mouse. In general, the upper line is the readback, lower is the control.

Selected parameters occur in pairs (readback and control point).

For example, when the charging power supply voltage control is selected, the selected readback is the positive power supply voltage readback.

The association between control points and readback points is determined when the page is constructed and may vary between pages.

A parameter is selected by placing the cursor on the numeric value or icon of the desired parameter and pressing the select button on the mouse.

There may be more than one parameter set located under a field. An alphanumeric field has a possible two parameter sets. An icon field has a possible four parameter sets. Clicking on the selected parameter multiple times cycles through the sets.

Note that some parameter sets may contain just a readback value, some may have just a control value, some may have both, and some may have both fields set to the same parameter.

4.3.2. Keyboard Window

The keyboard window consists of two display lines. The upper line is used to type commands. The lower line is for displaying error messages. Error messages are normally displayed in red. Pressing enter (<cr>) clears the error message.

4.3.3. Page Window

The page window displays the currently selected page.

The display is organized as a set of pages. The pages are organized by machine region. A separate page is provided for each injector, a page for the low energy beamline, etc. The pages are arranged to provide overlap between machine regions (the same parameter may appear on a number of pages). For example, the injector pages have some of the low energy beamline components on them. This is done to minimize the number of page changes required when tuning beam.

Information on the pages is provided in two manners.

Alphanumeric

Parameter name, value and units

Icon

Picture of a device such as a Faraday cup where the color represents the status

4.3.4. Display Colors

Alphanumeric pages

Green

Value is within database defined limits.

Red

Value is outside of database defined limits.

Violet

Indicates a status error. A CAMAC error such as a missing module. A DUTEC error such as a communication problem or lack of power.

Icons

Dark Blue

Device is inactive (power off).

Green

Device is active (power on).

Yellow

Various meanings depending upon the icon.

Faraday Cup

Cup is inserted into the beam path

Double Slit

Slit is in motion.

TPS Corona Probe

Probe is moving.

GVM and icons inside of tank

Indicates TPS operating mode, gvm icon yellow means gvm mode.

Red

Indicates an error condition. Example: control system has told Faraday cup to go out and cup status read indicates cup is in

There may be several assignable meters in the system. Each meter module has a mantissa display (the meter), a liquid crystal display (LCD), two range select buttons, and an assign button. There is also an analog jack for each meter located on the rear of the meter chassis. The analog jack gives the value of the mantissa. The voltage range is 0-10v.

The current meter assignment is shown on a LCD located above the meter. The first line of the display shows the Label and RefName for the assigned parameter. The second line shows the parameter value and units. The third line shows the currently selected meter range.

The meter system is only accessable through the workstation it is connected to. The currently assigned readback parameter in the focused window is assigned to a meter when the assign button for that meter is pushed. If the mouse readback parameter is NULL, the meter is unassigned.

There are two meter range buttons. Pressing a button increases or decreases the meter range.

If both range buttons are pressed at the same time, the meter enters freeze mode. Freeze mode is indicated by the message "frz" on the 3rd line of the LCD. This mode is used with autoranging parameters such as the Faraday cup current reads. Pressing a button increases or decreases the meter range. Pressing both buttons at the same time when in freeze mode exits freeze mode.

Meter overrange is indicated by the word "overrange" on the LCD. No meter assignment is indicated by the LCD being blank.

Certain types of devices can not be assigned to the meters. These usually consist of digital (status/control) parameters. For example: Faraday cup position reads.

There may be several assignable knobs in the system. Each assignable knob module consists of a knob, a LCD, two range select buttons, a save button, a restore button, and an assign button.

The current knob assignment is shown on the LCD located above the knob. The first line of the display shows the Label and RefName for the assigned parameter. The second line shows the parameter value and units. The third line shows the current knob sensitivity setting.

The meter system is only accessable through the workstation it is connected to. The currently assigned control parameter in the focused window is assigned to a knob when the assign button for that meter is pushed. If the mouse control parameter is NULL, the knob is unassigned.

The knob sensitivity is given in turns to full scale (tfs). For example, if you are controlling a 15KV power supply and the sensitivity is set to 50 tfs, each complete turn of the knob will increase or decrease the voltage by 300V (15KV/50tfs = 300V). Pressing a range button increases or decreases the knob sensitivity.

The save and restore buttons work in exactly the same way as the keyboard "sv" and "rs" commands. Pressing the save button stores the current value of the parameter. Pressing the restore button recalls a previously saved value.

The accelerator commands have been arranged in a way that hopefully provides an organized and convenient method of starting up the machine. The intention is to start the machine up in stages or layers.

The best order for issuing commands, using S2 and 1B as examples, is:

The sources usually require some warmup time, therefore you will probably need to start with a lower charging voltage than the final setting from the last run and increase the charging as the source warms up.

If the charging system is balanced correctly, the beam should go all the way to the target with minimal retuning. The parameters most in need of adjustment are the ion source parameters and the stripping gas. With a little practice, it is easy to return the beam to the target at the same energy previously run and with the same beam current.

The user should resist the temptation to immediately start retuning the machine and instead look for and carefully adjust those items that are the least well controlled by the computer such as gas, charging and ion source focus.

If a previously saved run is not being loaded, the ion species setup information should be entered on the machine setup page.

The content of this manual does not cover every command and configuration of the AccelNET system. Manual pages have been created for a large percentage of the commands and other aspects of AccelNET. To access them, use the man command, browse the AccelNET web interface, or use the X manual pages menu item from the AccelNET menu.

In order for information to be saved, restored, scaled or otherwise manipulated, an empty directory must first be created in which to work. The Linux command "mkdir <directory name>" is used for this. It is suggested that the directory name be used to identify the particle run. Linux directory names may be up to 255 characters long. For example, "Au+++3.0MeV" could be the name for a triple plus gold run at 3.0MeV particle energy.

Next change into the directory just created by typing: cd <directory name>

Many of the commands described in the previous section use the current directory as a place to read from and write information into. Most of them are also implemented using Linux shell scripts (please see the Linux manual pages for bash). They in turn use the programs "ReqPar" and "dbmod" in order to communicate with the control system.

The program "ReqPar" reads from a list of tag names and asks the control system for the current values. The values obtained are written into a disk file along with the tag name.

The program "dbmod" may be used to send values to the control system from files created by ReqPar. The files containing the lists of parameters to obtain from the control system and the lists of parameter values obtained are text files and may be created or edited by a standard text editor such as vi.

The scaling program allows the particle energy, particle species, and other such parameters to be changed. The current values of the machine parameters can be retrieved from the running database, changed, and sent back to the running database. Alternately, parameters saved from a previous run may be scaled and sent to the running database.

The preacceleration components may be changed seperately from the post acceleration and machine components, thus allowing the injection energy to be changed to obtain a "match" into the accelerator.

Preacceleration and ion source parameters from a run may be combined with post acceleration parameters from another run in order to create a run on a new target beamline.

The scaling process is divided into three parts:

The scaling process uses parameter lists to do its job. A parameter list is a disk file with lines of text containing the tag name and value of the parameters. The scaling program reads the parameter list file and outputs a new file with the same format containing the newly scaled values.

Parameter lists to be scaled may be obtained from three sources:

When the scaling program is invoked, a copy of the entire database is read into memory. As each parameter in the list is processed, a scaling key is looked up in the database. The scaling key tells how to process the parameter to obtain the new value.

The scaling program must be provided with information that tells it the current particle energy, mass, and other needed values in order to function properly. This information is read in from a file called "MACHval" when the program is invoked. The file is obtained from the running database by typing "request MACH" or from a database save by "up" or "updaemon" by typing "extract MACH". Either way, it must be present in the current directory for the program to run correctly.

The program changes parameters such as the charge state, mass, and particle energy via a menu.

The accelerator is divided into three regions: preacceleration, machine, and post acceleration. Each region has a particle energy, charge state, and mass associated with it.

The energy relationship between the areas is TotalPartE = InjPartE + MachPartE. The scaling program allows any one of the three variables to be manipulated in the following way:

The preacceleration region contains all of the beamline components from the ion source to the entrance of the accelerator. When components in this machine region are scaled, the values of all components affected by a change in InjPartE are recalculated. This includes the bending magnets, einzel lenses, and steerers. Also, the cathode, extractor, and deck bias for a SNICS source. For an RF source, the focus, extractor, and deck bias.

The machine region contains the components needed to set the machine to a given terminal voltage. When components in this machine region are scaled, the values of all components affected by a change in MachPartE are recalculated. This includes TRV and corona probe position. The charging voltage is reset to the value needed for no beam operation if it is included in the list to be processed. (The charging voltage is not currently in the parameter lists, therefore it should be reset by hand).

The post acceleration region contains all of the beamline components after the machine region. When components in this machine region are scaled, the values of all components affected by a change in TotPartE are recalculated. This includes all post acceleration optics and the in tank quads and steerers.

The TRV setting is reset by changes in MachPartE. In turn, when TRV is changed, the corona probe position is recalculated. If TRV is changed by a large amount upward, it may be wise to put in a preacceeleration cup and turn off the chains before sending the new values. Wait for the corona probe to reach its new position before turning the chains back on. This prevents unnecessary sparking while the probe is moving to the new position.

The field strength of the magnets is calculated on the basis of MfieldR (the current hall probe value) and the new value is MfieldC (the magnetic field setting value). When the new MfieldC values are written into the running database, the magnet autotune routine is invoked causing the magnets to be retuned to the new field strength.

InjPartM is used to calculate preacceleration optics. TotalPartM is used to calculate post acceleration optics.

The runtime system calculates:

InjPartE = InjPartV * abs(InjChgState)

MachPartE = (GVM * (OutPartM / InjPartM) * abs(InjChgState)) + (GVM * abs(OutChgState))

TotalPartE = InjPartE + MachPartE

InjChgState, OutChgState, InjPartM and OutPartM are entered by the operator as part of the machine setup information.

This is an example of how to do a scaling run. We are going to reduce TotalPartE by changing the terminal voltage. Ion source S2 and beamline L6 are being used for the run.

The initial conditions are:

The steps are:

If the scaling process is repeated by using "request" to obtain new values from the running database, "scaenv" should be removed before invoking "scale".

This is another example of how to do a scaling run. In this example we are going to reduce the injection energy by 5 KeV. The initial conditions are the same as the last example.

The steps are:

This is the setup procedure for the terminal servers.

AccelNET provides a complete AMS data collection system capable of managing data collection for any species of interest. All collected information is logged to disk. The system may be reconfigured by operator command to change ion species.

AMS data logging is comprehensive. Data for every multicup (stable isotope off-axis Faraday cup) are logged in disk files and time stamped with the jumping cycle number in which the measurement was taken. Event data for each detected rare isotope particle is logged and is time stamped with the jumping cycle number and event number within the jumping cycle.

A "setup" file is written containing other information such as the terminal voltage, rare isotope, charge state, etc. for each measurement.

All of the logging files are written in ASCII to make them easy to view, manipulate and input to other programs.

As each cathode measurement is completed, a summary of the measurement is written to a disk file and displayed on the screen.

When the runlist is completed (all cathodes are measured), a summary file is written containing the average currents, rare isotope counts, average ratios, standard deviations etc. for all cathodes in the runlist. Other summary files may be created containing tab separated fields suitable for use by Quattro and Excel.

After all measurements for a list of cathodes have been completed, the datasets gathered may be reanalyzed off line if necessary. Parameters such as the rare isotope gates may be changed and the datasets reprocessed to obtain new summaries.

The summaries are then analyzed to perform normalization, background subtraction and so on.

NEC has written software using the PV-Wave (a data analysis package) language which performs both post measurement functions. NEC calls this software IsoNET.

IsoNET is divided into two programs. One program is used for reanalysis (off line data reduction) of the datasets. It traverses a list of datasets specified by the operator, reevaluates them and writes new summary files.

The second program performs normalization, background subtraction and calculates conventional AMS results and uncertainties.

The sequential beam injection system consists of an ion source, an electrostatic spherical analyzer, a bending magnet with an insulated chamber, three off axis Faraday cups and an X/Y steerer.

The post acceleration portion of the system consists of a bending magnet, three off axis Faraday cups, an electrostatic cylindrical analyzer and a gas ionization chamber. The figure titled "AMS system components" is a simplified line drawing of the accelerator layout.

Two of the cups at each end of the machine are used for carbon AMS measurements. The two cups plus a third set of cups can also be used for other species of AMS.

The ion source may be either a multicathode solid SNICS source or a multicathode gas SNICS source. In both cases a negative ion beam is accelerated from the source and passed through an electrostatic spherical analyzer (ESA). The ESA removes energy tails in the beam, which are produced by the cesium sputtering process. In systems containing two ion sources the ESA is made rotatable to select which ion source is to be used.

The beam then passes through a bending magnet with an insulated chamber. The bending magnet is set to bend 14C to the correct angle for injection into the accelerator. 12C and 13C are bent past the angle needed for accelerator injection into a set of offset Faraday cups which are monitored by AccelNET AMS. A power supply connected to the insulated magnet chamber is controlled by a signal supplied by the sequential injection control electronics. Voltages are sequentially applied to the magnet chamber to inject 12C and 13C.

A set of X/Y steerers follows the bending magnet. The steerers are also controlled by the jumping system. A different set of voltages is applied for each injected species to correct for slight possible differences in beam position and direction which may be produced by the different gap voltages applied to the magnet chamber.

The beam jumping control electronics may also be used for a simultaneous injection system. In this case bending magnet chamber bias and the steerers are not required but an electronic chopper is used to reduce the average intensity of the 12C ion beam to about 1% of its DC value. The data collection process is otherwise unchanged.

Beam jumping waveform and gating signals are generated by a set of CAMAC modules designed and manufactured by NEC. Below is a description of each of the modules which make up the system. Please refer to the figures titled "AMS data collection System block diagram" and "AMS carbon data acquistion waveforms".

AccelNET AMS provides a complete facility to control AMS data collection. A supervisory program controls the changing of the cathode in the ion source and starting and stopping of data collection. The status of the accelerator is monitored, and the program will pause data collection in the event of a problem such as a beamline valve closing due to a vacuum fault. Data collection startup is inhibited in cases where the operator may have failed to open a Faraday cup or a beamline valve or other accelerator problems may interfere with data collection.

The supervisory program may be configured to call other programs at various points in its execution. For example, one might implement a program to log accelerator parameters and run this program each time a cathode is measured.

The supervisory program operates from a list of cathodes (a runlist) generated by the user. This list specifies measurement parameters including the number of times to measure the cathode, the warmup time, the data collection time and the data collection mode.

The cathodes may be divided into groups within the list and each group measured consecutively or independently. Data may be collected for a fixed amount of time or a fixed number of rare isotope events.

When collecting for a fixed number of events, a time limit is also used to prevent excessive collection time on cathodes which have low count rate or problems such as low current. This mode collects until one of the limits is reached.

The cathode runlist may be traversed in two ways.

One way is to measure each cathode once and then go to the next cathode in the list. When this method is used the cathode list is traversed as many times as necessary until all cathodes in the list have been measured the number of times specified for each cathode.

The second way to traverse the cathode list is to measure each cathode repeatedly until the cathode has been measured the number of times specified in the runlist. When working in this mode another program in AccelNET can be used to analyze the measurements as they occur and make decisions about whether to go on to the next cathode or measure the same one again.

This is typically used in applications where it is desired to make several short measurements of a cathode and after some minimum number of measurements make a decision based on the scatter of measurements whether to measure again or go to the next cathode.

AccelNET provides a program module which makes this decision based on the results of the most recent N number of runs. It is possible to write program modules using other selection criteria.

IsoNET also provides a "best run" selection feature for off line analysis.

Abundant isotope collection is performed by a set of current amplifiers and CAMAC transient recorders. The current amplifiers are controlled by the computer and may be adjusted over a wide range.

The output of each current amplifier is connected to a transient recorder. A transient recorder is a type of list mode ADC. During each jumping cycle the transient recorders are individually clocked by signals from the gate generator at the appropriate moment to capture the value of the pulsed current waveform.

Usually each transient recorder is clocked once per jumping cycle. The isotope is sent to the offset Faraday cup by the beam jumping system, and a snapshot of the current value is taken and placed in the internal memory of the transient recorder.

Occasionally (approximately every 10 seconds) data collection is paused, and the list of measurements is uploaded to the computer where the information is placed in disk files for later processing.

Each time a block of data is uploaded numbers such as the average current and isotope ratios are updated in AccelNET.

NEC offers an option to this system which allows the transient recorders to be clocked more than once per jumping cycle. Using this option one can capture several datapoints within each Faraday cup current pulse and perhaps better quantify the measurement.

Rare Isotope data collection is handled by a gas filled, delta-E detector, a set of NIM amplifiers and logic modules, a CAMAC peak holding ADC, a CAMAC multichannel counter and a CAMAC list processor.

A list processor is a CAMAC module which performs CAMAC I/O operations independently of the computer. It contains a large RAM so the data from the I/O operations it performed can be stored.

The detector contains up to six plates for measurement of Etotal, dE1, dE2, dE3, dE4, and dE5.

The analog outputs from the NIM amplifiers, a trigger signal generated by the NIM electronics and gated by a signal from the jumping electronics are fed into the peak holding ADC.

A program is loaded into the list processor by AccelNET and the list processor is enabled. Each time the ADC receives the trigger signal from the NIM electronics it performs a conversion. At the end of the conversion the ADC asserts a LAM signal.

The list processor waits for the LAM from the peak holding ADC to trigger it. Each time the list processor is triggered it runs the program which has been loaded into it.

The program performs a number of CAMAC I/O operations to copy the data from the ADC to the list processor and clear the LAM. It then goes to sleep until the next trigger.

Periodically data collection is paused, and the data collected in the list processor's internal memory are uploaded to the computer.

The rare isotope data collection system uses two channels of the CAMAC multichannel counter.

The ADC trigger signal from the NIM electronics is split and is sent to the ADC and to one channel of the CAMAC counter module. Each time the ADC is triggered the counter is incremented. This provides a count of the number of ADC triggers supplied by the NIM electronics. When the data are uploaded from the list processor this register is read and a parameter containing the total number of ADC triggers is updated.

When the uploaded data are processed the number of events contained in the data block is counted and a parameter containing the total number of events processed by the list processor is updated.

If the ADC is already busy performing a conversion when another trigger is received, a particle event will be missed. By comparing the two numbers one can get an idea of the number of missed events (detector system pileup). Normally the number of missed events is very small, usually less than 0.1% of the total number of events.

Another channel of the counter module is used to count the number of jumping cycles which have occurred. It is connected to a signal from the jumping electronics which causes the counter to increment at the end of each jumping cycle. Each time the list processor is triggered the cycle number is read from the counter and placed in the block of event data. This allows individual events to be stamped with the cycle number in which they occured.

All aspects of rare isotope data collection are controlled by configuration files. Parameters such as the number of channels of data read from the ADC can be changed. This makes it possible to use the system with other types of particle detectors and perhaps use the system for other types of event counting.

For example, a solid state detector requiring only one ADC channel could be used. The program loaded into the list processor would be changed to only retrieve data from a single channel. This has the side effect of allowing more events to be stored in the list processor's memory and decreasing the data collection dead time because a smaller number of CAMAC I/O operations need to be performed.

It is also possible to locate CAMAC hardware needed for other types of experiments in the same CAMAC crate and load different programs into the list processor for the various configurations.

HISTmngr is a display tool which allows viewing of the histogram, contours, and gates which have been defined for the species of interest. Any of the defined histograms or contours may be viewed and the event gate settings may be changed from this program.

When rare isotope data are collected and uploaded into the computer the individual event data blocks are processed according to rule sets contained in a configuration file.

The format of the rare isotope event file and sets of one and two dimensional histogramming arrays (contours) are specified here. An event gate may be defined for each spectrum.

As each event data block is processed a line of data is written to the event file and the histogramming arrays are updated. One channel of input data may participate in several histograms and contours at the same time.

The backup program allows backups to be made of two groups of files.

The first is the "root" group. Backup of this information is required only when changes are made to Linux and the files associated with it. For example, if new users are added to the system.

The second is the "users" group. As new particle runs are added, this information changes and should be backed up. Currently the backup shell script copies all files owned by postgres, csadmin, csoperator, and kitchen to tape.

The restore program is used to copy files from a tape to the disk. When this operation is performed, files are created or modified on the disk as necessary.

The backup and restore programs are shell scripts and are easy to change. As the amount of information contained on the disk drive grows, the shell scripts may have to be changed in order for all of the information to correctly write to and read from tape.

The backup and restore programs both use the program tar to perform their jobs. See the Linux manuals for information on how to use tar.

Use these steps to perform a backup:

The backup program is invoked as follows:

The restore program is invoked as follows:

To aid in the backup of data, NEC generally provides a CD/DVD writer with each control system. This section will cover the basic usage of some scripts to create and write standardized backups of AccelNET releated data. If you would like to use the CD/DVD writer for other purposes, using a graphical application such as xcdroast^[1] or K3b^[2] is recommended. The scripts provided are wrappers to the following command line tools: mkisofs, cdrecord, growisofs.

The Postgres^[3] database manager is used to construct and maintain the control system database. In addition, it is used to generate the wire lists needed to assemble the CAMAC interfaces.

All of the relevant information needed to build the control system database is entered via SQL^[4] into the Postgres database.

After the database is entered into Postgres, each one of the tables needed by the accelerator control system is extracted from the Postgres database via SQL queries. They are then processed by other programs to translate the information into a format used by the runtime system.

This manual gives definitions for the fields in the tables maintained by the Postgres database and how they are related to each other.

A bold field name indicates the primary key. In some cases the table is keyed by more than one field. This is called a composite key. An italicized field name indicates an alternate (candidate) key. An alternate key is a field that can be used to uniquely identify a record (row, tuple) in a table in place of the primary key. This means that it must remain a unique value for each record, just like a primary key.

The LabelRec, DescRec and DataRec tables all work together to provide a definition of the data points in the control system.

More information concerning the use of the Label and RefName fields can be obtained in the operators manual in the section titled "Organization of machine parameters in the Control System Database".

The button tables (BoxRec and PadRec) have been deprecated and are slated for obsolete status. The original function of these tables was to provide touch screen or other alternative input support.

These tables are used to validate fields of other tables in the database. The following is true unless marked with an asterisk (*). These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.

The display page database is made up of several record types.

PgKeys contains the master records for a display page. There is one record in PgKeys for each page in the system.

The rest of the records define display entities. There is one record for each entity on the screen. An entity can be an alphanumeric field or an icon.

These tables are used to validate fields of other tables in the database. These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.

Interlocks are used to provide conditional actions on data points. They are usually used to provide software equivalents of hardware interlocks. An example might be to prevent a Faraday cup from moving out of the beamline unless the next beamline valve is open. The beamline valve cannot be opened unless there is good pressure on either side of it. Icon colors are also determined by entries in this table.

Interlocks are defined by first choosing a data point to be acted on. The point chosen is entered into a record in the ChkList table.

An interlock chain is created by defining records in the ChkPoint table. The ChkPoint table defines what data points will affect the action. The way in which the data point is evaluated is determined by the CPtype field.

The ChkAct table looks at the word formed by the entries in ChkPoint to determine what will happen to the data point in ChkList. If the word matches the checked criteria, a new value is returned for the ChkList data point.

The ChkAlarm table is processed in a similar way that ChkAct is processed, but returns an error message to the user, instead of a value to the data point.

The numeric processing system allows simple algebraic manipulation of data points to form a value to be written into a data point. This is used to perform calculations such as total injection voltage.

Just like the interlock tables, the numeric processor works off a chaining system. The data point to be affected is set in the NumList table.

The NumPoint table is used to perform the algebraic operations. The operations are peformed in order based on RecId. NPtype is used to define what algebraic function to perform (e.g. add, subtract, multipy, divide, sin, cos). A chain is started with an initial stored value of 0. The first record usually inserts an initial value using 'load' or 'add' as the NPtype. When a record is processed, the data point specified by NPdskey is multiplied by the Scale field to create the operand. If NPdskey is NULL, the Scale field is used as a constant operand in the calculation. Once the operand is determined, the operation specified by NPtype is evaluated on the stored value and operand. The result is placed in the stored value. This continues until all of the records in the chain have been processed. Once the chain has completed, the resulting stored value is written to the data point specified in NumList.

To facilitate complex algebraic equations, four subtotal values are available. They can be used by appending '_S#' to NPtype, where # is 1 through 4. Once the subtotal has been calculated, it can be evaluated into the main total using 't_add_S#', 't_sub_S#', 't_mul_S#', or 't_div_S#'. When the above evaluations are done with the main total, the subtotal is automatically cleared.

These tables are used to validate fields of other tables in the database. These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.

These tables are used to validate fields of other tables in the database. These tables should not be modified by the user. The tables will only change if new functionality is added to AccelNET.

After the database is entered, the data conversion coefficients for all of the data points must be calculated. This is done by invoking the BuildMB family of programs.

The buildmb script should be run after the initial creation of a new database, as well as when one of the following has been changed in the DescRec table: SpanMin, SpanMax, DataType, Size, DRkey, MBconvKey, or MBsetIncKey. If MBconvKey is not set to 'Y', buildmb will ignore the record when calculating M and B. If MBsetIncKey is not set to 'Y', buildmb will ignore the record when calculating IncVal.

Invoke a buildmb function by typing the following (as user 'postgres'):

buildmb <arg>

Here is a list that explains, by DataType, how buildmb treats a record.

DataTypes marked with an * are handled by the runtime system in the following way: When the data(X) is processed, M and B are applied to scale the value between the desired range (Y = MX + B). The scaled value is then sent to what is called a piece table. A piece table is a predefined set of steps/ranges. Each range contains an internal set of M and B values. The internal set of M and B are applied using the same equation to the scaled value to obtain the final physical value.

The database must be converted to the correct format before it can be used by the control system. The format conversion is done by a family of programs that all have roughly the same structure.

The table to be converted is extracted from the Postgres database by a SQL query and placed in a file. When the table is extracted, a filter is applied to substitute integer values for names on certain fields. For example, in the DescRec table, the name in the DataType field is substituted for the integer value known by the runtime system. In the above example, the Dkeys table is considered an immutable table. This means that it cannot/should not be changed. The table is in place to prevent bad entries in database. The actual integer values are defined in the filter/AccelNET source code. The Dkeys table will only be changed when there is a change in AccelNET that affects it. The result of this is an ASCII file where each line contains a number of fields separated by a field separator (usually a vertical bar '|') and terminated by a linefeed.

A program then translates the created file into the record structure used by the control system. This process involves steps such as converting strings of characters into floating point numbers. The program that does the translation is specifically tailored for the table in question, producing a new result file.

It is presently arranged so that the extracted Postgres tables occupy a directory. The SQL scripts share the directory with the extracted files along with a shell script that is used to translate the tables.

The table translation programs, invoked from a shell script, are in a separate directory. They read from the directory containing the extracted files and write into another directory.

As you become familiar with the fields of the database and how to manipulate them through the data entry screens you may want to learn to use the tools the Postgres database manager provides for manipulation of the database.

SQL is a programming language that allows records to be added, deleted, and modified to/from the database. It makes adding large quantities of records (for example, if a new beam line is added to the system) very easy to do. Consult the Postgres manuals for more information.

All of the reports described in this manual are generated using SQL, some of the UNIX tools, and a report written in C. Examine the report scripts provided with the system for examples.

For more information on SQL, visit http://www.postgres.org/docs/ as well as other online or printed documentation.

To help facilitate construction and maintenance of the database a collection of tools have evolved over time. This collection is not guaranteed to be complete. It is provided as a convenience to the customer.

Using the tools requires a working knowledge of the database design, SQL, and the UNIX shell. There are many existing script files to serve as examples.

Editing the control system database requires that you understand the database structure as covered in previous chapters.

To effectively edit and apply changes to the runtime system, you will need access to both the csadmin and postgres users. The actual editing is performed by the postgres user. The csadmin user is only needed to perform a restart of the control system. A restart is required for new additions and modifications to certain tables.

For the remainder of this chapter, the contract name 'sample1' will be used.