WHT-ISIS-7

WHT ISIS Polarisation Module
EPICS Software Design Document

V.E. Austin

Issue 1.1; 22/05/96

Royal Greenwich Observatory,
Madingley Road,
Cambridge CB3 0HJ

Telephone (01223) 374962
Fax (01223) 374700
Internet vea@ast.cam.ac.uk

1 Introduction

1.1 Purpose

This document describes the architectural and detailed design of the EPICS software used to control the ISIS polarisation module. The major EPICS software components are described here including the interfaces to the WHT system computer, the engineering mimic display and the ISISP hardware. The EPICS software has been designed in order to provide an upgrade path for the rest of the ISIS spectrograph. This upgrade path is required so that the existing 4MS microprocessor system may be eventually replaced by the EPICS based IOC used for the control of the ISIS polarisation module.

The intended readership of this document is those who wish to understand the ISIS polarisation module control system software design. Those users involved in the maintenance of the ISIS polarisation module control system at the software level will also benefit from reading this document.

1.2 Definitions, acronyms and abbreviations

ADAM Astronomical Data Acquisition Monitor. The software environment used with the WHT system software.

dct Database configuration tool.

dm2 Display Manager. EPICS OPI tool.

edd2 Display Editor. EPICS OPI tool.

EGU Engineering Unit

EPICS Experimental Physics and Industrial Control System

I-task Instrumentation task. An ADAM control task using ADAM v2 software. An I- task may directly control a device or may co-ordinate a number of other tasks.

ICL Interface Command Language

IOC I/O Controller. The VME crate containing the 68000 microprocessor board in which the EPICS database resides.

ISIS Intermediate-dispersion Spectrograph and Imaging System

OPI Operator Interface Tool

VME Versa Module Eurocard

VxWorks 68000 microprocessor-based real time operating system.

WHT William Herschel Telescope

1.3 References

"WHT ADAM/EPICS Interface" P. Martin, C. Mayer, P. Tayler July 1994

WHT-ISIS-5 "WHT ISIS Polarisation Module SRD" V. Austin, August 1995

WHT-ISIS-6 "WHT ISIS Polarisation Module VAX Software ADD" A. Johnson, December 1995

"EPICS IOC Application Developer's Guide" M. Kraimer, November 1994

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994

"OPI Users Manual" P. Stanley 1995

2 System Overview

The function of the ISIS polarisation module is to allow ISIS to be used as a spectropolarimeter, capable of measuring linear and circular polarisation. The polarisation module consists of two identical mechanisms. These mechanisms are the half-wave polarisation plate which is generally used for linear polarisation, and the quarter-wave plate generally used for circular polarisation. To use either of these mechanisms, the waveplate must be inserted into the beam where it can either be set to a specified angle or rotated continuously.

2.1 Processor Functions

The ISISP Control System (ICS) is divided between three processors:-

1. Real-time control of the ISIS polarisation module is maintained by the ISISP IOC, a VME rack-based system containing an MV147 Motorola 68030 CPU card. The ISISP IOC is electronically connected directly to the mechanisms comprising the polarisation module. Control of these mechanisms is provided by a memory resident EPICS database.

2. The engineering interface is implemented as an X-windows application (called dm2, supplied as part of EPICS) running under UNIX on a SUN workstation. The engineering interface allows graphical display and complete control of records in the polarisation module.

3. The user interface for astronomical use is provided by software running on the WHT system computer, a VAX housed in the WHT control room. The ICS is integrated into the instrument control system and has interfaces to the WHT mimic.

All three processors are connected via ethernet which forms part of the WHT infrastructure, and communicate using TCP/IP protocols.

2.2 Control Interfaces

All control interface between the above processors are implemented using the EPICS Channel Access network protocol over TCP/IP network connections. This gives UNIX and VAX client software the ability to read, modify and monitor values associated with named database records in any connected IOC. A standard mechanism interface has been developed for use at the WHT. This interface uses Channel Access to communicate mechanism command and status information between the VAX software and the EPICS software running on the IOC.

The observer's interface is implemented using ICL and an ADAM I-task and is described in WHT-ISIS-6. An observer issuing an ISISP command via ICL causes an ADAM message to be sent to the ISISP I-task requesting that an ADAM action be carried out. The I-task responds by sending commands to the IOC as necessary to implement the requested action. When all ISISP actions have completed, or when failure is detected, a status report is made to the observer's terminal. The status of the ISISP mechanisms is continuously available to the observer on a page of the observer's mimic system.

2.3 Physical Processor Model

The following diagram

shows the complete ISISP control system, identifying the three separate physical processors used and the dataflows between them. This document describes the EPICS software running on the processor labelled "ISISP_IOC" and the dm2 engineering display running on the processor labelled "SUN_Client_Engineering_MIMIC_and_Control".

3 Project Standards, Conventions and Procedures

3.1 Project Standards

The software described here together with its associated documentation is written in accordance with an RGO-approved subset of the ESA software engineering standards ESA-PSS-05-0 Issue 2.

3.2 Naming Conventions

The naming convention that has been adopted for all EPICS records is of the form:-
isisp:<mechname>:<rectype>

The polarisation module is required to be used for circular polarisation, necessitating the positions of the two waveplates to be physically swapped (i.e. the half waveplate is placed in the top mounting and vice-versa). In order for the I-task to maintain the mount positions of the waveplates, the EPICS software will refer to the waveplate mechanisms as the top and bottom waveplates. These mechanisms will have names beginning pt or pb. The I-task will be responsible for mapping mechanisms names starting with phw or pqw to the correct mechanism.

3.3 Software Development Tools

The EPICS database will be designed using CAPFAST, a schematic editor, as a graphical dct (database configuration tool). The schematic diagram representing the database will be hierarchical. A hierarchical schematic contains symbols which represent entire sub-schematics. Configuring the database using CAPFAST provides a simple, visual method of linking the records in the database together, thus defining the processing chains.

The CAPFAST schematic is converted into an EPICS short report file using build_db. The build_db script executes sch2edif which converts schematics to edif file format, followed by e2sr which converts edif files into EPICS short report ascii file format. The database translation process is described in the following diagram.

The engineering mimic display is produced and implemented using the OPI (Operator Interface) tools edd2 (Display Editor) and dm2 (Display Manager) respectively. These tools are X-windows applications supplied as part of EPICS and are described in the OPI Users Manual. The Display Editor is used to create a display list file for the Display Manager. A display list file contains a list of static, monitor and control elements. Each monitor and control element has an associated process variable. The Display Manager is a Channel Access tool which reads one or more display list files created by edd2; establishes communication with all necessary IOCs; establishes monitors on process variables; accepts operator control requests; and updates the display to reflect all changes.

4 VAX-EPICS Control Interface

ISISP mechanisms are controlled, and their status read, via interface boards accommodated in a VME crate. Communication with and control of this hardware is performed by writing to and reading from an EPICS database which resides in the MV147 VME board, containing a 68030 microprocessor and running the VxWorks real-time kernel. Target systems running the VxWorks and EPICS are known as Input/Output Controllers or IOCs.

The first implementation of the VAX-EPICS Control Interface was produced for the WYFFOS spectrograph. This interface has been revised for use within the ISISP control system and consists of the following components:-

z The EPICS database. This consists of sets of records, each set corresponding to a single ISISP mechanism. A standard set of records has been defined which provide the data required to monitor and control a mechanism. These records are described later in this document.

z EPICS subroutines. These routines run in the VxWorks system and are initiated by the processing of an EPICS multiple output subroutine (mosub) record which provides the subroutine escape mechanism. Each mosub record can call an initialisation subroutine and a processing subroutine. The EPICS subroutines used in the ISISP control system are written in the C programming language.

z EPICS Channel Access. This provides access to the EPICS database by communicating between the control host ( in this case a VAX running the VMS operating system) and the target VxWorks system where the EPICS database resides. Using channel access any values in the EPICS database may be read, written and monitored ( so that any significant change will cause a specified routine to be called). Channel access is implemented on the host using calls to the Channel Access subroutine library, which uses the TCP/IP protocol to perform reliable communication between the host and the IOC.

4.1 ISISP mechanism control categories

The VAX-EPICS interface defines records for all control and status information required when using ISISP. ISISP mechanisms have different functionality which is reflected in the EPICS database records needed to support it. Three classes of mechanism have been identified whose control and status information is required by an I-task. Many mechanisms do not support direct control from an I-task. A further distinction can be made between mechanisms that may report error conditions and those which only provide feedback of the current position. The three classes of mechanism are as follows:-

