BLISS: Spec Tutorial CH5 SPEC configuration

One of SPEC most interesting features is the possibility to adapt it to all kind of different setups.

In this chapter the SPEC starting sequence is described and the way in which it can be adapted. Config and setup files are used by both SPEC administrators and users to define, change or remove hardware or other application specific definitions. During operations SPEC offers to users ways to enable/disable subsystems on line, without changing definitions.

SPEC developers must keep in mind this model when new macros are written so that the interface to users is kept simple.

SPEC starting sequence

When a SPEC application is started a sequence is defined so that macro loading and configuration is done in the correct order.

fresh or stale?

SPEC can be started in two different modes. When a user runs a SPEC application for the first time nothing is defined. It is said that SPEC is started from fresh. Then, the sequence will take care of loading macro definitions, initialize variables and so on. When this user leaves the application by typing quit or control-D its current state is saved into disk. All macro definitions, variable definitions and assignments are kept for next session. ( Remark that the contents of array type variables is not saved for disk and memory economy. ). Next time the user will start the application it will find everything like it was left. SPEC will start in non-fresh mode and read in the user state file. All macro definition ( either automatically loaded or defined by hand ) will be there as they were. So they will variable values ( including, for instance, the data of the last scan ). A fresh start can be forced by calling the application with the -f option. Then user state files are deleted and application started as if it were the very first time.

expgb rey ~ : vicente -f 
Welcome to "vicente" Release 4.03.05
Copyright (c)
1987,1988,1989,1990,1991,1992,1993,1994,1995,1996,1997
by Certified Scientific Software. All rights
reserved.[...]

Standard files

When SPEC is started from fresh the following files are loaded in order (if present):

SPECD/standard.mac
SPECD/vice.mac
SPECD/site_f.mac
SPECD/site.mac
SPECD/vicente/conf.mac
./spec.mac

When SPEC is started non-fresh the sequence only the files:

SPECD/site.mac
SPECD/vicente/conf.mac
./spec.mac

are loaded.

The file SPECD/standard.mac contains the definition of all standard macros provided with SPEC. Macros like mv, ascan or wa are defined here.

The file SPECD/vice.mac takes its name from the four first letter of the SPEC application. This file contains definitions that depend on a particular diffractometer geometry. For example, if SPEC uses a four-circle diffractometer, the file SPECD/four.mac will defined macros like wh, br, ci or ca to correctly work with this geometry. Using only the four first letter of the application name allows SPEC administrator to define several applications that share the same geometry.

The file SPECD/site_f.mac is optional and may be used to load definitions or run macros only when SPEC is started fresh. In the ESRF startup model this file is not used.

The file SPECD/site.mac is also optional but is read any time that SPEC is started. This file is used at ESRF to hook our own macro loading. SPECD/site.mac contains a number of macro definitions used later in the SPEC initialization. This file is of key important for ESRF startup model and it is common to all ESRF installations. For your information this file checks the environment variable SPECBL and it sets the variable GUI_RUN if SPEC is started from specgui. The macro jtdo is defined here as well. Finally this file will load the file SPECD/../jmacros/$(SPECBL)setup.mac. It is in this last file where the SPEC administrator will define the macro loading specific to each beamline. SPECD/site.mac will remain unchanged. The discussion about the $(SPECBL)setup.mac file can be found below.

The file SPECD/vicente/conf.mac is also optional. It is loaded every time SPEC is started. It may be used to do application specific definitions. At ESRF this file is not used. Its functionality is taken and expanded by the use of setup, discussed later in this chapter.

Finally if a file called spec.mac exists in the directory from which the application is started it is loaded as well. We do not use this at ESRF but still it may be used for example to automatically load macros for a particular user.

Then, when a SPEC administrator at ESRF wants to decide which macros will be loaded in a beamline he/she will only need to modify the file $(SPECBL)setup.mac this file will contain lines of type

jtdo(macro-filename)

the macro jtdo will check the timestamp of that file and, if it is not set or is older than the last file modification, it will load the corresponding macro-filename from the directory SPECD/../jmacros. The new timestamp will be set. This system will load all the necessary macro files when started fresh. When not fresh it will only load those files that have been modified or added to the sequence since last time.

