Instructions for building and using stdR1-4 stdR1-4 is part of synAppsR4-6, a collection of custom EPICS software intended to support most of the requirements of an x-ray laboratory or synchrotron-radiation experiment station. Aside from databases, SNL programs, and the like, std contains the following code: record support scaler scaler bank scanparm scan parameters for use with the sscan record table 6-degree-of-freedom optical table transform like an array of calc records, with output links scalcout variant of calcout record extended to handle string expressions, links, and values. busy utility record: calls recGblFwdLink only when its VAL field makes a transition to zero. swait replaces the wait record in base. This version uses a modified version of recDynLlib that supports dbNotify command completion. It uses ca_put_callback to do puts, instead of ca_put. sscan Replaces the scan record in base. This version uses EPICS' execution-tracing (i.e., ca_put_callback()) to determine when positioners and detectors are finished. sseq string-sequence record. This is a modified version of the seq record in base. This version can link to/from either string or numeric PVs. serial generic serial record vme generic vme record gpib generic GPIB record ddfanout Like the dfanout record. Modified to use double, rather than long. epid extended PID record for fast feedback genSub generalized subroutine record device support Joerger VSC8/16 scaler GP307 GPIB Vacuum gauge controller Heidenhain ND261 sincremental encoder interface ESRF 'Varoc' SSI encoder interface board Heidenhain AWE1024 GPIB encoder interface HP 10895A Laser Axis (interferometer) board GPIB Keithley model 199 DMM APS Bunch clock generator Generic A32/D32 VME Access Heidenhain IK320 VME counter/interpolator VMI4116 16-bit D/A converter miscellaneous C code dbLoadRecords Adds an optional trailing argument to dbLoadRecords(), so that you can prepend a path to the database file using a variable defined in iocxxx/cdCommands. For example: dbLoadRecords("stdApp/Db/yySseq.db","P=xxx:,S=Sseq2", std) dbLoadTemplate Allows you to use dbLoadTemplate() to load a .substitutions file that uses templates located in other directories. You can do this in the .substitutions file as follows: dbLoadTemplate("motor.substitutions") where motors.substitutions contains the line: file motorApp/Db/motor.db, motor and 'motor' is defined in cdCommands. sCalcPerform, sCalcPostfix String-expression evaluation support, similar to, and mostly backward compatible with support in base for numeric expressions. recDynLink Backward compatible extension of the dynamic-link software in base. Extension supports ca_put_callback(). autosave Automatic parameter save and boot-time restore. saveData Saves scan data to files on an NFS-mounted disk. How to use std -------------- To use std, you must acquire and build EPICS base and other modules on which std depends. Here's a list of the modules and the version with which std is known to work. EPICS baseR3.13.7 or later 3.13 release mpf1-10 required for serial and GPIB support mpfGpib1-4 required for GPIB support mpfSerial1-4 required for serial support The records in std are documented separately. Here are some notes about the databases in std. Slits ----- Slits are supported by the database "2slit.db", intended to support two- leaf slit, and the medm displays 2slit*.adl and 4slit*.adl. The slit database makes the following assumptions about the two motors attached to the individual slit leaves: 1) Both of them have the same engineering units. 2) Their .VAL fields are in the same coordinate system. I.e., if the slit is closed, both motors have the same value. 3) The APS standard beamline coordinate system is used. Positive Z is the beam direction; positive Y is upward; positive X is outward from the storage ring. So then, if I open a slit, one motor's .VAL field increases and the other's decreases. The 2slit.db database allows users to move either the slit virtual motors or the actual motors, and it keeps all the readback values current regardless of how the actual motors got moved or recalibrated. But it does not automatically reset the slit *drive* values when the actual motors are used. This must be dome manually, using the "SYNC" button on the 2slit.adl display. Pressing this button causes the database to read the actual motor drive values and set the slit drive values accordingly. To recalibrate slit positions, press the "Set" button. This automatically presses the "Set" button of both motors the slit software talks to, and the user/dial offsets of those motors actually implement the recalibration. There is a new, experimental slit database in synApps which uses soft motor records as the user/client interface. This allows clients that know how to control a motor also to control a slit, with some limitations. We hope to use soft motor records in front of other positioners (e.g. monochromators, optical tables, insertion devices, and DAC channels) in the future. Optical tables -------------- Optical tables are controlled by a custom EPICS record (the "table" record), used in the database table.db and controlled via medm displays table*.adl. Table virtual motors behave in much the same way as do slit virtual motors. However, the table software does not use user/dial offsets in the underlying motor to implement recalibration (it can't, since it works through a nonlinear transform). Instead, the table maintains its own offsets for all of the six coordinated motions it implements. Pressing the "Set" button causes new table positions to modify the offsets instead of moving the table (which is exactly the way motor and slit calibration works). In addition to a "Sync" button, which reads motor positions and calculates the table positions from them, the table display has an "Init" button, which zeros all offsets before doing a "sync" operation. It also has a "Zero" button, which manipulates all the table offsets to make the current table positions zero without moving or recalibrating any motors. Monochromators -------------- Several varieties of crystal monochromators are supported in synApps: two constant-offset "channel-cut" monochromators, a high-resolution double-crystal monochromator, and a spherical-grating monochromator. Most are supported by databases paired with State Notation Language (SNL) programs, and several medm displays. The EPICS databases kohzuSeq.db, SNL program kohzuCtl.st, and medm displays kohzu*.adl (also kohzu*.gif) are involved in control of two varieties of high-heat-load monochromators. The EPICS database hrSeq.db, SNL program hrCtl.st, and medm displays hSeq*.adl are involbed in control of the high-resolution double-crystal monochromator. The spherical grating monochromator is supported by the database SGM.db and the displays SGM*.adl. Filters ------- The APS standard user filters combine several motors and solenoids to control the placement of filter material in the beam path. The databases filterMotor.db and filterLock.db, and the medm displays *filter*.adl are involved in this application. Basic run-time programming -------------------------- Impromptu coordinated motions and other bits of run-time programming are handled by what we call a "userCalc" (actually just a swait record with a nice Medm interface) or a "userTransform" (actually just a transform record with a nice medm interface). We normally load ten of these into each EPICS processor, and the users type in expressions to be evaluated, and link inputs and outputs, as needed to glue existing objects together to do what they want done at the moment. Here are some examples of the tasks that have been accomplished with userCalcs and userTransforms: - turn off hardware feedback control of a monochromator crystal when beam drops below a user-specified level. The userCalc monitored the EPICS PV that contains the value of the positron beam-current, and drove a DAC channel (used as a digital i/o bit) that enabled hardware feedback. - support the ubiquitous theta/two-theta coordination by slaving the two-theta motor's .VAL field to the theta motor's .VAL field. - talk to a motor through a nonlinear transformation, e.g., energy-to- Bragg-angle. - close slow feedback loops--e.g., to adjust a monochromator crystal to suppress third-order diffraction through the high-heat-load monochromator. (The epid record is a better choice in most applications.) - move multichannel-analyzer regions of interest automatically as the incident beam energy changes. - save and automatically subtract shutter-closed offsets from scaler data. String-expression support ------------------------- Run-time programming involving strings and/or numbers can be done with userStringCalcs, which resemble userCalcs closely, but differ in significant details. A package containing two stringCalcs and a generic serial record (called a "serial O/I block") is also available for run-time programming of simple serial-device support. There is also a GPIB O/I block. Sequence support ---------------- Run-time programming of sequences is possible using the sseq record and related medm displays yySseq.adl The sseq record differs from the seq record in base in that it supports strings as well as numbers. Multiple-step measurement ------------------------- Up to four measurement steps involving positioners, detectors, and end calculations (e.g., to support dichroism experiments) can be done with the 4step.db database and the related medm display, 4step.adl. The entire measurement sequence can be involved in a scan by treating the 4step database as you would treat the scaler or mca software. Autosave/restore ---------------- See autoSaveRestore.README saveData -------- saveData is a CA client that monitors sscan records and saves scan data to files on as NFS-mounted disk. The software is configured with the file iocBoot/iocxxx/saveData.req, which needs no special attention unless you want to specify modify the list of EPICS PV's whose values are to be saved with every data file. To do this, look for the string "[extraPV]" in the file, and edit the list of PV's immediately following that string. If an entry in this list contains only the PV name, saveData will describe the PV, in the data file, using the .DESC field of the record that contains that PV. If a string follows the PV name, saveData will use the string instead. The file format produced by saveData is documented in the file saveData_fileFormat.txt, and supported by several separately released tools for visualization and manipulation. =============================================================================== Tim Mooney (mooney@aps.anl.gov) Beamline Controls & Data Acquisition Group Advanced Photon Source 01/29/04