1. Control. These mechanisms can be moved at the request of the I-task and thus require the full set of EPICS interface records.

2. Position and status. These mechanisms will report an error condition when a value goes out of range. The EPICS interface for each such mechanism need only provide the current position, mechanism status and error description.

3. Position only. These mechanism need only report their current position/state with no defined error condition. The EPICS interface for each such mechanism provides only the current position.

4.2 EPICS Database Interface record types

Individual EPICS primitive records do not in themselves support the concept of command verification or signalling on completion of action. EPICS records give the means to read or write values in a hardware interface and allow monitoring of, and trigger alarms from, the values in the record. To implement commands of the form used in the control of other WHT instruments, a standard set of EPICS database records has been defined that allows mechanism control, command input and verification and mechanism movement monitoring, as well as providing necessary information for status display and monitoring. Every ISISP mechanism that can be directly controlled by the user has this set of standard records defined in the ISISP EPICS database. Other mechanisms that are not controlled directly have a more restricted set of EPICS interface records.

The following table gives the record name, EPICS record type, range or set of values that the value field of the record can take, and a description of the records usage within the ISISP control system. Subsequent sections define the type, range and use for some of the records in more detail.

4.2.1 Comm Record

The comm record contains the function to be carried out. Functions may be one of MOVE, DATUM, STOP or UPDATE. These functions act on mechanisms controlled by the EPICS database and are defined as follows:-

z MOVE. This function corresponds to a command which drives a mechanism to a new state or position. The demand record contains the required value for the mechanism's desired state or position.

z DATUM. This function corresponds to a command to drive the mechanism to a datum switch which is used as a calibration marker for an encoder, and thus re-calibrates the encoder against its absolute position.

z STOP. This function corresponds to a command to stop a currently ongoing mechanism motion. This can only be used with a mechanism which takes an appreciable amount of time to complete a movement.

z UPDATE. This function is used when a status update is required and this update requires an ADAM action to initiate some processing in the ISISP IOC. This function is only applicable to those mechanisms that do not continuously keep their status updated.

4.2.2 Demand Record

The demand record contains the requested mechanism position or state. Two different types of record can be used for the demanded value:-In the case of a mechanism with a discrete set of states (eg ON or OFF), the demand record is a Multibit Binary Output (mbbo) with a set of fields each defining the string corresponding to each valid state. Where an integer position (eg microns) is used the the record is a Long Output (longout). The record has fields (HOPR and LOPR) which are used to hold the upper and lower limits for the range of movement for the mechanism.

4.2.3 Commstat Record

This is the command validation status and is used to report the status returned after a command has been received and (where possible) its value and parameters have been checked. A separate record is utilized to allow specific monitoring of changes in this record by the host system via Channel Access. For example, if the command parameters are out of range or an illegal command has been specified then this value will contain an error value. When the command processing has completed and the command accepted as valid then the value is Done (zero). Other values (greater than 0) indicate a command error.

4.2.4 Commstr Record

The commstr record contains a string returned by the ISISP IOC describing any error for the last command issued. This string is displayed to the user by the ISISP I-task whenever a command fails with a command error.

4.2.5 Clstat Record

This is the client status record which is used to enable the progress of a mechanism command to be monitored by the control program (I-task) on the host via Channel Access. While the mechanism is inactive or the command itself is being verified then its value is DONE (zero); after an input command has been verified and before the mechanism activity begins, the value is set to ACTIVE (1). When the mechanism activity ends (whether successfully completed or not) then the value reverts to DONE. No error values are set in this record - the mechstat record is used for this purpose.

4.2.6 Mechstat Record

This contains the current status of the mechanism itself. This will be OK (zero) when the mechanism is inactive and there is no error to report. It will be set to TIMEOUT (= 2) if the mechanism has not completed its movement within the specified period. Positive values in the range 1-127 signify that a mechanism error has occurred and in the range 128-255 signify a warning. The table below shows the mechanism errors and associated error strings supported by the VAX-EPICS interface:-

4.2.7 Errstr Record

The errstr record contains a string returned by the ISISP IOC describing the current mechanism error. This string is displayed to the user by the I-task whenever a mechanism error occurs.

4.2.8 Current Record

The current record contains the current position of the mechanism. The record type corresponds to the demand record so that a mechanism with discrete states will have a current record of type mbbi and a mechanism with a range of integer values will have a current record of type longin.

4.2.9 Timeout Record

The timeout record contains the value (in seconds) representing the maximum period that the ISISP I-task will wait before terminating the command and returning a timeout error status. This record is writeable and so can be adjusted dynamically for engineering purposes.

4.3 Position only mechanisms

Position only mechanisms are the simplest type used, requiring only to maintain the current record type. The diagram below

shows the interfaces for position only mechanisms.

ISISP position only mechanisms are listed as follows:-

4.4 Position and status mechanisms

These mechanism types maintain two mechanism status records as well as the current position record. This is achieved using a Mechanism Control subroutine called by a subroutine record to update the mechanism status (mechstat) and associated error string (errstr), depending on the value of current. The diagram

below shows the interfaces for position and status type mechanisms.

ISISP position and status type mechanisms are shown below:-

4.5 Controlled mechanisms

Controlled mechanisms can perform operations at the request of a user across Channel Access, as shown in the diagram

below:-

The user can write to the comm and demand records only. Firstly the demand record must contain the position or state required (if relevant). The action required (MOVE, UPDATE, DATUM or STOP) must then be written to the comm record. This event causes the ISISP Command subroutine to process, called by a mosub record. The ISISP Command subroutine validates the demand and command, the result being either a successful validation or a command error.

If a command error occurs, commstat and commstr are updated with the relevant error code and string and no further action takes place.

On successful validation the demand is copied to the lastdemand record and comm is copied to the lastcomm record. The accept record is set to ACCEPTED (1) indicating to the ISISP Mechanism Control subroutine that a validated command is ready. The commstat and commstr records are also set to DONE (0) and "Accepted - Ok" respectively, indicating that the command was successfully validated.