The idea we keep at ESRF is that the files that are automatically loaded at startup should do nothing but defining macros ( with very few exceptions like checking of environment variables in SPECD/site.mac ). All the actual initializations of hardware, variables or any other is done with the use of two special utility files: config and setup.

Config

The config file is the standard way in which SPEC configures hardware. For each SPEC application the file SPECD/app-name/config defines hardware items and the necessary parameters to access them. Motors, counters, multichannel analyzers, CCD cameras, CAMAC, VME, serial, GPIB interfaces and I/O ports can be configured in this way. SPEC is compiled with the knowledge of how to program all of these pieces of hardware.

The config file can be edited by hand or by using the program edconf that offers a friendly user interface. The program edconf can be called from SPEC by typing the macro config. It can also be called from outside SPEC and it can normally be found on the directory SPECD. - do not forget settings file -

Every time SPEC is started the lines in the config file are read and interpreted. At this time the connection to devices is opened and initialized. If initialization to a device is not possible the device is marked as disabled and no attempt to access it will be done later.

The command reconfig in SPEC will close all opened connections and will read again the config file as during startup. As a result of this all the connections to devices are closed and reinitialized. For example, if a VME crate is rebooted it will be necessary to type this command so that dev_free is sent to all device servers and then dev_import will get the new pointers to the re-started devices.

An appendix to this chapter should show the most common lines (if not all) understood in a config file and detailed examples of how to configure common devices at ESRF - (i.e. MAXE, VCT6, MCA, CCD and so on... ). Detailed, explained pictures of every edconf window will be written as well.

( motor_par and counter_par )

The config file configures individual motor and counter channels. The SPEC administrator must choose a controller type for each of them, and eventually configure the controller separately. For both, motor and counter channels, controller NONE can be chosen. In this case when an action is required on a motor or counter channel SPEC just keep track of the values without accessing any real piece of hardware. This open the possibility to include other pieces of hardware, initially not known by SPEC, and make them look as any real motor or counter by the use of proper macros. This mechanism is explained in detail in the chapter devoted to pseudo motors and counters.

Setup

In a SPEC application there is often a number of other setup parameters that can not be included in a config file. To cope with this, at ESRF, a new file is assigned to each application and it is located together with config and settings file in

SPECD/app-name/setup

The setup file is a sequence of SPEC commands to send initialization commands, set parameters... to ensure the correct functioning of every subsystem defined in SPEC.

The file

SPECD/setup

contains setup commands common to all SPEC applications.

The setup files are read and executed every time SPEC is started. They are also loaded also after each config or reconfig command. Or after calling the macros setup or resetup.

The variable SEDITOR contains the name of the editor that will be used to edit the setup file when the setup macro is called within SPEC. The setup macro will open the editor with the setup file that corresponds to that application and will execute the commands in the file after the editor is exited. resetup will read and execute the file without editing it. When calling setup g the general setup file is opened instead.

If macros are written following the ESRF model described below. The setup facility allows to keep track of deletions in the file and performs the necessary actions to disable the system that was previously defined.

( examples - setup_tail and so on )

Enable/Disable subsystems

In some cases systems that have been defined in SPEC have to be temporarily disabled. Many reasons may exist for this: temporay disconnection, speed-up or security reasons or others.

In order to declare a piece of hardware or subsystem as disabled ( and without changing its definition ) a number of utilities exist.

SPEC itself provides with the commands

motor_par(xx,"enable")
motor_par(xx,"disable")
counter_par(xx,"enable")
counter_par(xx,"disable")

This commands will enable/disable individual motor and counter channels for SPEC and it will send no command to access them.

In the ESRF model every macro package is ideally provided with macron on/off

to perform this.

To avoid the user learning a long list of macro names and to show in a clear way which systems are enable/disable the macro blmenu can be used.

How it works and other uses of this macro -- state info and access to other macros in the macro package --

Writing macro packages for new systems. ESRF model

In the ESRF model ideally every macro package must include macros to setup the necessary parameters and to offer the enable/disable options.

• setup
• unsetup
• on/off
• body

Questions and Exercises