The ISISP Mechanism Control subroutine processes periodically. When this record processes, if accept has been set to 'ACCEPTED` then clstat is set to ACTIVE. indicating that an operation is active. Accept is reset to 'DONE` so that a new command can be validated. The requested operation is performed and on completion clstat is reset to 'DONE'.

The mechstat and errstr records are updated with the outcome of the operation by the Mechanism Control subroutine, whether successful or not. The current record is updated on change using the I/O Interrupt database scanning mechanism which processes records based on external interrupts.

The timeout record contains the maximum time an operation can take. If this time is exceeded, the operation is aborted and an error given. This record is given its value by the application developer.

ISISP control type mechanisms are listed below:-

5 Internal EPICS Interface Definitions

The internal EPICS interface consists of the EPICS database, described using CAPFAST schematic diagrams and EPICS subroutines. These routines run in the VxWorks system and are initiated by the processing of an EPICS multiple output subroutine or mosub record which provides the subroutine escape mechanism. Each mosub record can call an initialisation subroutine and a processing subroutine. Mosub output links are only processed after the subroutine has returned to the record processing routine. The EPICS subroutines used in the ISISP control system are written in the C programming language (listings in Appendix A).

5.1 ISISP Command Interface

The ISISP Command subroutine is used to perform command validation for controlled mechanisms. The comm record is forward linked to the ISISP Command subroutine record so that any write to this record will start execution of the ISISP Command code.

5.1.1 ISISP Command Flow Chart

The ISISP Command subroutine will process each time the comm record is written to. This is achieved by forward linking the comm record to the mosub type record calling the ISISP Command subroutine. The validation logic used is described in the following section. The accept record is used as a signalling mechanism to indicate to an ISISP Mechanism Control subroutine that a validated command is ready for execution. The flow chart for the ISISP Command subroutine is shown below:-

5.1.2 Validation Logic

Command validation is dependent on three records - comm, demand and clstat. The table below shows all possible combinations of record values and the resultant action.

5.2 ISISP Mechanism Control

The ISISP Mechanism Control subroutines are used to perform validated operations on the ISISP mechanisms. Mechanism Control subroutines are only required for controlled mechanisms and position and status mechanisms. Position only type mechanisms do not require EPICS subroutine code because the current position can be read directly from a record attached to the relevant hardware address.

5.2.1 Sol52 Subroutine Description

The only function implemented for mechanisms controlled by the sol52 subroutines is the MOVE function. The sol52 subroutines comprise of an initialisation subroutine which is called on record initialisation, and a process subroutine which is called periodically. The initialise subroutine sets clstat to DONE, mechstat to OK and errstr to "Ok". The flow diagram for the process subroutine is shown below:-

The process subroutine tests for two possible states. The first state tested for is the command validated/mechanism inactive state where clstat is DONE and accept is ACCEPTED. This state is reached by a MOVE command being successfully validated. The second state is the mechanism active state (clstat is ACTIVE, accept is DONE) which checks for completion of the slide action. This process is shown in the flow chart below.

The slide action is defined to be finished if the mechanism reaches the demanded position within the timeout period. If the mechanism fails to reach the demanded position within this time then an approriate error message is set depending on the reason for failure.

5.2.2 Angle Subroutine Description

The functions implemented for mechanisms controlled by the angle subroutines are MOVE, DATUM and STOP. The angle subroutines consist of an initialisation subroutine which is on record initialisation, and a process subroutine which is called periodically. The initialise subroutine sets clstat to DONE, mechstat to OK and errstr to "Ok". The flow chart for the process subroutine is shown below.

The process subroutine tests for four possible states. The first state tested is the command validated/mechanism inactive state where clstat is DONE and accept is ACCEPTED. This state is reached by either a MOVE or DATUM command being validated. The second state is the command validated/mechanism active state where clstat is ACTIVE and accept is ACCEPTED. This state is reached either from the first state or by a STOP command being validated. The command validated/mechanism active state calls the Start angle action process which is described in a separate flow chart shown below. The third state is the mechanism active state (clstat is ACTIVE, accept is DONE) which calls the Check angle action complete process shown below in another flow chart. The fourth state is the idle state where both clstat and accept are DONE, in which outputs linked to a stepper motor record are reset to zero.

The start angle action process sets outputs linked to a stepper motor record, depending on the issued command. The stepper motor record fields controlled are the HOMF (home forward), VAL (desired position) and STOP fields. Before either a MOVE or DATUM command is carried out, a check is done to ensure that the clamp is off to avoid mechanical damage. If the clamp is on or if a STOP command has been issued then the action is completed and the mechanism status is updated.

The Check angle complete process tests for completion of MOVE and DATUM commands. If the mechanism does not reach the demanded or datum position (if a MOVE or DATUM command respectively has been issued) within a defined time, then the action will abort and a timeout error is reported. When the mechanism does achieve the desired position within the timeout period, the clamp is enabled if the desired position is either one of the critical angles (every 225 EGUs where an EGU is 0.1 degrees) or the datum position.

5.2.3 Spin Subroutine Description

The only function implemented for mechanisms controlled by the spin subroutines is the MOVE function. The spin subroutines consist of an initialisation subroutine and a process subroutine.

The Start spin action process sets outputs linked to a stepper motor record depending on the demanded rotation rate. The stepper motor record fields controlled are the JOGF , VELO (Velocity EGU/s), and STOP fields. Before either a MOVE command is carried out, a check is done to ensure that the clamp is off to avoid mechanical damage.

The Check spin action complete process tests for completion of a MOVE command. If the mechanism does not either stop (if demanded rotation rate was 0 EGU/s) or start moving (if demanded rotation rate was greater than 0 EGU/s) within a defined time, then the action will abort and a timeout error is reported.

5.2.4 Status Subroutine Description

The mechanisms controlled by the status subroutine are position and status type mechanisms. These mechanisms do not perform actions on commands issued by an I-task. The status subroutines monitor the current position of a mechanisms and report mechanism status and error strings back to the I-task. The status subroutines comprise of an initialisation subroutine which is only run on startup, and a process subroutine. The initialise subroutine sets mechstat to OK and errstr to "Ok". The flow diagram for the process subroutine is shown below:-

6 Database Component Description

This section defines all the records for each ISISP mechanism. Records identified with CA i/f are part of the VAX/EPICS standard interface defined previously for position only type mechanisms, position and status type mechanisms and controlled mechanisms.

The records have been grouped together in logical sets relating to the schematic diagram on which they might be found (see Appendix B). For each set of records, the following aspects will be described:-

1. Type - logical and physical characteristics

2. Purpose - trace to the software requirements that it implements

3. Function - what the component does

4. Subordinates - components that are called by it or components that compose it

5. Dependencies - list of constraints placed upon its use by other components

6. Interfaces - how the component interacts with components that use it

7. Resources - what the component needs from its environment to perform its function

8. References - associated documentation

9. Processing - summary of the control and data flow within it

10. Data - internal data definition

Unless stated otherwise the default values for the type of record can be assumed. All standard records, together with their default vaules are described in the EPICS Record Reference Manual, with the exception of the mosub and motor records. These records are additional record types not supplied in the EPICS release. Documentation for the mosub record is not yet available (see author Andy Foster, RGO). The motor record is described in Appendix C.

Any defined links between records are shown in the schematics diagrams. All records linked together directly or indirectly using database links (Input, Output or Forward) are placed in the same lock set. When any member record of the lock set is processed, the entire set is locked and no new inputs are accepted into the lock set. This prevents two different tasks from simultaneously modifying records in the same lock set. Lock sets are determined at IOC initialisation.

6.1 Top Waveplate Slide

6.1.1 Type

EPICS record set. Created as schematic slide.sch using CAPFAST and converted to EPICS database format using build_db.

6.1.2 Purpose

Implements software requirments 2, 3, 11, 12, 13, 14.

6.1.3 Function

This record set is the database part of the top waveplate slide mechanism

6.1.4 Subordinates

The top waveplate slide record set calls a sub-schematic sol52.sch, represented by a symbol on the CAPFAST schematic. The other subordinates of this record set are the C subroutines activate.c and validate.c, called by their respective mosub records.

6.1.5 Dependencies

None.

6.1.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.1.7 Resources

None.

6.1.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.1.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.1.10 Data

Database isisp
Name isisp:ptslide:<rectype>

6.2 Top Waveplate 5/2 Solenoid (sol52) Sub-mechanism

6.2.1 Type

EPICS record set. Created as schematic sol52.sch using CAPFAST and converted to EPICS database format using build_db.

6.2.2 Purpose

Implements software requirments 2, 3, 11, 12, 13, 14.

6.2.3 Function

This record set is the database part of the 5/2 solenoid sub-mechanism

6.2.4 Subordinates

The subordinate of this record set is the C subroutine slide.c, called by the mosub record slide.

6.2.5 Dependencies

None.

6.2.6 Interfaces

The inputs to this record set are the validated command and demand values, the timeout value, the accept flag and clstat. The outputs from this record set are mechstat, errstr, current, accept and clstat.

6.2.7 Resources

None.

6.2.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.2.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.2.10 Data

Database isisp
Name isisp:ptslide:sol52:<rectype>

6.3 Top Waveplate Angle

6.3.1 Type

EPICS record set. Created as schematic angle.sch using CAPFAST and converted to EPICS database format using build_db.

6.3.2 Purpose

Implements software requirments 4, 5, 11, 12, 13, 14.

6.3.3 Function

This record set is the database part of the top waveplate angle mechanism

6.3.4 Subordinates

The top waveplate angle record set calls a sub-schematic smpm.sch, represented by a symbol on the CAPFAST schematic. The other subordinates of this record set are the C subroutines activate.c and validate.c, called by their respective mosub records.

6.3.5 Dependencies

A software interlock exists between the top angle and spin mechanisms. When the top angle mechanism is processing a command i.e. clstat is ACTIVE, then the top spin mechanism is prohibited from moving.

6.3.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.3.7 Resources

None.

6.3.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.3.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.3.10 Data

Database isisp
Name isisp:ptangle:<rectype>

6.4 Top Waveplate Stepper Motor Position Mode (smpm) Sub-mechanism

6.4.1 Type

EPICS record set. Created as schematic smpm.sch using CAPFAST and converted to EPICS database format using build_db.

6.4.2 Purpose

Implements software requirments 4, 5, 11, 12, 13, 14.

6.4.3 Function

This record set is the database part of the smpm sub-mechanism

6.4.4 Subordinates

The subordinate of this record set is the C subroutine angle.c, called by the mosub record angle.

6.4.5 Dependencies

None.

6.4.6 Interfaces

The inputs to this record set are the validated command and demand, the timeout value, the accept flag, clstat, clamp status, angle/spin interlock status and the ATHM, DMOV, MOVN, RBV and SET fields of the motor record. The outputs from this record set are the accept flag, clstat, clamp drive, mechstat, errstr, current, motor enable, and the VELO, VAL, STOP, HOMR, SET and DVAL fields of the motor record.

6.4.7 Resources

None.

6.4.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.4.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.4.10 Data

Database isisp
Name isisp:ptangle:smpm:<rectype>

6.5 Top Waveplate Spin

6.5.1 Type

EPICS record set. Created as schematic spin.sch using CAPFAST and converted to EPICS database format using build_db.

6.5.2 Purpose

Implements software requirments 6, 7, 8, 11, 12, 13, 14.

6.5.3 Function

This record set is the database part of the top waveplate spin mechanism

6.5.4 Subordinates

The top waveplate spin record set calls a sub-schematic smvm.sch, represented by a symbol on the CAPFAST schematic. The other subordinates of this record set are the C subroutines activate.c and validate.c, called by their respective mosub records.

6.5.5 Dependencies

A software interlock exists between the top angle and spin mechanisms. When the top spin mechanism is processing a command i.e. clstat is ACTIVE or is physically rotating, then the top angle mechanism is prohibited from moving.

6.5.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.5.7 Resources

None.

6.5.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.5.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.5.10 Data

Database isisp
Name isisp:ptspin:<rectype>

6.6 Top Waveplate Stepper Motor Velocity Mode (smvm) Sub-mechanism

6.6.1 Type

EPICS record set. Created as schematic smvm.sch using CAPFAST and converted to EPICS database format using build_db.

6.6.2 Purpose

Implements software requirments 6, 7, 8, 11, 12, 13, 14.

6.6.3 Function

This record set is the database part of the smvm sub-mechanism

6.6.4 Subordinates

The subordinate of this record set is the C subroutine spin.c, called by the mosub record spin.

6.6.5 Dependencies

None.

6.6.6 Interfaces

The inputs to this record set are the validated command and demand, the timeout value, the accept flag, clstat, clamp status, angle/spin interlock status and the ATHM, DMOV, MOVN, RBV and SET fields of the motor record. The outputs from this record set are the accept flag, clstat, clamp drive, mechstat, errstr, current, motor enable, and the VELO, JOGF, STOP, HOMR, SET and DVAL fields of the motor record.

6.6.7 Resources

None.

6.6.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.6.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.6.10 Data

Database isisp
Name isisp:ptspin:smvm:<rectype>

6.7 Top Waveplate Clamp

6.7.1 Type

EPICS record set. Created as schematic clamp.sch using CAPFAST and converted to EPICS database format using build_db.

6.7.2 Purpose

Implements software requirements 4, 11, 12, 13, 14.

6.7.3 Function

This record set is the database part of the top clamp sub-mechanism

6.7.4 Subordinates

None.

6.7.5 Dependencies

None.

6.7.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.7.7 Resources

None.

6.7.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.7.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.7.10 Data

Database isisp
Name isisp:ptclamp:<rectype>

6.8 Top Waveplate Motor

6.8.1 Type

EPICS record set. Created as schematic motor.sch using CAPFAST and converted to EPICS database format using build_db.

6.8.2 Purpose

Implements software requirements 4, 6, 7.

6.8.3 Function

This record set is the database part of the top motor sub-mechanism

6.8.4 Subordinates

None.

6.8.5 Dependencies

None.

6.8.6 Interfaces

The interfaces from this record set are the fields ATHM, DMOV, RBV and SET of the motor record.

6.8.7 Resources

None.

6.8.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.8.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.8.10 Data

Database isisp
Name isisp:ptmotor:<rectype>

6.9 Top Waveplate Connection

6.9.1 Type

EPICS record set. Created as schematic status.sch using CAPFAST and converted to EPICS database format using build_db.

6.9.2 Purpose

Implements software requirement 23.

6.9.3 Function

This record set is the database part of the top connector sub-mechanism

6.9.4 Subordinates

The subordinate of this record set is the C subroutine status.c, called by the mosub record status.

6.9.5 Dependencies

None.

6.9.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.9.7 Resources

None.

6.9.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.9.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.9.10 Data

Database isisp
Name isisp:ptconn:<rectype>

6.10 Bottom Waveplate Slide

6.10.1 Type

EPICS record set. Created as schematic slide.sch using CAPFAST and converted to EPICS database format using build_db.

6.10.2 Purpose

Implements software requirments 2, 3, 11, 12, 13, 14.

6.10.3 Function

This record set is the database part of the bottom waveplate slide mechanism

6.10.4 Subordinates

The bottom waveplate slide record set calls a sub-schematic sol52.sch, represented by a symbol on the CAPFAST schematic. The other subordinates of this record set are the C subroutines activate.c and validate.c, called by their respective mosub records.

6.10.5 Dependencies

None.

6.10.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.10.7 Resources

None.

6.10.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.10.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.10.10 Data

Database isisp
Name isisp:pbslide:<rectype>

6.11 Bottom Waveplate 5/2 Solenoid (sol52) Sub-mechanism

6.11.1 Type

EPICS record set. Created as schematic sol52.sch using CAPFAST and converted to EPICS database format using build_db.

6.11.2 Purpose

Implements software requirments 2, 3, 11, 12, 13, 14.

6.11.3 Function

This record set is the database part of the 5/2 solenoid sub-mechanism

6.11.4 Subordinates

The subordinate of this record set is the C subroutine slide.c, called by the mosub record slide.

6.11.5 Dependencies

None.

6.11.6 Interfaces

6.11.7 Resources

None.

6.11.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.11.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.11.10 Data

Database isisp
Name isisp:pbslide:sol52:<rectype>

6.12 Bottom Waveplate Angle

6.12.1 Type

EPICS record set. Created as schematic angle.sch using CAPFAST and converted to EPICS database format using build_db.

6.12.2 Purpose

Implements software requirments 4, 5, 11, 12, 13, 14.

6.12.3 Function

This record set is the database part of the bottom waveplate angle mechanism

6.12.4 Subordinates

The bottom waveplate angle record set calls a sub-schematic smpm.sch, represented by a symbol on the CAPFAST schematic. The other subordinates of this record set are the C subroutines activate.c and validate.c, called by their respective mosub records.

6.12.5 Dependencies

A software interlock exists between the bottom angle and spin mechanisms. When the bottom angle mechanism is processing a command i.e. clstat is ACTIVE, then the bottom spin mechanism is prohibited from moving.

6.12.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.12.7 Resources

None.

6.12.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.12.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.12.10 Data

Database isisp
Name isisp:pbangle:<rectype>

6.13 BottomWaveplate Stepper Motor Position Mode (smpm) Sub-mechanism

6.13.1 Type

EPICS record set. Created as schematic smpm.sch using CAPFAST and converted to EPICS database format using build_db.

6.13.2 Purpose

Implements software requirments 4, 5, 11, 12, 13, 14.

6.13.3 Function

This record set is the database part of the smpm sub-mechanism

6.13.4 Subordinates

The subordinate of this record set is the C subroutine angle.c, called by the mosub record angle.

6.13.5 Dependencies

None.

6.13.6 Interfaces

6.13.7 Resources

None.

6.13.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.13.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.13.10 Data

Database isisp
Name isisp:pbangle:smpm:<rectype>

6.14 Bottom Waveplate Spin

6.14.1 Type

EPICS record set. Created as schematic spin.sch using CAPFAST and converted to EPICS database format using build_db.

6.14.2 Purpose

Implements software requirments 6, 7, 8, 11, 12, 13, 14.

6.14.3 Function

This record set is the database part of the bottom waveplate spin mechanism

6.14.4 Subordinates

The bottom waveplate spin record set calls a sub-schematic smvm.sch, represented by a symbol on the CAPFAST schematic. The other subordinates of this record set are the C subroutines activate.c and validate.c, called by their respective mosub records.

6.14.5 Dependencies

A software interlock exists between the bottom angle and spin mechanisms. When the bottom spin mechanism is processing a command i.e. clstat is ACTIVE or is physically rotating, then the bottom angle mechanism is prohibited from moving.

6.14.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.14.7 Resources

None.

6.14.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.14.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.14.10 Data

Database isisp
Name isisp:pbspin:<rectype>

6.15 Bottom Waveplate Stepper Motor Velocity Mode (smvm) Sub-mechanism

6.15.1 Type

EPICS record set. Created as schematic smvm.sch using CAPFAST and converted to EPICS database format using build_db.

6.15.2 Purpose

Implements software requirments 6, 7, 8, 11, 12, 13, 14.

6.15.3 Function

This record set is the database part of the smvm sub-mechanism

6.15.4 Subordinates

The subordinate of this record set is the C subroutine spin.c, called by the mosub record spin.

6.15.5 Dependencies

None.

6.15.6 Interfaces

The inputs to this record set are the validated command and demand, the timeout value, the accept flag, clstat, clamp status, angle/spin interlock status and the ATHM, DMOV, MOVN, RBV and SET fields of the motor record. The outputs from this record set are the accept flag, clstat, clamp drive, mechstat, errstr, current, motor enable, and the VELO, JOGF, STOP, HOMR, SET and DVAL fields of the motor record.

6.15.7 Resources

None.

6.15.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.15.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.15.10 Data

Database isisp
Name isisp:pbspin:smvm:<rectype>

6.16 Bottom Waveplate Clamp

6.16.1 Type

EPICS record set. Created as schematic clamp.sch using CAPFAST and converted to EPICS database format using build_db.

6.16.2 Purpose

Implements software requirements 4, 11, 12, 13, 14.

6.16.3 Function

This record set is the database part of the bottom clamp sub-mechanism

6.16.4 Subordinates

None.

6.16.5 Dependencies

None.

6.16.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.16.7 Resources

None.

6.16.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.16.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.16.10 Data

Database isisp
Name isisp:pbclamp:<rectype>

6.17 Bottom Waveplate Motor

6.17.1 Type

EPICS record set. Created as schematic motor.sch using CAPFAST and converted to EPICS database format using build_db.

6.17.2 Purpose

Implements software requirements 4, 6, 7.

6.17.3 Function

This record set is the database part of the bottom motor sub-mechanism

6.17.4 Subordinates

None.

6.17.5 Dependencies

None.

6.17.6 Interfaces

The interfaces from this record set are the fields ATHM, DMOV, RBV and SET of the motor record.

6.17.7 Resources

None.

6.17.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.17.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.17.10 Data

Database isisp
Name isisp:pbmotor:<rectype>

6.18 Bottom Waveplate Connection

6.18.1 Type

EPICS record set. Created as schematic status.sch using CAPFAST and converted to EPICS database format using build_db.

6.18.2 Purpose

Implements software requirement 23.

6.18.3 Function

This record set is the database part of the bottom connector sub-mechanism

6.18.4 Subordinates

The subordinate of this record set is the C subroutine status.c, called by the mosub record status.

6.18.5 Dependencies

None.

6.18.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.18.7 Resources

None.

6.18.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.18.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.18.10 Data

Database isisp
Name isisp:pbconn:<rectype>

6.19 VME Fan Fail

6.19.1 Type

EPICS record set. Created as schematic status.sch using CAPFAST and converted to EPICS database format using build_db.

6.19.2 Purpose

Implements software requirement 23.

6.19.3 Function

This record set is the database part of the VME fan fail sub-mechanism

6.19.4 Subordinates

The subordinate of this record set is the C subroutine status.c, called by the mosub record status.

6.19.5 Dependencies

None.

6.19.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.19.7 Resources

None.

6.19.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.19.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

EPICS record set. Created as schematic status.sch using CAPFAST and converted to EPICS database format using build_db.

6.19.10 Data

Database isisp
Name isisp:vmefan:<rectype>

6.20 VME Thermal Status

6.20.1 Type

EPICS record set. Created as schematic status.sch using CAPFAST and converted to EPICS database format using build_db.

6.20.2 Purpose

Implements software requirement 23.

6.20.3 Function

This record set is the database part of the VME thermal status sub-mechanism

6.20.4 Subordinates

The subordinate of this record set is the C subroutine status.c, called by the mosub record status.

6.20.5 Dependencies

None.

6.20.6 Interfaces

The VAX-EPICS interface records are marked CA i/f.

6.20.7 Resources

None.

6.20.8 References

"EPICS Record Reference Manual" J. Anderson, M. Kraimer January 1994.

6.20.9 Processing

If the SCAN field of a record is the default value, Passive, then the record processing is defined by the processing links shown in the CAPFAST schematics of the previous section.

6.20.10 Data

Database isisp
Name isisp:vmetherm:<rectype>

7 Engineering Mimic Display

The ISISP engineering mimic display allows direct engineering control of ISISP hardware components, simulation of VAX commands acting on ISISP mechanisms, and display of mechanisms status. The engineering mimic display was created using edd2 and run using dm2. Dm2 uses the display list (.dl) files configured by edd2 to establish connections to channels indirectly through channel access and to display the value of these channels along with the static elements of the display. Channel values are updated as necessary by dm2. Detailed instructions on how to use these OPI tools are available in the OPI User Manual.

In order to minimise the number of displays created, macro-substitution is used. This means that the same display lists may be used for both top and bottom mechanisms by supplying the display with different parameters. Dm2 supports macro-substitution by allowing macro replacement strings to replace every instance of the macro substitution variable at run time, from channel names to menu titles and text strings of text objects.

The values of records which can only be read by the VAX software are shown in white against a black background, while the values of the records which can be written to by the VAX software are shown in dark grey against a light grey background. Those records which can be written to by the VAX software are also modifiable via dm2 and are represented by either choice buttons or text entry objects.

A common object between the displays is a Kill Display object, named Previous Screen. This object exits or kills a display by clicking on it at run time, providing a quicker, easier alternative to the exit display object in DM's main menu.

7.1 Top-level ISISP Display, isisp.dl

7.1.1 Type

EPICS OPI edd2/dm2 display list.

7.1.2 Purpose

Implements software requirements 11, 13, 14.

7.1.3 Function

The top level display provides engineering monitoring and control of the polarisation module. This display shows the current status of both the ISISP mechanisms and the VME environment status, and calls related displays which provide further status information and mechanism control, using related display callup objects. A related display callup object is a menu with the names of up to eight displays.

7.1.4 Subordinates

The subordinate of this record set are the follwing displays:-

7.1.5 Dependencies

None.

7.1.6 Interfaces

None.

7.1.7 Resources

None.

7.1.8 References

"OPI User Manual" P. Stanley 1995.

7.1.9 Processing

Processing of this display is controlled by dm2 at run-time.

7.1.10 Data

The following table shows the dynamic objects i.e. monitors and controllers in isisp.dl, together with the title. Other static objects are not listed.

Display isisp.dl is shown below:-

7.2 Slide Mechanism Control Display, slide.dl

7.2.1 Type

EPICS OPI edd2/dm2 display list.

7.2.2 Purpose

Implements software requirements 11, 13, 14.

7.2.3 Function

Display slide.dl provides a VAX command interface, allowing VAX software to be simulated and ADAM commands to be issued to the slide mechanisms. This display also calls a related display which gives direct engineering control of the slide mechanisms hardware.

7.2.4 Subordinates

The subordinate of this record set are the follwing displays:-

7.2.5 Dependencies

None.

7.2.6 Interfaces

None.

7.2.7 Resources

None.

7.2.8 References

"OPI User Manual" P. Stanley 1995.

7.2.9 Processing

Processing of this display is controlled by dm2 at run-time.

7.2.10 Data

The following table shows the dynamic objects i.e. monitors and controllers in slide.dl, together with the title. When not specified the VAL field is assumed in the channel name.

Slide.dl is shown in the figure below.

7.3 Angle Mechanism Control Display, angle.dl

7.3.1 Type

EPICS OPI edd2/dm2 display list.

7.3.2 Purpose

Implements software requirements 11, 13, 14.

7.3.3 Function

Display angle.dl provides a VAX command interface, allowing VAX software to be simulated and ADAM commands to be issued to the angle mechanisms. This display also calls a related display which gives direct engineering control of the angle mechanisms hardware.

7.3.4 Subordinates

The subordinate of this record set are the follwing displays:-

7.3.5 Dependencies

None.

7.3.6 Interfaces

None.

7.3.7 Resources

None.

7.3.8 References

"OPI User Manual" P. Stanley 1995.

7.3.9 Processing

Processing of this display is controlled by dm2 at run-time.

7.3.10 Data

The following table shows the dynamic objects i.e. monitors and controllers in angle.dl, together with the title. When not specified the VAL field is assumed in the channel name.

Display angle.dl is shown below:-

7.4 Spin Mechanism Control Display, spin.dl

7.4.1 Type

EPICS OPI edd2/dm2 display list.

7.4.2 Purpose

Implements software requirements 11, 13, 14.

7.4.3 Function

Display spin.dl provides a VAX command interface, allowing VAX software to be simulated and ADAM commands to be issued to the spin mechanisms. This display also calls a related display which gives direct engineering control of the spin mechanisms hardware.

7.4.4 Subordinates

The subordinate of this record set are the follwing displays:-

7.4.5 Dependencies

None.

7.4.6 Interfaces

None.

7.4.7 Resources

None.

7.4.8 References

"OPI User Manual" P. Stanley 1995.

7.4.9 Processing

Processing of this display is controlled by dm2 at run-time.

7.4.10 Data

The following table shows the dynamic objects i.e. monitors and controllers in spin.dl, together with the title. When not specified the VAL field is assumed in the channel name.

Display spin.dl is shown below:-

7.5 Slide Engineering Control Display, slide_eng.dl

7.5.1 Type

EPICS OPI edd2/dm2 display list.

7.5.2 Purpose

Implements software requirements 11, 13, 14.

7.5.3 Function

Display slide_eng.dl provides direct engineering control of the spin mechanisms hardware. Engineering control overrides VAX control and all other software interlocks, so should be used with discretion.

7.5.4 Subordinates

None.

7.5.5 Dependencies

None.

7.5.6 Interfaces

None.

7.5.7 Resources

None.

7.5.8 References

"OPI User Manual" P. Stanley 1995.

7.5.9 Processing

Processing of this display is controlled by dm2 at run-time.

7.5.10 Data

The following table shows the dynamic objects i.e. monitors and controllers in slide_eng.dl, together with the title. When not specified the VAL field is assumed in the channel name.

7.6 Angle Engineering Display, angle_eng.dl

7.6.1 Type

EPICS OPI edd2/dm2 display list.

7.6.2 Purpose

Implements software requirements 11, 13, 14.

7.6.3 Function

Display angle_eng.dl provides direct engineering control of the angle mechanisms hardware. Engineering control overrides VAX control and all other software interlocks, so should be used with discretion. In addition, it is very important that the clamp mechanism is released before attempting to drive the motor directly so that mechanical damage is prevented.

7.6.4 Subordinates

None.

7.6.5 Dependencies

None.

7.6.6 Interfaces

None.

7.6.7 Resources

None.

7.6.8 References

"OPI User Manual" P. Stanley 1995.

7.6.9 Processing

Processing of this display is controlled by dm2 at run-time.

7.6.10 Data

The following table shows the dynamic objects i.e. monitors and controllers in angle_eng.dl, together with the title. When not specified the VAL field is assumed in the channel name.

7.7 Spin Engineering Display, spin_eng.dl

7.7.1 Type

EPICS OPI edd2/dm2 display list.

7.7.2 Purpose

Implements software requirements 11, 13, 14.

7.7.3 Function

Display spin_eng.dl provides direct engineering control of the spin mechanisms hardware. Engineering control overrides VAX control and all other software interlocks, so should be used with discretion. In addition, it is very important that the clamp mechanism is released before attempting to drive the motor directly so that mechanical damage is prevented.

7.7.4 Subordinates

None.

7.7.5 Dependencies

None.

7.7.6 Interfaces

None.

7.7.7 Resources

None.

7.7.8 References

"OPI User Manual" P. Stanley 1995.

7.7.9 Processing

Processing of this display is controlled by dm2 at run-time.

7.7.10 Data

The following table shows the dynamic objects i.e. monitors and controllers in spin_eng.dl, together with the title. When not specified the VAL field is assumed in the channel name.

Appendix A. `C' Subroutine Listings

Appendix B. CAPFAST Schematic Diagrams

1. isisp.sch

2. slide.sch

3. sol52.sch

4. clamp.sch

5. angle.sch

6. smpm.sch

7. spin.sch

8. smvm.sch

9. status.sch

10. motor.sch

Appendix C. Motor Record

The motor record is intended to support motors of all kinds, but currently supports only the Oregon Microsystems steppermotor controller. The record maintains two coordinate systems for motor position ("user" and "dial" coordinates); displays drive and readback values; enforces limits to motor motion and maintains those limits in both coordinate systems; displays the states of limit switches; can use a home switch; optionally takes out backlash in a user-defined direction; and provides a mechanism by which the user and other EPICS records can recalibrate the motor position in either coordinate system. The record also supports "tweak", "jog", and "home" motions, and supports both absolute and relative motions in user coordinates. Two "stop" switches are provided: a simple one for use by other records and by channel-access clients; and a more versatile one intended primarily for interactive use.

With one exception, all fields associated with the motor position and its derivatives take values in "engineering units", such as degrees; the engineering unit name is contained in the field EGU. Velocities are expressed in EGU's per second. The exception is accelerations, which are expressed as the number of seconds taken to accelerate from zero to full velocity.

The motor record can read motor position from the motor controller's readback register, from the motor controller's encoder register, or, via an EPICS input link, from any other EPICS record. While the motor is moving, the record can trigger an output link periodically, to send current readback information to other EPICS records. When a complete motion, possibly including backlash takeout, is finished, the record can trigger a forward link to process other EPICS records.The motor record can force its own drive fields to agree with the readback field, and it does this under a variety of circumstances. Therefore, if you are driving the motor record's VAL or DVAL field with the output of another record, and you want that record always to contain the same value as the motor record, you must forward link the motor record to a soft analog output record, and cause that AO record to grab the motor record's VAL or DVAL field and poke it into your record.

In addition to fields common to all record types (see the EPICS Record Reference Manual for these) the motor record has the fields described below. The "access" column below describes the behavior of the record when a channel-access client or a database link attempts to get/put a value to/from a particular field.

R = read only
R/W = read and write are allowed
R/W* = read and write are allowed; write triggers record processing if the record's SCAN field is set to "Passive".

The motor record is unlike most other EPICS records, in that its processing is neither "synchronous" nor "asynchronous" (as these terms are used in the EPICS Record Reference Manual). Currently, PACT is always FALSE after record processing has completed, even though a motor motion may be in progress. This means the record always responds to channel-access "puts", and so can be stopped or retargeted at any time.

-------------------------------------------------------------------------------------- CALIBRATION FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

OFF R/W "User Offset (EGU)" DBF_DOUBLE

The magnitude of the difference between user and dialvalues. The user is not expected to change this field.

DIR R/W* "User Direction" DBF_RECCHOICE

The sign of the difference between user and dial values.

SET R/W "Set/Use Switch" DBF_RECCHOICE

Toggle switch, used to redefine the motor's user and dial positions: When SET = 0 ("Use"), Put's to the user-coordinate drive field (VAL) cause the dial-coordinate drive field (DVAL) to change, and the motor to move. Put's to the dial-coordinate drive field (DVAL) cause the user-coordinate drive field (VAL) to change, and the motor to move.When SET = 1 ("Set"), Put's to the dial-coordinate drive field (DVAL) cause a new raw motor position to be loaded into the hardware without any change to the user-coordinate drive field (VAL). Put's to all other fields that would normally move the motor, change the user-coordinate drive field (VAL), and the offset between user and dial coordinates (the OFF field), with corresponding changes in the user-coordinate limit fields (HLM and LLM).

MRES R/W* "Motor Step Size (EGU)" DBF_FLOAT

Motor resolution, the distance or angle associated with a single motor step.

ERES R/W* "Encoder Step Size (EGU)" DBF_FLOAT

Encoder resolution, the distance or angle associated with a single encoder step.

RRES R/W "Readback Step Size (EGU)" DBF_FLOAT

Readback-device resolution, the distance or angle associated with a unit change in the number retrieved via the readback-location input link (RDBL).

RES R/W "Step Size (EGU)" DBF_FLOAT

The encoder or readback-devive resolution, as selected by the switched UEIP and URIP below.

UEIP R/W* "Use Encoder If Present" DBF_RECCHOICE

Switch: nonzero value tells the record to read the encoder (if the hardware indicates an encoder is present) and to ignore the value read back from the hardware's step-count register. This switch also directs the record to calculate destinations in relative, rather than absolute, terms, since the ratio of encoder counts to motor steps may not be a constant or may not have been specified correctly.

URIP R/W* "Use RDBL Link If Present" DBF_RECCHOICE

Switch: nonzero value tells the record to get the motor position from the readback-location link (if it contains valid EPICS link information) and to ignore values read back from the hardware's step-count and encoder registers. This switch also directs the record to calculate destinations in relative, rather than absolute, terms, since the ratio of readback-link units to motor steps may not be a constant or may not have been specified correctly.

TRAK R/W* "Make Readback = Value" DBF_RECCHOICE

Not implemented. Originally intended to support closed-loop control.

PREC R/W "Display Precision" DBF_SHORT

The number of digits to the right of the decimal that are to be displayed by MEDM and other channel-access clients.

EGU R/W "Engineering Units" DBF_STRING

String sent to channel-access clients who ask for engineering units.

-------------------------------------------------------------------------------------- MOTION-RELATED FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

VELO R/W "Velocity (EGU/s)" DBF_FLOAT

The speed, in engineering units per second, at which the motor is move after the acceleration phase of a motion is finished.

ACCL R/W "Seconds to Velocity" DBF_FLOAT

The length, in seconds, of the acceleration and deceleration phases of a motion. By default, the motor record requests hardware to produce a trapezoidal velocity profile. That is, the motor speed is to increase linearly with time, from zero to "VELO" EGU's per second in "ACCL" seconds. At the end of a motion, the speed is to decrease similarly to zero.

BDST R/W "BL Distance (EGU)" DBF_FLOAT

The distance, in engineering units, used for backlash takeout. The algorithm used for backlash takeout in moves to position "TARGET" follows:

1. If the motor is to move a distance greater than the magnitude of "BDST", or if the motor is to move in a direction opposite to the sign of "BDST", then the motor will move first to position (TARGET- BDST), at an acceleration specified by "ACCL" and speed "VELO", and then to position TARGET, at an acceleration specified by "BACC" and speed "BVEL".

2. If the motor is to move a distance smaller than the magnitude of "BDST", and if the motor is to move in the same direction as the sign of "BDST", then backlash is assumed already to have been taken out, and the motor will move to position "TARGET" at an acceleration specified by "BACC" and speed "BVEL".

BVEL R/W "BL Velocity (EGU/s)" DBF_FLOAT

The speed, in engineering units per second, at which the motor is move after the acceleration phase of a backlash-takeout motion is finished.

BACC R/W "BL Seconds to Veloc." DBF_FLOAT

The length, in seconds, of the acceleration and deceleration phases of a backlash-takeout motion. By default, the motor record requests hardware to produce a trapezoidal velocity profile. During backlash-takeout motions, the motor speed is to increase linearly with time, from zero to "BVEL" EGU's per second in "BACC" seconds. At the end of the motion, the speed is to decrease similarly to zero.

FRAC R/W "Move Fraction" DBF_FLOAT

This field is intended to support closed-loop control of pathological devices for which drive values are not expected to compare reproducibly with readback values. (Inchworms and other friction-driven devices are good examples: the number of steps taken by an inchworm motor is a very poor indicator of the distance it has travelled.) In a move from position "CURRENT" to position "TARGET", the motor record will ask hardware to move a distance FRAC*(TARGET-CURRENT). When that motion is complete, the record will request a motion of FRAC*(remaining distance), and so on.

MODE R/W "Operating Mode" DBF_RECCHOICE

This field has one of two values: "Position" (0) and "Velocity" (1). Velocity mode is not implemented.

RDBD R/W "Retry Deadband (EGU)" DBF_FLOAT

When the motor has finished a complete motion, possibly including backlash takeout, the motor record will compare its current location with the desired location. If the two differ by more than the magnitude of "RDBD", the motor will try again, as if the user had requested a move from the current location to the desired location. Only a limited number of retries will be performed (see RTRY), after which the record will put itself into the "Pause" state, using the SPMG (Stop/Pause/Move/Go) field.

RTRY R/W "Max retry count" DBF_SHORT

The maximum number of times the motor record will try again to move to a given desired location. When the retry limit is reached, the motor record will put itself into the "Pause" state, using the SPMG (Stop/Pause/Move/Go) field.

-------------------------------------------------------------------------------------- LINK-RELATED FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

OUT R "Output Specification" DBF_OUTLINK

This field specifies the hardware to be controlled.

RDBL R "Readback Location" DBF_INLINK

This field specifies the field (of this or any other EPICS record) from which the motor's current position is to be read when the field URIP (Use Readback If Present) has the value "Yes" (1). If this field does not contain a valid EPICS link, the URIP may as well have the value "No" (0).

DOL R "Desired Output Loc" DBF_INLINK

If this field contains a valid EPICS link, and the "OMSL" field has the value "Closed Loop" (1), then every time the the motor record is processed, it will get a value for the "VAL" field from the link and move to that location, ignoring all other drive fields. Closed-loop mode has not been tested extensively.

OMSL R/W "Output Mode Select" DBF_GBLCHOICE

If this field has the value "Closed Loop" (1), and the field "DOL" contains a valid EPICS link, then every time the the motor record is processed, it will get a value for the "VAL" field from the link and move to that location, ignoring all other drive fields. Closed-loop mode has not been tested extensively.

RLNK R "Readback OutLink" DBF_OUTLINK

If this field contains a valid EPICS link, then every time the motor record is processed, it will put the (engineering-unit) readback value "RBV" to that link.

-------------------------------------------------------------------------------------- LIMIT FIELDS
--------------------------------------------------------------------------------------

At present, changing limit fields so that limits are violated causes the motor to move to the violated limit. This behavior is likely to change in a later version of the motor record so that limit changes never cause the motor to move.

-------------------------------------------------------------------------------------- name access DCT prompt data type
--------------------------------------------------------------------------------------

HLM R/W* "User High Limit" DBF_FLOAT

The maximum allowed value of the "VAL" field. If "HLM" changes so that "VAL" is no longer less than "HLM", then the motor will move until "VAL" is equal to "HLM". If the "DIR" field has the value "Pos", then "HLM" will always be consistent with "DHLM", otherwise "HLM" will always be consistent with "DLLM".

LLM R/W* "User Low Limit" DBF_FLOAT

The minimum allowed value of the "VAL" field. If "LLM" changes so that "VAL" is no longer greater than "LLM", then the motor will move until "VAL" is equal to "LLM". If the "DIR" field has the value "Pos", then "LLM" will always be consistent with "DLLM", otherwise "LLM" will always be consistent with "DHLM".

DHLM R/W* "Dial High Limit" DBF_FLOAT

The maximum allowed value of the "DVAL" field. If "DHLM" changes so that "DVAL" is no longer less than "DHLM", then the motor will move until "DVAL" is equal to "DHLM". If the "DIR" field has the value "Pos", then "DHLM" will always be consistent with "HLM", otherwise "DHLM" will always be consistent with "LLM".

DLLM R/W* "Dial Low Limit" DBF_FLOAT

The minimum allowed value of the "DVAL" field. If "DLLM" changes so that "DVAL" is no longer greater than "DLLM", then the motor will move until "DVAL" is equal to "DLLM". If the "DIR" field has the value "Pos", then "DLLM" will always be consistent with "LLM", otherwise "DLLM" will always be consistent with "HLM".

PERL R/W "Periodic Limits" DBF_RECCHOICE

Not implemented. Originally intended to support periodic "limits" on the "VAL" field (such as those associated with a rotation stage--e.g., [0...360] or [-180...180]) independently of the actual soft limits "HLM" and "LLM".

HOPR R/W "High Operating Range" DBF_FLOAT

Not used. See "HLM".

LOPR R/W "Low Operating Range" DBF_FLOAT

Not used. See "LLM".

HLS R "At High Limit Switch" DBF_SHORT

If this field is nonzero, then the motor is at the positive-limit switch, where the positive sense is that of the "VAL" field (i.e., user coordinates, rather than dial coordinates define the positive sense.)

LLS R "At Low Limit Switch" DBF_SHORT

If this field is nonzero, then the motor is at the negative-limit switch, where the negative sense is that of the "VAL" field (i.e., user coordinates, rather than dial coordinates define the negative sense.)

-------------------------------------------------------------------------------------- COMMAND "BUTTONS"
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

SPMG R/W* "Stop/Pause/Move/Go" DBF_RECCHOICE

This field is intended primarily for interactive use, and is expected normally to have the value "Go" (3). When the motor record detects trouble (e.g., too many unsuccessful retries to get to the desired location) it will set this field to "Pause" (1), which prevents the motor from moving in response to any other field.

If the user sets this field to "Stop" (0), the motor will (decelerate to a) stop, the "VAL" field will be set equal to the "RBV" field, and the "DVAL" field will be set equal to the "DRBV" field. These actions are intended to ensure that the motor does not start moving again until a drive field is changed. In any case, the motor will not move while "SPMG" has the value "Stop" (0) or "Pause" (1).

If "SPMG" has the value "Move" (2), the motor record will reset "SPMG" to "Pause" (1) as soon as a motion completes. This behavior is intended to support users who want a motor to sit still until they say "Move", no matter what changes occur in the drive fields.

LSPG R/W* "Last SPMG" DBF_RECCHOICE

Previous value of the SPMG field. For internal use by the motor record, this field should not be writable.

STOP R/W* "Stop" DBF_SHORT

When this field is set to 1, it will immediately be reset to 0, and the motor will (decelerate to a) stop. When the motor has stopped, "VAL" will be set equal to "RBV", and "DVAL" will be set equal to "DRBV". This behavior is intended to ensure that the motor remains stopped at least until a drive field is changed.

HOMF R/W* "Home Forward" DBF_SHORT

When this field is set to 1, the motor will decelerate to a stop if already moving, move in the positive direction (in dial coordinates) at the acceleration specified by "ACCL" and a speed of 1000 motor pulses per second, until the hardware detects the "home" switch has become active. Then the hardware will do something hardware dependent in response to its "home" command, if any. (The OMS hardware immediately stops sending motor pulses.) When the motor stops, the "VAL" field will be set equal to the "RBV" field, and the "DVAL" field will be set equal to the "DRBV" field.

HOMR R/W* "Home Reverse" DBF_SHORT

Same as "HOMF", but in the other direction.

JOGF R/W* "Jog motor Forward" DBF_SHORT

When this field is set to 1, the motor will decelerate to a stop if already moving, and move in the positive direction (in user coordinates) at an acceleration specified by "ACCL" and speed "VELO" until the "JOGF" field goes to 0. Then the motor will set "VAL" to "RBV" and "DVAL" to "DRBV", decelerate to a stop, and execute a (backlash-corrected, if "BDIST" is nonzero) move to the position at which "JOGF" went to 0.

JOGR R/W* "Jog motor Reverse" DBF_SHORT

Same as "JOGF", but in the other direction.

TWF R/W* "Tweak motor Forward" DBF_SHORT

When this field is set to 1, it will immediately be reset to 0, and the motor will move (with backlash takeout if "BDST" is nonzero) by a distance "TWV" (forward in user coordinates if "TWV" is positive) at an acceleration specified by "ACCL" and speed "VELO.

TWR R/W* "Tweak motor Reverse" DBF_SHORT

Same as TWF, but in the other direction.

TWV R/W* "Tweak Step Size (EGU)" DBF_FLOAT

This field contains the distance the motor is to move in response to "TWF" and "TWR" buttons.

-------------------------------------------------------------------------------------- DRIVE FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

VAL R/W* "User Desired Value" DBF_DOUBLE

When this field is written to, "DVAL" will be changed correspondingly, and the motor will move (with backlash takeout if "BDST" is nonzero) to the newly written position.

DVAL R/W* "Dial Desired Value" DBF_DOUBLE

When this field is written to, "VAL" will be changed correspondingly, and the motor will move (with backlash takeout if "BDST" is nonzero) to the newly written position.

RLV R/W* "Relative Value" DBF_DOUBLE

When this field is changed, its value will be added to "VAL", the field itself will immediately be reset to 0, and the motor record will behave as though the "VAL" field had been changed directly.

-------------------------------------------------------------------------------------- STATUS FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

RBV R "User Readback Value" DBF_DOUBLE

The current motor position, in user coordinates, from the motor hardware (default), or from the encoder supported by the motor-controller hardware (if "UEIP" is nonzero), or from the readback link "RLNK" (if "URIP" is nonzero).

DRBV R "Dial Readback Value" DBF_DOUBLE

The current motor position, in dial coordinates, from the motor hardware (default), or from the encoder supported by the motor-controller hardware (if "UEIP" is nonzero), or from the readback link "RLNK" (if "URIP" is nonzero).

DMOV R "Done moving to value" DBF_SHORT

This field is set to 0 when the motor record begins a motion, and remains 0 (through any retries and backlash corrections that may be required) until the motor record has completely finished that motion, whereupon the field is set to 1.

MOVN R "Motor is moving" DBF_SHORT

This field is set to 1 while the motor record believes that the motor is actually moving.

DIFF R "Difference dval-drbv" DBF_DOUBLE

The difference in engineering units between the desired motor position, and the readback device's report of the current position.

RRBV R "Raw Readback Value" DBF_DOUBLE

The current position of the motor, encoder, or readback link, as received from whatever source has been selected to provide position information. The units associated with this field depend on the source.

RMP R "Raw Motor Position" DBF_DOUBLE

The contents of the hardware's step-count register. This field contains the same information as the dial value, but in steps, rather than in engineering units.

REP R "Raw Encoder Position" DBF_DOUBLE

The contents of the hardware's encoder-count register. Ideally, this field contains the same information as the dial value, but in encoder counts, rather than in engineering units.

MSTA R "Motor Status" DBF_ULONG

The motor status as received from the hardware.

TDIR R "Direction of Travel" DBF_SHORT

The direction in which the motor is currently travelling (or was most recently travelling), as received from the hardware. If 0, the dial value should be decreasing.

ATHM R "At HOME" DBF_SHORT

The state of the hardware's "home" switch. If 1, the motor has hit the switch.

CVEL R "Constant Velocity" DBF_SHORT

Not used.

POSM R "Positive motion" DBF_SHORT

Not used.

RCNT R "Retry count" DBF_SHORT

The number of times the motor record has detected failure of the motor to land within the retry-deadband distance of the desired position.

MISS R "Ran out of retries" DBF_SHORT

If 1, the motor has failed to land on the desired position more than the allowed number of times. The motor record will have set the "SPMG" field to "Pause" (1).

-------------------------------------------------------------------------------------- ALARM FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

HIHI R/W* "Hihi Alarm Limit" DBF_FLOAT
LOLO R/W* "Lolo Alarm Limit" DBF_FLOAT
HIGH R/W* "High Alarm Limit" DBF_FLOAT
LOW R/W* "Low Alarm Limit" DBF_FLOAT
HHSV R/W* "Hihi Severity" DBF_GBLCHOICE
LLSV R/W* "Lolo Severity" DBF_GBLCHOICE
HSV R/W* "High Severity" DBF_GBLCHOICE
LSV R/W* "Low Severity" DBF_GBLCHOICE
HLSV R/W* "HW Lim. Violation Svr" DBF_GBLCHOICE

None of these fields are used, at present.

-------------------------------------------------------------------------------------- MONITOR-RELATED FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

MDEL R/W "Monitor Deadband" DBF_FLOAT
ADEL R/W "Archive Deadband" DBF_FLOAT

Not used.

-------------------------------------------------------------------------------------- PRIVATE FIELDS
--------------------------------------------------------------------------------------

name access DCT prompt data type
--------------------------------------------------------------------------------------

LVAL R "Last User Des Val" DBF_DOUBLE
LDVL R "Last Dial Des Val" DBF_DOUBLE
LRLV R "Last Rel Value" DBF_DOUBLE
ALST R "Last Value Archived" DBF_DOUBLE
MLST R "Last Value Monitored" DBF_DOUBLE
PP R "Post process command" DBF_SHORT
MIP R "Motion In Progress" DBF_SHORT
MMAP R "Monitor Mask" DBF_ULONG

Private.

Appendix A. Document history

Issue 0.1 06/10/95 First issue describing architectural design only.

Issue 1.0 12/02/95 Second issue incorporating comments and detailed design.

Issue 1.1 22/05/96 Third issue including latest software modifications.

WHT ISIS Polarisation Module EPICS Software Design Document

1 Introduction

2 System Overview

3 Project Standards, Conventions and Procedures

4 VAX-EPICS Control Interface

5 Internal EPICS Interface Definitions

6 Database Component Description

7 Engineering Mimic Display

WHT ISIS Polarisation Module
EPICS Software Design Document