SCP Principles of Operation

SLC CONTROL SYSTEM PRINCIPLES OF OPERATION March 21, 1994 Joanne Bogart Marty Breidenbach Jean Francois Gournay Keith Jobe Nan Phinney Dave Sherden Kathy Thompson Dan Yaffe

CONTENTS CHAPTER 1 DATABASE INTERNAL STRUCTURE AND MAINTENANCE

1.1 DATABASE SEMANTICS . . . . . . . . . . . . . . . . 1-1

1.1.1 PRIMARY.DBS . . . . . . . . . . . . . . . . . . 1-2

1.1.2 Supertypes . . . . . . . . . . . . . . . . . . . 1-3

1.1.3 Datastructure . . . . . . . . . . . . . . . . . 1-4

1.2 DATABASE SYNTAX . . . . . . . . . . . . . . . . . 1-5

1.2.1 Primary Definition . . . . . . . . . . . . . . . 1-5

1.2.2 Default Definition . . . . . . . . . . . . . . . 1-6

1.2.3 Data Definition . . . . . . . . . . . . . . . . 1-6

1.3 DATABASE STRUCTURE . . . . . . . . . . . . . . . . 1-7

1.3.1 Floating Point Formats . . . . . . . . . . . . 1-12 CHAPTER 2 8086 CAMAC INTERNALS

2.1 "NESTING" OF INTERNAL ROUTINES . . . . . . . . . . 2-3

2.1.1 CAMIO (Vax) . . . . . . . . . . . . . . . . . . 2-3

2.1.2 CAMIO (Micro) . . . . . . . . . . . . . . . . . 2-3

2.1.3 CAMALO (Vax & Micro) . . . . . . . . . . . . . . 2-4

2.1.4 CAMADD (Vax & Micro) . . . . . . . . . . . . . . 2-4

2.1.5 CAMGO (Vax) . . . . . . . . . . . . . . . . . . 2-4

2.1.6 CAMGO (Micro) . . . . . . . . . . . . . . . . . 2-4

2.1.7 CAMDEL (Vax & Micro) . . . . . . . . . . . . . . 2-4

2.1.8 CAMFAG (Vax) . . . . . . . . . . . . . . . . . . 2-5

2.1.9 CAMFAG (Micro) . . . . . . . . . . . . . . . . . 2-5

2.1.10 CAMMOD (Vax & Micro) . . . . . . . . . . . . . . 2-5

2.1.11 CAMALO_RESET (Vax & Micro) . . . . . . . . . . . 2-5

2.1.12 CAMEXIT (Vax Only) . . . . . . . . . . . . . . . 2-5

2.2 CAMAC DATA STRUCTURES . . . . . . . . . . . . . . 2-6

2.2.1 Camac Package Structure . . . . . . . . . . . . 2-6

2.2.1.1 Control Block Structure . . . . . . . . . . . 2-7

2.2.1.2 MBCD Packet Structure . . . . . . . . . . . . 2-8

2.2.1.3 EMASK Storage . . . . . . . . . . . . . . . . 2-8

2.2.2 VAX-VMS To MICRO Message Structure . . . . . . . 2-9

2.2.3 MICRO To VAX-VMS Message Structure . . . . . . 2-10

2.3 ROUTINES . . . . . . . . . . . . . . . . . . . . 2-11

2.3.1 CAMIO . . . . . . . . . . . . . . . . . . . . 2-11

2.3.2 CAMIO_V . . . . . . . . . . . . . . . . . . . 2-12

2.3.3 CAMALO . . . . . . . . . . . . . . . . . . . . 2-12

2.3.4 CAMAL1 . . . . . . . . . . . . . . . . . . . . 2-12

2.3.5 CAMADD . . . . . . . . . . . . . . . . . . . . 2-13

2.3.6 CAMAD1 . . . . . . . . . . . . . . . . . . . . 2-13

2.3.7 CAMGO (Micro) . . . . . . . . . . . . . . . . 2-14

2.3.8 CAMGO (Vax) . . . . . . . . . . . . . . . . . 2-14

2.3.9 CAMGO_R (Vax) . . . . . . . . . . . . . . . . 2-15

2.3.10 CAMGO_V . . . . . . . . . . . . . . . . . . . 2-15

2.3.11 CAMMOD . . . . . . . . . . . . . . . . . . . . 2-16

2.3.12 CAMALO_RESET . . . . . . . . . . . . . . . . . 2-16

2.3.13 CAMEXIT . . . . . . . . . . . . . . . . . . . 2-16

2.3.14 CAMVMAIN . . . . . . . . . . . . . . . . . . . 2-17

2.3.15 CAMAC_DRVR (Micro) . . . . . . . . . . . . . . 2-17

CHAPTER 3 BPM SOFTWARE INTERNALS

3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . 3-1

3.1.1 Hardware . . . . . . . . . . . . . . . . . . . . 3-2

3.1.2 Functions Available From SCP . . . . . . . . . . 3-3

3.1.2.1 Calibration . . . . . . . . . . . . . . . . . 3-3

3.1.2.2 Measurement . . . . . . . . . . . . . . . . . 3-4

3.1.2.3 Diagnostics . . . . . . . . . . . . . . . . . 3-5

3.1.3 Basic Protocol For Calibration And Measurement . 3-6

3.2 SCP CODE . . . . . . . . . . . . . . . . . . . . . 3-8

3.2.1 Panels . . . . . . . . . . . . . . . . . . . . . 3-8

3.2.2 Driver Routine (BPMDRVR) . . . . . . . . . . . . 3-9

3.2.3 Measurement Definitions . . . . . . . . . . . 3-10

3.2.3.1 Rationale . . . . . . . . . . . . . . . . . 3-12

3.2.3.2 Setting Parameters (BPMDRVR, BPM_RANGE, Entries BPM_AUTORANGE, . . . . . . . . . . . 3-13

3.2.3.3 Manipulating Measurement Definitions . . . . 3-14

3.2.3.3.1 Creation . . . . . . . . . . . . . . . . . 3-14

3.2.3.3.2 Selection . . . . . . . . . . . . . . . . 3-15

3.2.3.3.3 Saving And Restoring Measurement Definitions . . . . . . . . . . . . . . . 3-15

3.2.4 Calibration Routines (BPMCAL, BPMCAL_*) . . . 3-16

3.2.4.1 Calibratione Downloading (BPMCAL_DOWNLOAD) . 3-19

3.2.5 Data Accumulation (BPMDATON And Entries BPMDAT, BPMDATOFF) . . . . . . . . . . . . . . . . . . 3-20

3.2.6 Data Display (BPMDISP, BPMDISPZ, BPMDISPV) . . 3-21

3.2.7 Data Accumulation For Applications (BPM_AVG) . 3-22

3.2.8 Coroutines And Status Routine . . . . . . . . 3-23

3.2.9 Diagnostics . . . . . . . . . . . . . . . . . 3-24

3.2.9.1 TIMING (BPMSYNC) . . . . . . . . . . . . . . 3-24

3.2.9.2 Single Unit Functions . . . . . . . . . . . 3-24

3.2.10 Clean-up (BPMUNLOCK, BPMSTOP, BPMCANDEF) . . . 3-24

3.2.11 Miscellany . . . . . . . . . . . . . . . . . . 3-24

3.2.11.1 Logical Name Initialization (BPMINIT) . . . 3-24

3.2.11.2 Damping Ring Lifetime Display (BPM_DRLIFE) . 3-24

3.2.11.3 Damping Ring Ungated Read . . . . . . . . . 3-24

3.3 MICRO . . . . . . . . . . . . . . . . . . . . . 3-24

3.3.1 Over-all Control Structure (BPMO_DRVR) . . . . 3-24

3.3.2 Structure And Handling Of Beam Segments (relevant Parts Of . . . . . . . . . . . . . 3-25

3.3.3 Initialization (BPMINIT) . . . . . . . . . . . 3-25

3.3.4 Common Elements Of Calibration And Measurement: 3-25

3.3.4.1 Hardware Checks (PDU_CHECK, ONLINE, Re-get Relevant HSTAs) . . . . . . . . . . . . . . 3-25

3.3.4.2 Preparation (set Up Timing And Reading Camac Packages; TIMEPACK, BPMPACK) . . . . . . . . 3-25

3.3.5 Calibration (CALBPREP, BEAMSEG$INIT, MUXSET, CALBPROC, . . . . . . . . . . . . . . . . . . 3-25

3.3.6 Measurement (MEASPREP, BEAMSEG$PREP, ATTENPACK, BEAMSEG$PROC) . . . . . . . . . . . . . . . . 3-25

3.3.7 Clean-up (BEAMSEG$STOP, BEAMSEG$DEL, BPMCAN) . 3-25

3.3.8 Miscellany: . . . . . . . . . . . . . . . . . 3-25

3.3.8.1 Communication Between Fortran And PLM (MISSING_LINK) . . . . . . . . . . . . . . . 3-26

3.3.8.2 Initialize When Crate Goes On (BPMPINIT) . . 3-26

3.4 (APPENDIX) DATABASE . . . . . . . . . . . . . . 3-26

3.5 (APPENDIX) OTHER DATA STRUCTURES . . . . . . . . 3-26

3.5.1 Calibration Files . . . . . . . . . . . . . . 3-26

3.5.2 Measurement Definition Files . . . . . . . . . 3-27

3.6 (APPENDIX) FUNCTION CODES (WITH FORM OF DATA) . 3-27

3.7 (APPENDIX) ROUTINES . . . . . . . . . . . . . . 3-27

3.7.1 Alphabetical, With Description Of Arguments . 3-27

3.7.2 By Function (who Calls Whom) . . . . . . . . . 3-27

3.8 (APPENDIX) DATABASE . . . . . . . . . . . . . . 3-27 CHAPTER 4 TIMING SYSTEM

4.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . 4-1

4.1.1 THE PROGRAMMABLE DELAY UNIT (PDU) . . . . . . . 4-2

4.1.2 The T_MATRIX And Timing Data Structures . . . . 4-4

4.1.3 Pulse Class Devices (PCD'S) . . . . . . . . . . 4-5

4.1.3.1 PSU . . . . . . . . . . . . . . . . . . . . . 4-6

4.1.3.2 PAU . . . . . . . . . . . . . . . . . . . . . 4-6

4.1.4 DUPCD'S . . . . . . . . . . . . . . . . . . . . 4-6

4.1.5 Software Control Of Timing Devices . . . . . . 4-7

4.1.5.1 SCP . . . . . . . . . . . . . . . . . . . . . 4-7

4.1.5.2 Micro . . . . . . . . . . . . . . . . . . . . 4-7

4.1.5.3 BDL . . . . . . . . . . . . . . . . . . . . . 4-8

4.2 GENERATION OF THE T_MATRIX (TGEN) . . . . . . . . 4-9

4.3 TIMING-RELATED PANELS . . . . . . . . . . . . . 4-10

4.3.1 Master Timing Panel . . . . . . . . . . . . . 4-11

4.3.2 Individual-sector Trigger Panels . . . . . . . 4-11

4.3.3 DUPCD Displays Panel . . . . . . . . . . . . . 4-13

4.3.4 Klystron Control Panels . . . . . . . . . . . 4-14

4.3.5 Diagnostics Panel . . . . . . . . . . . . . . 4-15

4.4 MAJOR SUBROUTINES IN THE SCP . . . . . . . . . . 4-15

4.4.1 T_MATRIX_ADJUST . . . . . . . . . . . . . . . 4-15

4.4.2 TIME_BTN_HANDLER . . . . . . . . . . . . . . 4-16

4.4.3 T_MATRIX_KNOB . . . . . . . . . . . . . . . . 4-16

4.4.4 KTRG_PNL . . . . . . . . . . . . . . . . . . . 4-17

4.4.5 DEVICE_ACTIVE_DISP . . . . . . . . . . . . . . 4-17

4.4.6 TIMING_DISP . . . . . . . . . . . . . . . . . 4-17

4.4.7 DEVICE_TIME_DISP . . . . . . . . . . . . . . . 4-17

4.4.8 TIME_DIAGNOSTICS_PANL . . . . . . . . . . . . 4-18

4.4.9 PDUXPGM, PDU_GETDELAY, PDU_GETPP, PDU_READ_PDU, And PDU_READ_STB . . . . . . . . . . . . . . . 4-18

4.4.10 BEAM_DISPLAY . . . . . . . . . . . . . . . . . 4-18

4.4.11 BCOD_PNL And BCOD_DISP . . . . . . . . . . . . 4-18

4.5 BASE RATE TRIGGERS (TRBR'S) . . . . . . . . . . 4-18

4.6 THE VERNIER DELAY UNIT (VDU) . . . . . . . . . . 4-20

4.7 TRIGGER GATE AND SYNCHRONIZER (TGAS) . . . . . . 4-22

4.7.1 Details Of Algorithm . . . . . . . . . . . . . 4-22

4.8 TIME JOB IN THE MICRO . . . . . . . . . . . . . 4-24

4.8.1 Downloading Of T_MATRIX Data . . . . . . . . . 4-25

4.8.2 Initialization Of PDU's . . . . . . . . . . . 4-26

4.8.2.1 Initialization Of The PAU . . . . . . . . . 4-29

4.8.2.2 Initialization Of The PSU . . . . . . . . . 4-29

4.8.3 Updating PDU's, PAU's, And PSU's . . . . . . . 4-30

4.8.3.1 Updating The PDU . . . . . . . . . . . . . . 4-30

4.8.3.2 Updating The PAU . . . . . . . . . . . . . . 4-31

4.8.3.3 Updating For The PSU . . . . . . . . . . . . 4-31

4.8.4 Pattern Interrupt Handler . . . . . . . . . . 4-31 CHAPTER 5 BEAM DEFINITION LANGUAGE (BDL)

5.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . 5-1

5.1.1 BEAM . . . . . . . . . . . . . . . . . . . . . . 5-2

5.1.2 T_MATRIX . . . . . . . . . . . . . . . . . . . . 5-2

5.1.3 DUPCD . . . . . . . . . . . . . . . . . . . . . 5-2

5.1.4 PCD . . . . . . . . . . . . . . . . . . . . . . 5-3

5.1.5 BIT-ID . . . . . . . . . . . . . . . . . . . . . 5-4

5.2 COMMANDS . . . . . . . . . . . . . . . . . . . . . 5-4

5.2.1 SET . . . . . . . . . . . . . . . . . . . . . . 5-4

5.2.1.1 /BEAM . . . . . . . . . . . . . . . . . . . . 5-5

5.2.1.2 /NOMINAL . . . . . . . . . . . . . . . . . . . 5-5

5.2.2 SHOW . . . . . . . . . . . . . . . . . . . . . . 5-6

5.2.2.1 /BEAM . . . . . . . . . . . . . . . . . . . . 5-6

5.2.2.2 /NOMINAL . . . . . . . . . . . . . . . . . . . 5-6

5.2.2.3 /DEVICE . . . . . . . . . . . . . . . . . . . 5-6

5.2.2.4 /T_MATRIX . . . . . . . . . . . . . . . . . . 5-7

5.2.2.5 /KLYSTRONS . . . . . . . . . . . . . . . . . . 5-8

5.2.3 PRINT . . . . . . . . . . . . . . . . . . . . . 5-8

5.2.3.1 /T_MATRIX . . . . . . . . . . . . . . . . . . 5-8

5.2.3.2 /NOMINAL . . . . . . . . . . . . . . . . . . . 5-9

5.2.3.3 /KLYSTRONS . . . . . . . . . . . . . . . . . . 5-9

5.2.4 ACTIVATE . . . . . . . . . . . . . . . . . . . 5-10

5.2.4.1 /OFFSET . . . . . . . . . . . . . . . . . . 5-10

5.2.4.2 /ABSOLUTE . . . . . . . . . . . . . . . . . 5-10

5.2.5 DEACTIVATE . . . . . . . . . . . . . . . . . . 5-11

5.2.6 ACCELERATE . . . . . . . . . . . . . . . . . . 5-11

5.2.6.1 /END . . . . . . . . . . . . . . . . . . . . 5-12

5.2.6.2 /GAIN . . . . . . . . . . . . . . . . . . . 5-12

5.2.6.3 /BACKPHASE . . . . . . . . . . . . . . . . . 5-12

5.2.6.4 /SLED . . . . . . . . . . . . . . . . . . . 5-13

5.2.7 STANDBY . . . . . . . . . . . . . . . . . . . 5-13

5.2.8 COPY . . . . . . . . . . . . . . . . . . . . . 5-13

5.2.8.1 /NOMINAL . . . . . . . . . . . . . . . . . . 5-14

5.2.9 LOADBEAM . . . . . . . . . . . . . . . . . . . 5-14

5.2.10 EXIT . . . . . . . . . . . . . . . . . . . . . 5-14 CHAPTER 6 LARGE POWER SUPPLY CONTROLLER

6.1 HARDWARE DESCRIPTION . . . . . . . . . . . . . . . 6-1

6.1.1 Individually Shunted Magnets . . . . . . . . . . 6-1

6.1.2 Series Magnets . . . . . . . . . . . . . . . . . 6-2

6.2 DATABASE STRUCTURE . . . . . . . . . . . . . . . . 6-3

6.2.1 Large Power Supply Controller . . . . . . . . . 6-3

6.2.2 Individually Shunted Magnets Controlled By An LGPS . . . . . . . . . . . . . . . . . . . . . . 6-4

6.2.2.1 Calibration: . . . . . . . . . . . . . . . . . 6-4

6.2.2.2 Standardization: . . . . . . . . . . . . . . . 6-5

6.2.2.3 Check And Trim: . . . . . . . . . . . . . . . 6-5

6.2.3 Series Magnets Without Individual Control . . . 6-5

6.3 CAMAC COMMANDS . . . . . . . . . . . . . . . . . . 6-6

6.3.1 Addresses And Function Codes . . . . . . . . . . 6-6

6.3.2 Analog Output In The Micros: . . . . . . . . . . 6-6

6.3.3 Analog Input In The Micros: . . . . . . . . . . 6-6

6.4 ON/OFF/REVERSE CONTROL . . . . . . . . . . . . . . 6-7

6.4.1 Control Structure . . . . . . . . . . . . . . . 6-7

6.4.2 Error Checking: . . . . . . . . . . . . . . . . 6-7

6.4.3 Camac Functions: . . . . . . . . . . . . . . . . 6-8

6.4.4 LGPSCNTL Procedure: . . . . . . . . . . . . . . 6-9

6.4.5 BULKCNTL Procedure . . . . . . . . . . . . . . 6-11

6.4.6 DEGAUSS Subroutine . . . . . . . . . . . . . . 6-12

6.5 MAGNET CONTROL IN THE MICROS . . . . . . . . . . 6-13

6.5.1 Initialization . . . . . . . . . . . . . . . . 6-13

6.5.2 Magnet Control . . . . . . . . . . . . . . . . 6-13

6.5.3 Calibration . . . . . . . . . . . . . . . . . 6-14

6.5.4 Standardization . . . . . . . . . . . . . . . 6-15

6.5.5 Check And Trim . . . . . . . . . . . . . . . . 6-16

6.5.6 LGPSCHK . . . . . . . . . . . . . . . . . . . 6-16 CHAPTER 7 STEPPING MOTOR CONTROL

7.1 HARDWARE DESCRIPTION . . . . . . . . . . . . . . . 7-1

7.2 DATABASE STRUCTURE . . . . . . . . . . . . . . . . 7-2

7.3 CONTROL FUNCTIONS IN THE MICRO . . . . . . . . . . 7-3

7.3.1 Calibration . . . . . . . . . . . . . . . . . . 7-3

7.3.2 Check And Trim . . . . . . . . . . . . . . . . . 7-4

7.3.3 Perturb . . . . . . . . . . . . . . . . . . . . 7-4

7.3.4 Home . . . . . . . . . . . . . . . . . . . . . . 7-4

7.3.5 Reset . . . . . . . . . . . . . . . . . . . . . 7-5

7.4 CONTROL AND DISPLAY FUNCTIONS IN THE VAX . . . . . 7-5

7.4.1 Control Functions . . . . . . . . . . . . . . . 7-5

7.4.2 Adjust Knobs . . . . . . . . . . . . . . . . . . 7-5

7.4.3 Checkout Knobs . . . . . . . . . . . . . . . . . 7-6

7.4.4 Displays . . . . . . . . . . . . . . . . . . . . 7-6

7.5 SOFTWARE DETAILS IN THE MICRO . . . . . . . . . . 7-6

7.5.1 DACSET(Unit,Dac_value,Ptrbflag) . . . . . . . . 7-7

7.5.2 READADC(Type,Waitflag) . . . . . . . . . . . . . 7-8

7.5.3 SAMRESET() . . . . . . . . . . . . . . . . . . . 7-8

7.5.4 DACZERO() . . . . . . . . . . . . . . . . . . . 7-8

7.5.5 CALIBALL(Type) . . . . . . . . . . . . . . . . . 7-9 CHAPTER 8 SOFTWARE TO CONTROL GENERALIZED ANALOG KNOBS

8.1 PRESENT SOFTWARE . . . . . . . . . . . . . . . . . 8-1

8.2 PROPOSED MODIFICATIONS . . . . . . . . . . . . . . 8-3

8.3 PROBLEMS AND COMMENTS . . . . . . . . . . . . . . 8-5 CHAPTER 9 DIGITAL STATUS CONTROL SYSTEM

9.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . 9-1

9.1.1 Digital Output Devices . . . . . . . . . . . . . 9-2

9.1.2 States . . . . . . . . . . . . . . . . . . . . . 9-2

9.1.3 Modes . . . . . . . . . . . . . . . . . . . . . 9-4

9.1.4 Example . . . . . . . . . . . . . . . . . . . . 9-4

9.2 DATA BASE STRUCTURE . . . . . . . . . . . . . . . 9-5

9.2.1 DODD - Digital Output Device Definition . . . . 9-6

9.2.1.1 NOB = # Output Bits. . . . . . . . . . . . . . 9-6

9.2.1.2 NIB = # Input Bits. . . . . . . . . . . . . . 9-7

9.2.1.3 NM = # Modes. . . . . . . . . . . . . . . . . 9-7

9.2.1.4 ESCR = User Escape Routine . . . . . . . . . . 9-7

9.2.1.5 PLSE = Pulse Or Level Specification. . . . . . 9-7

9.2.1.6 NSC = Number Of State Components . . . . . . . 9-8

9.2.1.7 NSV = Number Of State Component Values . . . . 9-8

9.2.1.8 NS = Total Number Of State Values. . . . . . . 9-8

9.2.1.9 OBSD = Output Bit State Definition . . . . . . 9-9

9.2.1.10 IBSD = Input Bit State Definition. . . . . . . 9-9

9.2.1.11 SEV = Severity Level X Log . . . . . . . . . . 9-9

9.2.1.12 DODU = DOD Primaries And Units . . . . . . . 9-10

9.2.2 DODN - Digital Output Device Names . . . . . . 9-10

9.2.2.1 DNAM = Device Type Name . . . . . . . . . . 9-11

9.2.2.2 DEVP = Primary . . . . . . . . . . . . 9-11

9.2.2.3 DODP = Device Primary Number . . . . . . . . 9-11

9.2.2.4 SCNM = State Component Names . . . . . . . . 9-11

9.2.2.5 SVNM = State Value Names . . . . . . . . . . 9-11

9.2.2.6 ONAM = Output Bit Names . . . . . . . . . . 9-12

9.2.2.7 INAM = Input Bit Names. . . . . . . . . . . 9-12

9.2.2.8 OLBL = Output Bit State Labels . . . . . . . 9-12

9.2.2.9 ILBL = Input Bit State Labels . . . . . . . 9-12

9.2.2.10 MNAM = Mode Names . . . . . . . . . . . . . 9-12

9.2.2.11 TRNT = Transition Times. . . . . . . . . . . 9-13

9.2.3 - Digital Output Device . . . . . . . . 9-13

9.2.3.1 ALNM = Alias Name . . . . . . . . . . . . . 9-13

9.2.3.2 UNIT = DODN, DODD, DOM Unit Numbers. . . . . 9-13

9.2.3.3 OBIT = Output Bit Numbers . . . . . . . . . 9-14

9.2.3.4 IBIT = DIM Unit And Input Bit Numbers . . . 9-14

9.2.3.5 CNTL = Control Word. . . . . . . . . . . . . 9-14

9.2.3.6 STAT = Status . . . . . . . . . . . . . . . 9-14

9.2.4 DOM - Digital Output Module . . . . . . . . . 9-15

9.2.4.1 OMTP = Output Module Type . . . . . . . . . 9-16

9.2.4.2 CTLW = CAMAC Control Word . . . . . . . . . 9-16

9.2.4.3 DATA = Data . . . . . . . . . . . . . . . . 9-16

9.2.4.4 STAT = CAMAC Status . . . . . . . . . . . . 9-16

9.2.5 DIM - Digital Input Module . . . . . . . . . . 9-16

9.2.5.1 CTLW = CAMAC Control Word . . . . . . . . . 9-17

9.2.5.2 DATA = Input Data . . . . . . . . . . . . . 9-17

9.2.5.3 STAT = CAMAC Status . . . . . . . . . . . . 9-17

9.2.6 Example: . . . . . . . . . . . . . . . . . . . 9-17

9.3 SEMI-CUSTOM USER PANELS . . . . . . . . . . . . 9-18

9.3.1 Example . . . . . . . . . . . . . . . . . . . 9-19

9.3.2 Panel Subroutines . . . . . . . . . . . . . . 9-20

9.3.3 DODUPNL Panel Variables . . . . . . . . . . . 9-20

9.3.4 DSTATDSP Variables . . . . . . . . . . . . . . 9-22 CHAPTER 10 DIGITAL STATUS INPUT SYSTEM

10.1 INTRODUCTION . . . . . . . . . . . . . . . . . . 10-1

10.1.1 Digital Input Devices . . . . . . . . . . . . 10-2

10.1.2 Severity Levels . . . . . . . . . . . . . . . 10-2

10.1.3 Modes . . . . . . . . . . . . . . . . . . . . 10-2

10.2 DATA BASE STRUCTURE . . . . . . . . . . . . . . 10-2

10.2.1 DIDD - Digital Input Device Definition . . . . 10-3

10.2.1.1 DEVP - Device Primaries . . . . . . . . . . 10-4

10.2.2 DIDN - Digital Input Device Names . . . . . . 10-4

10.2.2.1 NIB = # Input Bits. . . . . . . . . . . . . 10-4

10.2.2.2 NM = # Modes. . . . . . . . . . . . . . . . 10-4

10.2.2.3 DNAM = Device Type Name . . . . . . . . . . 10-4

10.2.2.4 DEVP = Primary . . . . . . . . . . . . 10-5

10.2.2.5 DIDP = Device Primary Number . . . . . . . . 10-5

10.2.2.6 INAM = Input Bit Names. . . . . . . . . . . 10-5

10.2.2.7 ILBL = Input Bit State Labels . . . . . . . 10-5

10.2.2.8 MNAM = Mode Names . . . . . . . . . . . . . 10-6

10.2.2.9 ESCR = User Escape Routine . . . . . . . . . 10-6

10.2.3 - Digital Input Device . . . . . . . . . 10-6

10.2.3.1 ALNM = Alias Name . . . . . . . . . . . . . 10-6

10.2.3.2 DIDN = DIDN Unit Number. . . . . . . . . . . 10-7

10.2.3.3 IBIT = DIM Unit And Input Bit Numbers . . . 10-7

10.2.3.4 SEVM = Severity Level Masks . . . . . . . . 10-7

10.2.3.5 CNTL = Control Word. . . . . . . . . . . . . 10-8

10.2.3.6 STAT = Status . . . . . . . . . . . . . . . 10-8

10.2.4 DIM - Digital Input Module . . . . . . . . . . 10-9

10.2.4.1 CTLW = CAMAC Control Word . . . . . . . . . 10-9

10.2.4.2 DATA = Input Data . . . . . . . . . . . . . 10-9

10.2.4.3 STAT = CAMAC Status . . . . . . . . . . . . 10-9

10.2.5 Example: . . . . . . . . . . . . . . . . . . . 10-9

10.3 SEMI-CUSTOM USER PANELS . . . . . . . . . . . . 10-10

10.3.1 Example . . . . . . . . . . . . . . . . . . . 10-11

10.3.2 Panel Subroutines . . . . . . . . . . . . . . 10-12

10.3.3 DIDUPNL Panel Variables . . . . . . . . . . . 10-12

10.3.4 DSTATDSP Variables . . . . . . . . . . . . . . 10-14 CHAPTER 11 ANALOG STATUS SYSTEM

11.1 INTRODUCTION . . . . . . . . . . . . . . . . . . 11-1

11.2 DATA BASE STRUCTURE . . . . . . . . . . . . . . 11-2

11.2.1 Primary Data Type ASDF . . . . . . . . . . . . 11-2

11.2.2 Primary Data Type ASTS . . . . . . . . . . . . 11-3 CHAPTER 12 CRATE MONITORING AND INITIALIZATION

12.1 INTRODUCTION . . . . . . . . . . . . . . . . . . 12-1

12.2 MONITORING CRATE STATUS . . . . . . . . . . . . 12-1

12.3 CRATE INITIALIZATION PROCEDURE . . . . . . . . . 12-2

12.4 CRATE VERIFICATION . . . . . . . . . . . . . . . 12-3 CHAPTER 13 THE CABLE VIDEO SOFTWARE.

13.1 FUNCTIONAL REQUIREMENTS. . . . . . . . . . . . . 13-1

13.1.1 The Cable Video Touch Panel. . . . . . . . . . 13-1

13.1.2 The Cable Video Database Records. . . . . . . 13-2

13.1.3 The Software Source Files. . . . . . . . . . . 13-3

13.2 SOFTWARE FUNCTIONAL DESIGN . . . . . . . . . . . 13-4

13.2.1 CAVMINIT . . . . . . . . . . . . . . . . . . . 13-4

13.2.2 CAVMBUTN . . . . . . . . . . . . . . . . . . . 13-4

13.2.2.1 Entry CAVMCHNS - Channel Select. . . . . . . 13-5

13.2.2.2 Entry CAVMMODS - Module Select. . . . . . . 13-5

13.2.2.3 Entry CAVMINPS - Input Select (Implicit Turn On). . . . . . . . . . . . . . . . . . . . . 13-6

13.2.2.4 Entry CAVMOFFC - Turn Off Channel. . . . . . 13-7

13.2.2.5 Entry CAVMOFFM - Turn Off Module. . . . . . 13-8

13.2.3 CAVMCAMAC . . . . . . . . . . . . . . . . . . 13-9

13.2.4 CAVMCAMER . . . . . . . . . . . . . . . . . . 13-10

13.2.5 CAVMUPDAT . . . . . . . . . . . . . . . . . . 13-12

13.2.6 CAVMDBUPD . . . . . . . . . . . . . . . . . . 13-13 CHAPTER 14 KLYSTRON SUPPORT

14.1 OVERVIEW . . . . . . . . . . . . . . . . . . . . 14-1

14.2 KLYSTRON TIMING -- HEURISTIC FUDGE FACTORS . . . 14-1

14.2.1 Delay Calculation . . . . . . . . . . . . . . 14-1

14.2.1.1 Delay Register . . . . . . . . . . . . . . . 14-2

14.2.1.2 Sample/Trigger Time . . . . . . . . . . . . 14-2

14.2.1.3 PDUT . . . . . . . . . . . . . . . . . . . . 14-3

14.2.1.4 TERR . . . . . . . . . . . . . . . . . . . . 14-3

14.2.1.5 HERR . . . . . . . . . . . . . . . . . . . . 14-3

14.3 MESSAGE SERVICE PROTOCOL . . . . . . . . . . . . 14-5

14.3.1 VAX-VMS To MICRO Message Structure . . . . . . 14-5

14.3.2 MICRO To VAX-VMS Message Structure . . . . . . 14-6

14.4 KLYSTRON FUNCTION CODES . . . . . . . . . . . . 14-7

14.5 SPECIAL SECRETS OF THE KLYSTRON JOB . . . . . . 14-9

14.5.1 KLYSDATA.INC . . . . . . . . . . . . . . . . . 14-9

14.5.2 KLYSUNITS.INC . . . . . . . . . . . . . . . . 14-9

14.5.3 FUNC2.INC . . . . . . . . . . . . . . . . . . 14-10 CHAPTER 15 A DEVICE DESCRIPTOR FOR CERTAIN APPLICATION PROGRAMS.

15.1 INTRODUCTION . . . . . . . . . . . . . . . . . . 15-1

15.2 DEVICE TYPES CURRENTLY USED . . . . . . . . . . 15-1

15.2.1 Summary . . . . . . . . . . . . . . . . . . . 15-2

15.3 A DATA ORGANISATION TO DESCRIBE THE VARIOUS DEVICE TYPES . . . . . . . . . . . . . . . . . . 15-3 CHAPTER 16 DEVICE ACCESS USING THE DEVICE DESCRIPTOR.

16.1 INTRODUCTION . . . . . . . . . . . . . . . . . . 16-1

16.2 CRITERIA . . . . . . . . . . . . . . . . . . . . 16-1

16.3 EVALUATION OF CRITERIA . . . . . . . . . . . . . 16-2

16.4 CONTENTS OF THE X DESCRIPTOR . . . . . . . . . . 16-2

16.4.1 Summary . . . . . . . . . . . . . . . . . . . 16-3

16.5 ALTERNATIVE SOLUTIONS AND RECOMMENDATION . . . . 16-3

16.6 DEVICE I/O USING THE DEVICE DESCRIPTOR. . . . . 16-4

16.6.1 Summary . . . . . . . . . . . . . . . . . . . 16-5

16.7 THE VALUE DESCRIPTOR . . . . . . . . . . . . . . 16-5

16.7.1 Valid I/O Operations For The Different Device Types. . . . . . . . . . . . . . . . . . . . . 16-6

16.8 ASSOCIATED CONSIDERATIONS FOR DEVICE I/O . . . . 16-6

16.9 UTILITY ROUTINES . . . . . . . . . . . . . . . . 16-7

16.10 ADDENDUM: SOFTWARE STATUS (JUNE 1985) . . . . . 16-8

16.11 SUGGESTIONS FOR FUTURE DEVELOPMENT . . . . . . . 16-9

CHAPTER 1 DATABASE INTERNAL STRUCTURE AND MAINTENANCE

1.1 DATABASE SEMANTICS This note is a gloss on Database Syntax. It is not intended as a primer. A term in the data base is fully identified by a four part name: PRIM,MICR,unit,SECN PRIM is a alphanumeric primary name describing a general device class. Examples are BPMO for beam position monitor, QUAD for quadrupole, XCOR for X correcting magnet and so forth. MICR is an alphanumeric name describing the "host" of the particular device in question. MICR is always of the form AAnn, where AA is alphabetic and nn is numeric. For example, in the linac each sector will have a micro-cluster and that cluster will be named LInn for sector nn, beginning with sector 01. Devices belonging to the VAX, e.g. a console, belong to VX01. The proposed set is:

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-2 PRnn Pep Ring region nn (reserved) SRnn Spear Ring control node nn (reserved) LInn Linac sector nn DRnn Damping Ring control sector nn IJnn InJector control node nn CAnn Collider Arc sector nn CInn Collider Intersection region control node nn BLnn Beam Line control node nn LOCL Special. Implicit reference to the local micro- cluster on which this code is executing unit is a formally arbitrary number representable in 16 bits. It is used as a counter of devices within a micro-cluster. Only the Linac has a convention at this time. Unit is a 2 decimal digit number of form ij. i is the linac girder number and j is the device count on that girder. j begins with 1 and increases with increasing z. A drift space belongs to the preceding girder. SECN is an alphanumeric symbolic secondary name representing some attribute of the device PRIM. SECN may refer to fixed or variable length blocks of integer, floating, or string data. Format conversion of data entered into database data files may be specified. Examples are IVBU ( I versus B going Up ) - a set of coefficients for a magnetization polynomial, PSNM for a fixed length power supply name, and STAT for a 32 bit integer bit collection.

1.1.1 PRIMARY.DBS The PRIM's are established along with the SECN's and their characteristics in the file PRIMARY.DBS. The nature and details of this file are the responsibility of the system designer, and changes in this file should be made only with the explicit consent of the designer. Nevertheless, this file is a source document for applications program design, and it ie expected to be well commented.

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-3 The PRIMARY file is the definitive document on what PRIM's and SECN's exist and what they mean. The database structure that is micro-cluster resident has a less symbolic structure than that used on the host to conserve space on the unpaged machines. Thus the PRIMARY file explicitly assigns a (normally) unique number to each PRIM which is called a catn or category number. (Perhaps it should have been called a primn. Tough) Also each SECN is a assigned a unique (unique only within a PRIM) subn or subtype number. Applications codes on the VAX pay no heed to catn's or secn's. Micro-cluster access routines will need them. Associated with each PRIM is a primary descriptor number. It has no meaning at this time and is reserved for future emergencies.

1.1.2 Supertypes Data are organized into large blocks called superblocks or supertypes. Five different supertypes are currently defined: 0 Pointer Block (Write Protected) 1 Stable Parameters Block (Write Protected) 2 To Micro-cluster (VAX Write only) 3 From Micro-cluster (VAX Read only) 4 Host only parameters (No micro access) Supertypes 0 through 3 are sent to the micro-cluster at IPL. Subsequently only supertype 2 is transmitted to the micro-cluster and only supertype 3 is received from it. (Arbitrary subsets of these blocks may be transmitted as well as the full blocks). The Pointer block was designed as a separate structure to allow it to be write protected and to decrease the overhead associated with moving data. The Stable parameters are usually those that are in the database data

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-4 files and do not normally change during the operation of the machine. (If they are changed, it will be necessary to re-IPL the micros.) The To block are control parameters for the micro that are loaded by the dbput routines and automatically sent to the relevant micros. The From block is data sent by the micros and is loaded into the database by the DBEX process. Supertype 4 is data associated with a device on a micro but which the micro does not need. Thus it is kept as a separate block to reduce wasted storage in the micro. Every SECN must belong to a supertype between 1 and 4, and this is specified in the PRIMARY file as the number supn.

1.1.3 Datastructure The datastructure associated with each SECN is specified in the PRIMARY as the word dstr. First, the datastructure may have a fixed or variable number of "words". In this context, a word is a 2 byte word, a 4 byte word, or a string. dstr begins either with a 4 decimal digit integer specifying the number of words, or a V meaning variable. Variable means the number of words may vary from device to device, but the data must be specified in the data base files as space is allocated at data base generation time. Fixed word data need not be mentioned in the data files and DBGEN will insert zeros. The next character in dstr is the format conversion control: I Fortran Integer conversion * R Floating Conversion (Fortran F or E) * Z Hexadecimal Conversion A Alphanumeric (NO OTHER SYMBOLS) S String (Anything at all inside double quotes)

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-5 * I and R conversion allow addition of entries in the data files. The next (and last) character in the dstr is a 2 or a 4 indicating the word size. R conversion must have 4 byte words. Strings ignore the word size and use as many 4 byte words as they need. Thus 2I4 specifies that space for exactly 2 4 byte words will be allocated, and that if data is specified at DBGEN, there must be exactly 2 Integer format words available.

1.2 DATABASE SYNTAX

1.2.1 Primary Definition <:PRIM:catn,prmd; SN;SN;....SN;> where: PRIM is 4 character alphanumeric primary name catn is integer category number prmd is integer primary descriptor and SN=:secn:subn,supn,dstr where: secn is 4 character alphanumeric secondary name subn is integer subtype number supn is integer supertype number 0

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-6

1.2.2 Default Definition <:DEFNAME: DN;DN;....DN;> where: DEFNAME is an alphanumeric name of 15 or fewer characters and DN=|:secn:=V,V,...V;| |@:REFNAME: | where: secn is a previously defined secondary name V is data consistent with the dstr associated with secn REFNAME is an alphanumeric name of 15 or fewer characters or: <%symbol=V;> where: symbol is an alphanumeric symbol of 8 or fewer characters and V is data as defined below.

1.2.3 Data Definition <:PRIM:MICR,unit; DD;DD;...DD;> where: PRIM is a previously defined primary name MICR = TTJJ is a micro cluster name TT is a 2 character alphabetic name JJ is a 2 digit integer unit is an integer unit number and DD=|:secn:=V,V,...V; | |@:REFNAME: | where: secn is a previously defined secondary name V is data consistent with the dstr associated with secn I : |+| nnnnn |-| | | R : |+| nn.nn {E|+|nn} |-| |-| | | | | Z : zzzzz

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-7 A : aann S : "anything at all but double quote" where: nnnn are from set {0123456789} zzzz are nnnn & {ABCDEF} aa are from {ABCDEFGHIJKLMNOPQRSTUVWXYZ} where: {} are set delimiters & is a set union symbol. REFNAME is a previously defined DEFNAME V may be of the form: V1 |+| V2 |+| V3 ... |-| |-| A V may be a previously defined symbol: %symbol Addition and subtraction of symbols as well as explicit data is permitted. or <%userexit> where: userexit is a 4 character alphanumeric symbol.

1.3 DATABASE STRUCTURE The database utilizes two basic structures, dbnodes and db. Dbnodes is an I*4 common array that describes the primary structure of the database. It consists of a three level structure that hash codes the prim on level 1, the secn*prim on level 2, and the micr on level 3. Db is an I*2 common array that is subdivided into five supertypes for each micro. The supertypes are the pointer block, parameter block,

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-8 'to' block, 'from' block and host block respectively. The first four blocks are transmitted to a micro at IPL. The pointer block contains all the pointers necessary to access the other blocks. The parameter block is stable data for the micro, being transmitted to the micro only at IPL. The 'to' block is transmitted to the micro whenever it is updated. The 'from' block is transmitted by the micro to the host. The host block contains data that is logically associated with the prim, but for which the micro has no need. The common block dbmng is used to manage space allocation to these blocks in /DB/. The size of DBNODES and DB is set by PARAMETER statements in the include file DATACOMM. Then DBINIT, DBMAP, and CRDB should be recompiled. DB, DBNODES, and DBMNG are permanent group mapped global sections. They are created by CRDB which must be run once after each system boot. If the block sizes are changed, the global sections must be deleted and CRDB rerun. Then DBGEN can be rerun. 'User' processes must get a new copy of DBMAP before they will work. Therefore, one should probably be rather generous in increasing block sizes so it will not be too frequent an occurrence. The DBNODES structure has two layers, the outer layer being the pointers described in the include file DBNODES (the following paragraph IS DBNODES), and the inner layer being the various list structures associated with each level. parameter (nlevm=3) common/dbnodes/lastloc,nlev,hshlen(nlevm),hshloc(nlevm), >hshcnt(nlevm),preamble,node1,nodend integer*4 m(1) equivalence (lastloc,m(1)) c c lastloc is ptr to end of this block c nlev is number of hash coded levels c nlevm is compile time max number of levels c hshloc are ptrs to 0'th loc of hash pointer tables

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-9 c hshcnt are ptrs to 0'th loc of hash count tables c hshlen are the hash lengths for each level c preamble is the number of standard block words before list data c node1 is ptr to first seq node c nodend is ptr to last seq node c c preamble structure Parameter ( !node + > pr_nxth=1, !next node with this hash code > pr_nxtp=2, !next physical node > pr_nlen=3, !length of this node > pr_ident=4, !identifier for this node > pr_level=5, !level of this node > pr_nxtg=6) !next node of same group (group ne level) c parameter ( > nst=4, !Number of supertypes not counting 0 > mlist_len=2*nst+2+2, !Length of mlist > mlist_len2=mlist_len-2 !length of mlist less 2 > ) c c integer plist(5) data plist/5,3,3*0/ equivalence (plist(3),catn),(plist(4),prdis),(plist(5),nsub) c integer slist(7),dstr(2) data slist/7,5,5*0/ equivalence (slist(3),lprim),(slist(4),subn),(slist(5),supn), > (slist(6),dstr(1)) c integer mlist(mlist_len),slp(0:nst),sll(0:nst) data mlist/mlist_len,mlist_len2,mlist_len2*0/ equivalence (mlist(3),slp(0),sp),(mlist(nst+2+2),sll(0),sl) c c common/dbmng/dblen,dbhshl,dbpnt(0:nst),dbmax(0:nst) integer*4 dblen,dbhshl,dbpnt,dbmax c c dblen is the total length of the data base db in (2 byte) words c dbhshl is the size of the hash code to be allocated in db c dbpnt are pointers to the 0'th word of the space to be c allocated for each supertype c dbmax is the size of that space in (2 byte) words c e.g. dbpnt and dbmax describe the partitioning of db into space c for the nst supertypes c All access to DBNODES is through the PNODE and GNODE subroutines. PNODE puts a node on the structure. Its calling sequence is: STAT=PNODE(level,name,list,cnode). Level is basically a region identifier in DBNODE that segregates name and serves a chaining

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-10 function to be explained. Name is an arbitrary 4 byte integer,usually an ASCII word. List is an I*4 'standard format' list that is placed on the node after the preamble. Cnode is a bidirectional variable; when a node is created, the value passed to PNODE in cnode becomes the sixth word of the preamble; the value returned in cnode is the node address of the newly created node. Thus a linked chain of nodes can be created and manipulated. The list structure for a prim (level 1) is: plist(3) catn category number plist(4) prdis primary descriptor (reserved) plist(5) nsub total number of subtypes for this prim The list structure for a secn (level 2) is: slist(3) lprim associated primary name slist(4) subn subtype number slist(5) supn supertype number slist(6) dstr data structure The list structure for a micr (level 3) is: mlist(3) sp pointer to supertype 0 mlist(4) slp(1) pointer to supertype 1 . . . mlist(j+3) slp(j) pointer to supertype j mlist(nst+4) sl length of supertype 0 . . . . mlist(nst+4+j) sll(j) length of supertype j nst is the number of supertypes, not including supertype 0. The structure of block 0 is described in the include file SUPSTR: c c Supertype 0 Structure (Pointers to the World) c c This block begins with the standard superblock structure. c It is followed by hash parameters and tables for finding c nodes that correspond to a particular unit. The hash tables c code the integer sum of catn+unit. c c Each node has a set of pointers and other information, and c is followed by nsub subtype blocks. c c Note that all node locations in this block are relative to sp, c so that the block is relocatable. Similarly, the pointers c into the superblocks are relative to the 0'th location of the c superblock.

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-11 c Parameter ( !Block Structure: > !sp+ > sp_net_work=1, !Work space for System 40 > sp_net_lsn=2, !System 40 network Logical Session Number > sp_id=3, !Superblock identification > sp_len=4, !Superblock length (words) > sp_micr=5, !Beginning of ascii micr name field > sp_blk_beg=7, !Beginning address of "real" data in this block > sp_seg_beg=8, !Address of superblock into which data at > ! sp_blk_beg is mapped. The structure from > ! sp_id to sp_hdr_len constitute the network > ! high level header. > sp_hdr_len=8, !Length of header block > sp_hshl=9, !Hash length > sp_hshp=10, !Hash pointers (hshp is this location) > sp_bdef=9 ) !Length of basic block is sp_bdef+2*hshl c sp_hshp+hshl Hash counters (hshc is this location) c Parameter ( !Hash Node Definition > !node+ > sp_nxth=1, !Next hash node > sp_nxtp=2, !Next physical node > sp_nxtc=3, !Next node of this category > sp_nlen=4, !Total length of this node > sp_catn=5, !Category number > sp_unit=6, !Unit number > sp_nsub=7, !Number of subtype blocks to follow > sp_ndef=7 ) !Length of this node definition c c Parameter ( !Subtype Block Definition > sp_subn=1, !Subtype number > sp_supn_byte=3, !Supertype number > sp_fmt_byte=4, !Format variable (I,A,R,Z,S) > sp_slen=3, !Length of subtype data (on the superblock) > sp_sptr=4, !Relative pointer into the superblock > sp_sdef=4 ) !Length of this subtype block definition c c The database access routines use an I*2 command list to access the database. The list consists of doublets of words. The first word is a pointer into dbnodes that points to the relevant micro-cluster node. This node, called mnode, has the (32 bit) pointers to the supertype blocks. Note with great care, (and I hope I haven't screwed it up) that the supertype blocks in DB cannot be addressed with 16 bits, and this ploy should eliminate the addressability problem. Mnode +

DATABASE INTERNAL STRUCTURE AND MAINTENANCE Page 1-12 preamble +1 points to the address of a supertype 0 block. The second word of the doublet points to the subtype node in the supertype 0 block (relative to its beginning). Thus the rest is trivial- The subtype block has the relevant data supertype whose address is found back in mnode, the offset to the data, and the number of words of the data subtype. See, for example, DBLGET.

1.3.1 Floating Point Formats The iRMX and VMS floating point formats are different. The convention we will follow is that all the databases- on the micros and on the vax- will always use the VMS format. Conversion will be automatic and transparent by calls from DBLGET and DBLPUT to CVT_IEEE_TO_VMS_FLT and CVT_VMS_TO_IEEE_FLT . Note that a virtual micro will call these conversion routines - in this case - the conversion routines should be dummies.

CHAPTER 2 8086 CAMAC INTERNALS Camac operations on the SLC Micro (8086 Microcomputer) are usually preformed by calling some or all of the following routines: o CAMIO -- for single packet CAMAC transfers with all the dirty work done for the user already. o CAMALO -- Allocates a control block for a CAMAC "package". o CAMADD -- Adds a "packet" to the allocated CAMAC "package". o CAMGO -- Executes a prepared CAMAC "package". o CAMGO_R-- Executes a prepared CAMAC "package", and sends the SLC micro a message to continue executing the package "forever". o CAMDEL -- Deletes the control block of an allocated package. o CAMFAG -- Modifies the F-code and sub-address of a single "packet" camac "package" and executes the packet (via CAMGO). o CAMMOD -- Modifies the CTLW's of an existing (ie: address) of an existing package, and executes the package (via CAMGO). o CAMALO_RESET -- Re-initializes an allocated "package". o CAMEXIT -- Sends a message to the indicated micro to stop executing this users repeat function. The above routines are described for the user in depth in the "SLC Basic Users Guide" (BUG). The casual user of SLC CAMAC is referred to the BUG for information concerning the use of the above routines.

8086 CAMAC INTERNALS Page 2-2 This chapter decsribes the internal structures of the command and data formatting used by the above routines, as well as a host of internal routines used by the above. Note that only the above listed routines are available as entry points into the shared VMS run-time library.

8086 CAMAC INTERNALS Page 2-3

2.1 "NESTING" OF INTERNAL ROUTINES The "nesting" of the various CAMAC routines is shown schematically below. Note that the returned status may come from any of the nested routines, or from an ERRCHK following a system service.

2.1.1 CAMIO (Vax) CAMIO_V CAMALO | LIB$GET_VM | (First time only) CAMAL1 | LIB$GET_VM (If BCNT > 270) CAMAL1 CAMADD CAMAD1 CAMGO_V LIB$GET_VM (if needed for RE_PACK) MSG_ONE CAMVMAIN (Micro) CAMAC_DRVR (Micro) CAMALO (Micro) RQ$CREATE$SEGMENT CAMAL1 (Micro) CAMGO (Micro) RQ$CREATE$SEGMENT (For P8 or RE_PACK) RQ$DELETE$SEGMENT (For P8 or RE_PACK) CAMDEL (Micro) RQ$DELETE$SEGMENT MMSG_SEND (Micro) LIB$FREE_VM (if needed for RE_PACK) LIB$FREE_VM (If BCNT > 270)

2.1.2 CAMIO (Micro) CAMALO | RQ$CREATE$SEGMENT | (First time only) CAMAL1 | RQ$CREATE$SEGMENT (If BCNT > 20) CAMALO_RESET CAMADD CAMAD1 CAMGO RQ$CREATE$SEGMENT (For P8 or RE_PACK) RQ$DELETE$SEGMENT (For P8 or RE_PACK)

8086 CAMAC INTERNALS Page 2-4 RQ$DELETE$SEGMENT (If BCNT > 20)

2.1.3 CAMALO (Vax & Micro) LIB$GET_VM (Vax only) RQ$CREATE$SEGMENT (Micro only) CAMAL1

2.1.4 CAMADD (Vax & Micro) CAMAD1

2.1.5 CAMGO (Vax) CAMGO_1 CAMGO_V LIB$GET_VM (if needed for RE_PACK) MSG_ONE CAMVMAIN (Micro) CAMAC_DRVR (Micro) CAMALO (Micro) RQ$CREATE$SEGMENT CAMAL1 (Micro) CAMGO (Micro) RQ$CREATE$SEGMENT (For P8 or RE_PACK) RQ$DELETE$SEGMENT (For P8 or RE_PACK) CAMDEL (Micro) RQ$DELETE$SEGMENT MMSG_SEND (Micro) LIB$FREE_VM (if needed for RE_PACK)

2.1.6 CAMGO (Micro) RQ$CREATE$SEGMENT (For P8 or RE_PACK) RQ$DELETE$SEGMENT (For P8 or RE_PACK)

2.1.7 CAMDEL (Vax & Micro) LIB$FREE_VM (Vax only)

8086 CAMAC INTERNALS Page 2-5 RQ$DELETE$SEGMENT (Micro only)

2.1.8 CAMFAG (Vax) CAMFA1 CAMGO_V (See CAMGO (Vax) for the rest of the nesting sequence)

2.1.9 CAMFAG (Micro) CAMFA1 CAMGO (See CAMGO (Micro) for the rest of the nesting sequence)

2.1.10 CAMMOD (Vax & Micro) CAMMOD1 CAMGO (See CAMGO for the rest of the nesting sequence)

2.1.11 CAMALO_RESET (Vax & Micro) (Does not call any routine)

2.1.12 CAMEXIT (Vax Only) CAMEXIT MSG_ONE CAMVMAIN (Micro)

8086 CAMAC INTERNALS Page 2-6

2.2 CAMAC DATA STRUCTURES The following is a description of the data structure used by the Camac routines, and by the MultiBus Camac Driver (MBCD). Also shown is the Vax->Micro and Micro->Vax message structures. Note that although the Vax routines do not directly do any Camac -- the structure of the Camac Package Structure it the same as in the micro.

8086 CAMAC INTERNALS Page 2-7

2.2.1.1 Control Block Structure - Word # Item +-------+----------+ | 0 | KEY | (the literal 'FR') +-------+----------+ | 1 | NOPS | Max. number of camac packets to follow +-------+----------+ | 2 | IOP | Actual number of camac packets +-------+----------+ | 3 | TBYTES | Maximum data byte count for this package +-------+----------+ ( approximate ) | 4 | Spare | Spare word +-------+----------+ | 5 |Bit Summary Bit Summary ( as P8 or RE_PACK ) +-------+----------+ | 6 | Spare 1 | Spare word 1 +-------+----------+ | 7 | Spare 2 | Spare word 2 +-------+----------+ The last two words are available for use by applications code. The current users are: o VAX-VMS Camac Support 1. Micro-Name (A*4) o TIME Job If words 6 and 7 are non-zero, they will be interpreted by the TIME job as a mbx token and and a msg token, respectivaly. The TIME job will put the supplied message token in the supplied mbx when the package has completed execution. 1. Segment Token for Mailbox 2. Segment Token for Message

8086 CAMAC INTERNALS Page 2-8

2.2.1.2 MBCD Packet Structure - Word # Item +-------+----------+ | 0 | | Low-order camac control word +-------+ CTLW | | 1 | | High-order camac control word +-------+----------+ | 2 | | Stat/dat buffer address offset +-------+ Data Ptr | | 3 | | Stat/dat buffer address segment +-------+----------+ | 4 | WC_MAX | Maximum word count +-------+----------+ | 5 | CIC | Completion interrupt code +-------+----------+

2.2.1.3 EMASK Storage - Word # Item +-------+----------+ | 0 | EMASK | EMASK for the IOP'th Packet +-------+----------+

8086 CAMAC INTERNALS Page 2-9

8086 CAMAC INTERNALS Page 2-10

8086 CAMAC INTERNALS Page 2-11

2.3 ROUTINES

2.3.1 CAMIO CAMIO performs a single-packet CAMAC operation: ISS = CAMIO(BRCH,CTLW[,DATA[,BCNT [,STATUS[,EMASK]]]]) Integer*4 CAMIO returned status Integer*4 BRCH micro name, required but not used in micro Integer*4 CTLW control word (Array) DATA unspecified data array (Optional on VAX non-data) Integer*2 BCNT byte count (Optional on VAX non-data) Integer*4 STATUS returned MBCD status (Optional on VAX) Integer*2 EMASK error mask (Optional on VAX) This is the general purpose "camac" routine. Routines in both the Vax and the Micro do essentially the same functions. Specifically: o Allocates a CAMAC package with a CAMALO first time called. o Gets some memory if it's default array is too small. (VAX version's default array size is 270 bytes, while MICRO's is 20 bytes.) o Copies DATA into stat_data, if camac write. o Initializes CAMAC package: CAMAL1 (Vax) with a new BRCH destination, or, CAMALO_RESET (Micro). o Prepares MBCD packet with CAMADD to load CTLW, STAT_DATA pointer, etc. o Executes the packet with a CAMGO (Vax code, with a CAMGO_V). o Copies STATUS from stat_data. o Copies DATA from stat_data, if camac read. o Deallocates memory. Vax version calls CAMIO_V after determining that CAMAC is SLC type, with all 6 arguments to do the above dirty work.

8086 CAMAC INTERNALS Page 2-12

2.3.2 CAMIO_V CAMIO_V receives ALL arguments form CAMIO. (Vax only). ISS = CAMIO(BRCH,CTLW[,DATA[,BCNT [,STATUS[,EMASK]]]]) Integer*4 CAMIO returned status Integer*4 BRCH micro name, required but not used in micro Integer*4 CTLW control word (Array) DATA unspecified data array (Optional on VAX non-data) Integer*2 BCNT byte count (Optional on VAX non-data) Integer*4 STATUS returned MBCD status (Optional on VAX) Integer*2 EMASK error mask (Optional on VAX) See product description under CAMIO.

2.3.3 CAMALO Allocates and initializes a block for NOPS camac packets. ISS = CAMALO(BRCH,NOPS,PTR) Integer*4 CAMALO returned status Integer*4 BRCH micro name, required but not used in micro Integer*2 NOPS maximum number of operations allowed Addr.Token PTR pointer to control block The size required for a CAMAC package is 1 control block plus NOPS each MBCD Packets and EMASK's. Or in numbers: 8 + NOPS*(6 + 1) words. CAMALO calls on CAMAL1 to initialize the package, calling with the PTR by value: ISS = CAMAL1(PTR, ... )

2.3.4 CAMAL1 Initializes the Control Block with the Key ('FR'), BRCH (Vax only),

8086 CAMAC INTERNALS Page 2-13 NOPS, and zeros the rest of the package. ISS = CAMAL1(CTLBLK,WC,NOPS,BRCH) Integer*4 CAMALO returned status Integer*4 CTLBLK control block, by referance Integer*2 WC size of camac package block (words) Integer*2 NOPS maximum number of operations allowed Integer*4 BRCH micro name, required but not used in micro

2.3.5 CAMADD Dummy routine to call CAMAD1 to add a single packet to a Camac package. ISS = CAMADD(CTLW,STAT_DATA,BCNT ,EMASK,PTR) Integer*4 CAMADD returned status Integer*4 CTLW control word (Array) STAT_DATA unspecified data array Integer*2 BCNT byte count Integer*2 EMASK error mask Addr.Token PTR pointer to control block CAMADD calls on CAMAD1 to initialize the package, calling with the PTR by value: ISS = CAMAD1( .... ,PTR)

2.3.6 CAMAD1 Routine to add a single packet to the Camac package. ISS = CAMAD1(CTLW,STAT_DATA,BCNT ,EMASK,CTLBLK) Integer*4 CAMAD1 returned status Integer*4 CTLW control word (Array) STAT_DATA unspecified data array Integer*2 BCNT byte count Integer*2 EMASK error mask Integer*4 CTLBLK control block, by referance This routine adds a packet to the Camac package (Whose address was

8086 CAMAC INTERNALS Page 2-14 passed as the last argument). Routines in the Vax and the Micro do essencially the same functions. Specifically: o Check the Control Block KEY to verify that it is 'FR'. o Increment the packet count IOP, and verify that is does not exceed the limit of NOPS. o Check that RE_PACK option is only requested on a single packet. o Calculate the MBCD Packet WC_MAX, with proper accounting for the pack 8 (P8) option. o Check against ODD byte counts, and excessivly long transfers. o Load the MBCD Packet with: 1. CTLW 2. STAT_DATA Pointer 3. WC Maximum 4. CIC (Completion interrupt code, not used) o Clears the CIC and sets MPC (more packets coming) of the previous MBCD Packet.

2.3.7 CAMGO (Micro) Executes an already prepared Camac package, and checks the results for errors against the EMASK error mask. ISS = CAMGO(PTR) Integer*4 CAMGO returned status Addr.Token PTR pointer to control block See comments in code for concise documentation of this routine.

2.3.8 CAMGO (Vax) CAMGO calls CAMGO_1(%val(PTR),...) which calls CAMGO_V(CTLBLK) after

8086 CAMAC INTERNALS Page 2-15 determining that CAMAC is SLC type. ISS = CAMGO(PTR) Integer*4 CAMGO returned status Addr.Token PTR pointer to control block

2.3.9 CAMGO_R (Vax) CAMGO_R calls CAMGO_V(%val(PTR), .true.) after determining that CAMAC is SLC type. ISS = CAMGO(PTR) Integer*4 CAMGO returned status Addr.Token PTR pointer to control block

2.3.10 CAMGO_V Builds outgoing Vax-to-Micro Message requesting the micro to execute a Camac package. ISS = CAMGO_V(CTLBLK, REPEAT_FLAG) Integer*4 CAMGO_V returned status Integer*4 CTLBLK control block, by referance Integer*4 REPEAT_FLAG signals that package repeats (Optional) Refer to section on CAMAC DATA STRUCTURES while reading the following. o CAMGO_V sends to the micro a message containing the entire camac package, and all write data associated with the Camac operation. o The data is sent to the micro via MSG_ONE, and a response is expected within a 2 second timeout. o The returned message consists of the returned status (VMS), and all STAT_ for non-read or STAT_DATA for read commands. o CAMGO_V copies the STAT_ or STAT_DATA into the previously declared locations (via camadd calls) and returns with the VMS status from the micro.

8086 CAMAC INTERNALS Page 2-16 If the REPEAT_FLAG is asserted, the micro keeps the generated CAMAC blocks and repeats the transaction until either it 1) reaches it's repeat count, or 2) receives any other CAMAC message from the same VAX process.

2.3.11 CAMMOD An intresting little routine with a pleasent color. Modifies the CTLW's of a existing package, and executes it (via CAMGO). ISS = CAMCAM(CTLW,MASK,PTR) Integer*4 CAMCAM returned status Integer*4 CTLW control word Integer*4 MASK mask of CTLW bits to modify Addr.Token PTR pointer to control block

2.3.12 CAMALO_RESET Resets the package to the virgin state, allowing a new set of camac packets to be added. ISS = CAMALO_RESET()

2.3.13 CAMEXIT Sends a request to the Micro to stop this process's CAMAC activity started with a CAMGO_R request. ISS = CAMEXIT(BRCH) Integer*4 BRCH micro name Note: Process ID is determined from the user's SLCNET interrupt ID number, and may not be the same after a process exits and runs again.

8086 CAMAC INTERNALS Page 2-17

2.3.14 CAMVMAIN The main job in the micro, receives the message from CAMGO_V and then: o Allocates memory for the return response message. o Calls CAMAC_DRVR ISS = CAMAC_DRVR(INMSG,OUTMSG). o Sends back response message. o Deallocates memory.

2.3.15 CAMAC_DRVR (Micro) Executes CAMGO_V Package from Vax. ISS = CAMAC_DRVR(INMSG, OUTMSG) (Array) INMSG incoming message (Array) OUTMSG outgoing message Routine's function is primarly as an interface between the Vax and the internal CAMGO. Routines functions are: o Allocate a Camac Package. (via Camalo). o Copy VAX's package into our own (thereby forcing paragraph allignment). o Adjust all the MBCD Packet's STAT_DATA Pointers to point to either: 1. Stat_data locations in INMSG (for camac writes). 2. Stat_data locations in OUTMSG buffer. Note that holes were left for write stat_ data in OUTMSG. o Execute CAMGO on our package. o Copy returned Camgo status into OUTMSG. o Copy all write Stat_'s into previously left holes in OUTMSG. o Deallocate our Camac Package. (via camdel).

CHAPTER 3 BPM SOFTWARE INTERNALS

3.1 INTRODUCTION The chief funtion of the BPM software is to enable the operator to take a "snapshot" of the particular beam he is interested in. Ideally (and in fact, in some parts of the SLC, such as the linac), the data returned to the operator should report the location of a single pulse as it travels along the operator-specified range within the SLC. In some parts of the SLC hardware limitations make this impossible. In such cases several pulses are required to return data for all the requested monitors. In any case readings along the range are synchronized by means of a request to the MPG to broadcast a special non-zero "YY" byte along with a particular "PP", corresponding to the beam for which the operator requests BPM measurement data. Software complications peculiar to the BPM code arise from the following considerations: 1. A single operator is likely to want BPM data from several parts of the SLC for several beams during a typical session.

BPM SOFTWARE INTERNALS Page 3-2 2. Several operators may want BPM data from from overlapping sets of micros at roughly the same time. 3. The entire procedure necessary to obtain BPM measurement data includes several steps which will, in general, be strung out over time. Information from earlier stages, peculiar to the beam code and particular SCP requesting the measurement, must be saved (some in the SCP; most in the micro) in a manner allowing reasonably speedy access and a minimum of wasted space. These considerations primarily affect the micro, where both time and space are at more of a premium.

3.1.1 Hardware BPMs are logically and physically divided into two parts: a monitor and a processor. The monitor consists of four (or, in some parts of the machine, e.g. collider arcs, two) strips in which electrical charge is induced when the beam passes. Information pertaining to the monitors is stored in the database under the primary BPMS (or, for the two-strip monitors, BPMX or BPMY). The processor (database primary BPMP) takes the signals from the monitors and outputs digitized sum and (two) difference signals. In the linac each monitor is connected to a processor, but in other parts of the machine up to ten monitors may be multiplexed into a single BPMP by means of SP10T multiplexers. A detailed description of the hardware may be found in the appropriate chapter of the Hardware Manual. See also SLAC-TN-84-2, "SLC BPM System Maintenance and Diagnostics Manual."

BPM SOFTWARE INTERNALS Page 3-3 SLC Toroids are also controlled by the BPM software. Toroids are never multiplexed, so there is no reason to separate processor from monitor. All information pertaining to a toroid can be found in the primary TORO. A variety of analog devices read out through gated ADC's (primary GADC) are also accessed through BPM software. These devices (collectively and colloquially known as DUGADC's) include SLIT, GAPM, ARRY and WIRE. For them the GADC plays a role rather similar to the BPMP, while SLIT, GAPM, ARRY and WIRE are similar to BPMS (or BWMS). For a description of the BPMP, BPMS and TORO secondaries see the database appendix to this chapter.

3.1.2 Functions Available From SCP

3.1.2.1 Calibration - Before the raw data output from BPM processors may be meaningfully converted to X- and Y- locations, the processors must be calibrated. The operator selects all the parameters relevant to the beam he wishes to measure (namely PP, bunch number, attenuation, range of micros, etc.) and stores them in a "Measurement Definition" on the BPMO START panel. He then attempts to calibrate. Possibly he will have to re-select some of the parameters before he can obtain usable calibration data. The calibration procedure is designed to determine the characteristics of the ADC's in the BPM processor when gathering data in the environment provided by the selected PP beam number. In particular,

BPM SOFTWARE INTERNALS Page 3-4 the calibration procedure measures pedestals for each ADC and the gains of the two difference ADC's relative to the sum ADC (note: calibration procedure will be different when hardware other than the standard BPMP processor is used). Data from the calibration is displayed and written to an unformatted disk file on the SCP end. Those pieces of information needed to calculate measurement data are also saved in the micro as long as the requesting SCP might need them.

3.1.2.2 Measurement - Measurement data may be collected in two ways: by pushing the DATA START-STOP button on the BPMO MEASUREMENT PANEL (normally either the values or bar display will also be selected on this panel), or by a call to the routine BPM_AVG (in which case the data is not displayed in any form by the BPMO facility software). In either case, the data is stored in a common block accessible to all routines which include the file SLCSYS:BPMSCP.TXT. (Note: in the very near future the common block will be eliminated. Instead data will be stored in dynamically-allocated storage. Utility routines analogous to DBGET, DBLIST, etc. will be provided for callers of BPM_AVG to access the data.) The procedure actually followed to collect the data depends on the hardware in the sectors in the current range, being somewhat more complex in those sectors having multiplexed monitors. The differences are transparent to the operator. The returned data has the same form regardless of the type of hardware.

BPM SOFTWARE INTERNALS Page 3-5

3.1.2.3 Diagnostics - Several diagnostics are supported by the BPM facility software: 1. TIMING The TIMING button on the BPMO START panel allows the operator to take measurement data for a single sector, whether or not the sector has been calibrated. This is possible because only the raw data read from the three ADC's is returned; X- and Y-position are not reported. TIMING is used to determine the best value to set for BUNCH DELAY when a measurement definition is being created. It is classed as a diagnostic because, under normal operating circumstances, BUNCH DELAY should always be zero. In a future release of the BPM software the calculation of the optimum BUNCH DELAY will be done automatically during calibration. The TIMING button will be moved to the BPM DIAGNOSTICS panel so that the operator may override the automatic calculation. 2. Ungated read (rings only) Once beam has been stored in a ring, the appropriate time to take data can no longer be calculated as a fixed offset from fiducial time. Any such fixed offset will give readings with intolerably high variance. Instead, it is preferable to take data asynchronously, when the beam is strongest. This facility is provided by the UNGATED READ button on the BPMO DIAGNOSTICS panel. When it is pushed, data for any measurement definition whose range is one of the rings will be taken in ungated mode.

BPM SOFTWARE INTERNALS Page 3-6 3. Histograms (see also Correlation Plots) The BPM facility software provides several histograms, which may be selected from the BPMO DIAGNOSTICS panel. The histograms will be created as data is collected when the DATA START-STOP button is in its ON state. More sophisticated histograms of BPM data may be created by means of the Correlation Plots software. 4. HSTA toggles Operators may toggle the hardware status of any BPMS (monitor), BPMP (processor) or toroid from buttons on the BPMO DIAGNOSTICS panel. 5. DBS displays for a single unit All database information for a single BPMS, BPMP or toroid may be displayed by means of buttons on the BPMO DIAGNOSTICS panel.

3.1.3 Basic Protocol For Calibration And Measurement BPM calibration and data-taking have the peculiar property of involving, at a minimum, three rather than two computers: the Vax, the micro with control over the sector from which data is requested, and the Master Pattern Generator (for synchronization). The protocol is as follows:

BPM SOFTWARE INTERNALS Page 3-7 1. Preparation When a start-up of data-taking has been requested, the SCP sends a request to each micro in the current range to prepare (but not execute) camac packages. The camac packages vary according to the hardware available in the sector. They may contain packets to program PDU's, set multiplexers, set attenuation in the BPMP's, and read the BPMP ADC's. The micro is requested to associate each camac package with a particular YY. The package will be executed when the YY is seen by the micro. At this time the BPM job may also need to request the TIMING job to program PDU's for a particular YY. 2. MPG request The SCP sends a request to the MPG to broadcast the YY's when it is also broadcasting the PP that is part of the current measurement definition. 3. Data processing in micro Upon receipt of the second YY in a pair the BPMO subjob is woken up by a "trickle-down" message. The raw data is massaged into a form suitable for the SCP. Finally, a response message may be sent to the SCP. 4. Data accumulation in SCP If the operation is calibration, data is stored in the SCP in dynamically allocated memory, one segment per micro in the current range (the memory is allocated when a measurement definition is created or selected). The data is also written

BPM SOFTWARE INTERNALS Page 3-8 to two disk files, one unformatted and one Ascii. The Ascii file is a permanent, human-readable record of the calibration results. The unformatted file is used by the SCP to recover calibration data in case the operator de-selects, then re-selects the measurement definition. It could also be used to restore calibration data to a micro which has been booted since its BPM's were last calibrated (not yet implemented). If the operation is measurement (includes the diagnostic TIMING), returned data is stored in a common block. The common block is accessible to any routine including SLCSYS:BPMSCP.TXT. In particular, it is accessible to application code, such as the Correlation Plot software, as well as to the BPM facility. It will probably be necessary in the near future to move to a dynamic allocation scheme for measurement data storage just as is now done for calibration. When this is done, a routines will be provided to allow access to the data to applications code.

3.2 SCP CODE We now take a detailed look at the SCP code. The discussion here is organized by function. See Appendix ?? for an alphabetical list of routines with a short description of each.

3.2.1 Panels There are three panels for the BPMO facility software: BPMO Start-up

BPM SOFTWARE INTERNALS Page 3-9 (BPMSTART.PNL), BPMO Measurement (BPMOMEAS.PNL), and BPMO Diagnostics (BPMDIAG.PNL). On the Start-up panel measurement definitions are created (and may also be selected), calibrations are done, and the TIMING diagnostic may be used (because it may be necessary to do timing in order to find a workable value for bunch delay in the measurement definition). Measurements may be started or stopped from the Measurement panel, and the operator may toggle between the two available displays (values display or BPM versus Z) and between the different devices (BPM's or toroids). A measurement definition may also be re-selected from this panel. The Diagnostics panel supports single-unit displays for BPMP's, BPMS's or toroids, hardware status toggles for each of these three kinds of devices, histograms, and a toggle for ungated reading in the rings.

3.2.2 Driver Routine (BPMDRVR) Most of the buttons for strictly BPMO functions on the BPMO START and BPMO MEASUREMENT panels cause BPMDRVR to be called. The major exceptions are the calibration buttons, the set of switches to select Display Group, the buttons for choosing measurement display, and the TIMING button. Several different button variables are used, depending on the function requested by the operator. [Note: this should be cleaned up. Certainly we could get by with fewer variables than are currently used.] If the CHANGE MICRO LIMITS button is pushed, the variable BPMRANGE will get the value ENTR. If a new display group is selected, the switch variable BPMDGRP will get a new value (and the entry BPM_RANGE_CLEAR will be called). If any of the other components of

BPM SOFTWARE INTERNALS Page 3-10 the measurement definition are to be changed, the variable BEAMDEFN will get an appropriate value (PP, BUNCH, etc.). If the UNLOCK button is pushed [Note: this function is nearly obsolete. It should be eliminated altogether or at least moved to the DIAGNOSTICS panel.] then BPMODIAG gets the value UNLOCK. If a new measurement definition is to be created or selected (by pushing one of the measurement definition buttons) BPMBEAM will get a value of BEAMDEF1, BEAMDEF2, etc., depending on the button pushed. When any of the buttons CREATE MEAS DEF, SAVE MEAS DEF or RESTOR MEAS DEF is pushed, the variable BPMDEF receives a value. If data is to be started or stopped, or if a new device for data-taking is to be selected, the variable BPMSAMPL gets a value. Where the function requested consists merely of updating the panel and internal variables, the work will generally be done entirely by BPMDRVR (although in many cases if data-taking is ongoing at the time the button is pushed, BPMDATOFF will be called first to turn it off; then BPMDRVR will do the updating). The more profound functions are handled by separate routines. For example, If data-taking is to be started BPMDRVR will call BPMDATON. If measurement definitions are to be created, selected, saved, or restored BPMDRVR will call the appropriate entry in BPMDEF_CREATE. In all cases BPMDRVR clears whatever button variable has been set by the button push.

3.2.3 Measurement Definitions A Measurement Definition is a collection of parameter values which determine the conditions under which a set of BPM measurements (and the corresponding calibration) will be taken. The values are set by

BPM SOFTWARE INTERNALS Page 3-11 the operator or may be read in from a previously-saved Measurement Definition file (in the future, certain Measurement Definitions may be fixed and available with no operator action; e.g., the Measurement Definition appropriate for normal operation in CID). Currently the parameters composing a Measurement Definition are: the display group, the first and last micros in the range of micros from which the data is to be taken (must be consistent with display group), the PP beam number, the time slot, the bunch number (1, 2 or 3), the attenuation value to be set in the BPMP's (the same value is used throughout the range), the bunch delay (timing fudge factor which is normally zero), and the sign of the bunch (e- or e+). Soon the new display group parameter will be added. Ideally, at some time in the future attenuation and bunch delay will, by default, be set automatically and so will not appear on the BPMO START panel (but might be left on the Diagnostics panel for those who want to override the automatic settings). Internally, all this information is kept for each Measurement Definition in a set of arrays whose size is determined by the value of the parameter MAXDEFS (currently =5). The arrays are in the common block BPM_BEAMDEFS, defined in the include file SLCSYS:BPMBTNDEF.TXT. Certain other information pertinent to each Measurement Definition is also kept in arrays in this common block. For example, the logical array CAL_DEFS keeps track of which Measurement Definitions have valid calibrations. The array BPM_CALOK(2,MAXDEFS) consists of 64-bit masks for each Measurement Definition, indicating which micros have successful BPM calibrations for this Measurement Definition. The variable CURR_DEF (in BPM_BEAMDEFS) keeps track of which Measurement

BPM SOFTWARE INTERNALS Page 3-12 Definition, if any, is the currently active one; i.e., the one for which measurements will be taken if the DATA ON-OFF button is pushed, for which a calibration will be done if the CAL BPMO button is pushed, etc. If no Measurement Definition is selected CURR_DEF is set to zero. Similarly, CURR_SEG is the index used by the micro in its array of tokens (one for each active measurement definition). For now, CURR_SEG = 8*SCP_ID + CURR_DEF. Another group of variables carries much of the same information for the currently-selected Measurement Definition (or, if there is none, for the values of the parameters as displayed on the BPMO START panel). Most of these variable are in one of the common blocks BPM_BEAM_DEF or BPMPANEL, both defined in the file SLCSYS:BPMPANEL.TXT. Examples of such variables are PP, BUNCH, TS (in BPM_BEAM_DEF) and FMIC, LMIC, CFMIC, CLMIC (in BPMPANEL).

3.2.3.1 Rationale - The rationale for the existence of Measurement Definitions is two-fold: 1. To allow the operator to move his attention from one group of BPM measurements (in one area of the machine, for a particular PP) to another (maybe in another area, for a possibly different PP) and back again as painlessly as possible.

BPM SOFTWARE INTERNALS Page 3-13 2. To allow different SCPs to take interleaved measurements over possibly overlapping sets of micros (this is accomplished by keeping sufficient information in the micro for each existing Measurement Definition, for each active SCP).

3.2.3.2 Setting Parameters (BPMDRVR, BPM_RANGE, Entries BPM_AUTORANGE, - BPM_RANGE_CLEAR) Before creating a new Measurement Definition the operator will in general want to change one or more parameter values. As soon as the operator changes such a parameter, CURR_DEF and CURR_SEG are set to zero and the bar on the currently-selected Measurement Definition, if any, is erased. If data-taking has been going on, it is stopped. The simpler parameters (PP, BUNCH, TS, ATTENUATION, PARTICLE {e- or e+} and BUNCH DELAY) are handled entirely by BPMDRVR. Input is solicited from the operator if necessary, the panel is updated, and appropriate variables are changed. If a new DGRP is selected, the entry BPM_RANGE_CLEAR gets rid of the old micro range (since it usually will not be consistent with the new DGRP) in addition to stopping data-taking, setting CURR_DEF to zero, etc. If the values for the first or last micros are to be changed, BPMDRVR calls BPM_RANGE. BPM_RANGE solicits operator input, checks to make sure this range is consistent with the current DGRP, then flows into the entry BPM_AUTORANGE (which is called directly when a Measurement Definition is selected--see below). BPM_AUTORANGE sets up DISP_LIST, the list of all micros in the selected DGRP, and finds the location of the operator-chosen first and last micros in this list. It also initializes the display range to 'ALL'.

BPM SOFTWARE INTERNALS Page 3-14

3.2.3.3 Manipulating Measurement Definitions -

3.2.3.3.1 Creation - The process of creating a Measurement Definition with the current value of the parameters begins when the operator pushes the CREATE MEAS DEF button on the BPMO START panel. BPMDRVR sets the flag CREATE and returns control to the operator. To finish the process, the operator must push one of the Measurement Definition buttons on the bottom of the panel. The button variable BPMBEAM gets one of the values BEAMDEF1, BEAMDEF2, etc., depending on which Measurement Definition button has been pushed. The parameter values are then "stored in the button" by BPMDEF_CREATE (called by BPMDRVR). If the button previously contained a Measurement Definition, it is now lost. BPMDEF_CREATE updates internal Measurement Definition arrays with the information on the panel and, in some cases, with default initial values (e.g., CAL_FLAGS(idef) is set to .FALSE.). Certain simple variables are also set to default values (e.g., DEV_BPM is set to .TRUE. and DEV_TOR is set to FALSE.). A mask of the micros in the current range is created in the quadword CURR_MICROS and also stored in DGRP_MICROS(*,CURR_DEF). A bar is written to the appropriate Measurement Definition button and the previous bar, if any, is erased. FInally, BPMDEF_CREATE calls BPMGETDB to get current HSTA and other information for the relevant hardware and calls BPMGETVM to give back old virtual memory and get the right amount of new virtual memory in which to store calibration information.

BPM SOFTWARE INTERNALS Page 3-15

3.2.3.3.2 Selection - When the operator pushes a Measurement Definition button without first pushing the CREATE MEAS DEF button BPMDRVR instead calls BEAMDEF_SELECT, an entry in BEAMDEF_CREATE. This routine copies values from the Measurement Definition arrays to variables used to store current parameter values (e.g., PP, TS, etc.) and updates the BPMO START panel (if it is the currently selected panel) with these values. It also calls BPM_AUTORANGE, BPMGETDB and BPMGETVM. Finally, it reads in calibration data, if any, for this Measurement Definition so that it can be displayed on operator request.

3.2.3.3.3 Saving And Restoring Measurement Definitions - A set of currently defined Measurement Definitions may be "saved" (i.e., written to a disk file for later retrieval) by pushing the SAVE MEAS DEF button. The button variable BPMDEF gets the value BPMSAVE, so that BPMDRVR knows to call the entry BPMDEF_SAVE (in the routine BPMDEF_CREATE). BPDMEF_SAVE prompts the user for file name (directory is always SLCBPM: and filetype is always DEF) and writes out the necessary information. No changes are made to the Measurement Definitions themselves. Similarly, Measurement Definitions may be restored from a previously-written file by pushing the RESTORE MEAS DEF button. In this case BPMDEF gets the value BPMRSTOR and BPMDRVR calls the entry BPMDEF_RESTORE. This routine prompts for file name in the same manner as BPMDEF_SAVE, then reads the information into the Measurement Definition arrays. A Measurement Definition existing on the panel

BPM SOFTWARE INTERNALS Page 3-16 before the RESTORE button is pushed will be over-written iff there is a saved Measurement Definition corresponding to the same Measurement Definition button. The BPMO START panel is updated appropriately.

3.2.4 Calibration Routines (BPMCAL, BPMCAL_*) Once a Measurement Definition has been selected, the operator may obtain new calibration data by pushing the CAL BPMO button on the BPMO START panel. DEXEC and the display BPMCAL are scheduled and the button variable BPMOCALI gets the value CALB. To display old calibration data, the CAL DISPLAY button must be pushed (on either BPMO START or BPMO MEASUREMENT), in which case the entry BPMCALD in BPMCAL is scheduled instead of BPMCAL, and the value of the variable is CALD. BPMCAL sets up two (64-bit) masks of micros in the selected range; one of those micros with cluster status on for BPMP's (BPM_CLUSTAT), the other with good cluster status for TORO's (TOR_CLUSTAT). These masks are part of the declared as two-dimensional arrays (e.g., BPM_CLUSTAT(2,MAXDEF)). The union of these two masks are the micros to which the SCP now sends a prep. message. The new mask BPM_CALOK (resp. TOR_CALOK) is then the intersection of those micros replying successfully to the prep. command and BPM_CLUSTAT (resp. TOR_CLUSTAT). These masks are also part of arrays indexed by Measurement Definition number. For a complete description of the data for the prep. message, see the Appendix???? Since there is no data (except for a single longword of status) in the micro acknowledgement to the prep. command, this return message is handled by the co-routine BPM_MSGCO, the least complex of the coroutine entries in

BPM SOFTWARE INTERNALS Page 3-17 the file SLCSYS:BPRMEAD.FOR. "Calibration" of the toroids is now complete; actual hardware calibration of toroids is, for now, done off-line. The SCP orchestrates calibration of the BPMP's by sending two sets of requests to the MPG. The first is used in the micro to make gain measurements, the second for pedestals. A set consists of ten separate requests, each for one pair of YY's to be broadcast. The reason for breaking up the broadcasts this way is so that one SCP does not monopolize the MPG with a single long chain. This way, other SCP's, working in other (disjoint) micro ranges, may continue BPM activities interleaved with the calibration. After the very first MPG request the SCP waits for acknowledgement from all micros in the BPM_CALOK mask. The coroutine used is again BPM_MSGCO. If no micros respond, it may mean that the MPG did not fulfill the broadcast request within the time limit, probably because the requested combination of PP and TS is not being braodcast, and calibration is aborted with an appropriate message to the operator. If some, but not all, micros respond, it probably means the non-responding micros have some defective hardware (e.g., PRIM or CAR) so that they never received the broadcast. BPM_CALOK is updated accordingly, since there is no point in attempting to calibrate such a micro. The next eight chain requests are sent without waiting for acknowledgement from the micros, but the SCP does wait for a reply after the last chain request used for gain measurement (this allows the micro to switch BPMP mode from gain to pedestal without danger of

BPM SOFTWARE INTERNALS Page 3-18 losing synchronization with the SCP). The coroutine is again BPM_MSGCO. Again, any micros which fail to respond with good status are deleted from the mask BPM_CALOK. Finally, the last chain request is made to the MPG. This time the SCP waits for the returned calibration data from the micros, stored by the coroutine BPMCALRD in the virtual memory obtained when the current Measurement Definition was selected. BPM_CALOK is updated the last time, to indicate which micros in the range completed the entire calibration procedure successfully. If calibration was at all successful (i.e., if at least one micro with BPM's or toroids was successfully calibrated), BPMCAL next call the routine BPMCAL_OPEN_FILE to open two disk files to contain the calibration results and to write appropriate header information to the files. One (VxxxPPppp.Bb, where xxx is the SCP id, ppp is the PP number for this Measurement Definition, and b is the button number -- between 1 and MAXDEF, inclusive -- for this Measurement Definition) is an Ascii file of essentially the same format as the video display, the other (VxxxPPpp.Ub) will contain the information unformatted. BPMCAL then updates the panel and does some other minor clean-up before flowing into the entry BPMCALD, in which the results are displayed. BPMCALD writes a couple header lines to the display. Then, for each micro it calls the routine BPMCAL_WRT_MICRO to display the data for that micro and, if a new calibration has been done, write information for the micro to the disk files. Finally, BPMCAL_FILE_CLOSE closes the files.

BPM SOFTWARE INTERNALS Page 3-19

3.2.4.1 Calibratione Downloading (BPMCAL_DOWNLOAD) - At times circumstances may be such that it is impossible or undesirable to re-calibrate, but old calibration data is known to be valid. For example it becomes impossible to accurately measure pedestals in the Damping Rings when there is stored beam. It is possible to download calibration data for one or more micros in the current range by pressing the CAL DOWNLOAD button on the BPMO START panel. The routine BPMCAL_DOWNLOAD prompts for micro (can be ALL*) and calibration file. The file must be a standard unformatted file such as is normally created upon successful calibration. BPMCAL_DOWNLOAD checks to see that the current DGRP is the same as the one in the file. If the attenuation values are not the same, the operator is warned and given an opportunity to abort. BPMCAL_DOWNLOAD then searches the file for the requested micro, calls BPMCAL_PTR to set up pointers into the dynamic storage allocated for the calibration data for this micro, calls BPMCAL_RSTR_MICRO to restore the data from the file to the dynamic storage, and calls BPMCAL_SEND to send the data accross the network. If the "micro" specified was actually ALL*, BPMCAL_DOWNLOAD simply reads through the entire calibration file. Whenever it finds a micro in the current range, it proceeds with all the steps listed above. Finally BPMCAL_DOWNLOAD writes a new unformatted calibration file which merges the new calibration data with any pre-existing calibration data for othermicros in the range. The same routines (BPMCAL_FILE_INIT, BPMCAL_WRT_MICRO, BPMCAL_FILE_CLOSE) are used as are used in a regular calibration, but they are called with arguments which specify that only the unformatted file is to be written. No formatted file is written nor is there any video display (although the operator can get it by pushing the CAL

BPM SOFTWARE INTERNALS Page 3-20 DISPLAY button).

3.2.5 Data Accumulation (BPMDATON And Entries BPMDAT, BPMDATOFF) The operator initiates (resp. stops) data accumulation for display by pushing the START-STOP DATA button on the BPMO MEASUREMENT panel. The button variable BPMSAMPL gets the value DATA and BPMDRVR is called. BPMDRVR calls BPMDATON (resp. BPMDATOFF) and clears the button variable. BPMDAT and BPMDATOFF are both entries in the routine BPMDATON (file is SLCSYS:BPMDAT.FOR). BPMDATON starts up data-taking by sending a prep. request (see Appendix??? for data in the request) to all micros in the current range which completed calibration successfully for the selected hardware (BPM or toroid). The data for each micro in the range is slightly different (because T_NOMINAL may be different) so the prep. requests are sent with one MSG_WAIT for each micro in the range, followed by a single MSG_WAIT to accept all acknowledgements. BPM_MSGCO, the simplest coroutine, is used to handle the micro replies. If the preparation succeeds (i.e., if at least one micro is successful) the 64-bit mask MEAS_MASK is set to those micros which were successful, the routine (acutally group) BPMDAT is scheduled to do the actual data-taking, and, if selected, a LIST_PUT is done for one of the displays BPMDISPZ or BPMDISPV. Finally, BPMDAT is scheduled (NOW and CYCLE). BPMDAT handles the actual data collection for the displays. An appropriate request is sent to the MPG (varies depending on whether any multiplexed readings are to be done -- if so, 9 pairs of YY's are

BPM SOFTWARE INTERNALS Page 3-21 requested, otherwise just one pair) and the SCP waits for the data all with a single call to MPG_SYNC. The co-routine used is BPMREAD, which both collects status information and stores the data in fixed arrays in the common block BPM_DATA. If sufficiently severe error conditions occur (e.g., no response from any micros in the range) BPMDAT de-schedules itself, takes the bar off the DATA START-STOP button, etc.

3.2.6 Data Display (BPMDISP, BPMDISPZ, BPMDISPV) BPMDISP and its entries BPMDISPZ and BPMDISPV handle all matters relating to the BPM data displays. At ACNTRL(1) .EQ. -1 BPMDISP initializes a number of variables used in the bar display (e.g. variables like NTICS and SECTO_XARRAY) and does a couple of LIST_VARS. BPMDISP will be called from the BPMO MEASUREMENT panel if the operator chooses to change the scale of the BPM vs. Z display. BPMDISPZ handles the BPM vs. Z display (background and foreground). If BPMDISPZ is being called for the first time after data has started coming in, if the operator has just changed the display range (possible values are ALL, FIRST and LAST, where these refer to the selected micro range), or if the operator has just changed the scale, code for generating the background display will be executed. This includes getting display Z's for the sectors and for the hardware (For now the bar display is only supported for BPMS's. Eventually toroids will also have a bar display); creating the axes, labels, and tics; and, if the sectors to be displayed are in the linac and the number of sectors is not too large, getting Z-positions for quads and correctors and displaying them. Whether or not the background display is

BPM SOFTWARE INTERNALS Page 3-22 generated on a particular call to BPMDISPZ, the foreground will be generated. Data has been stored in the common block BPMDATA by the co-routine BPMREAD. BPMDISPZ makes two passes through the data. The first is to find the maximum value of TMIT, used for normalizing the TMIT bar display. In the second pass display positions and colors are calculated and the data is displayed. BPMDISPV is called when the values display has been selected. BPMDISPV loops over the micros in the display range. Some of the information needed for the display is in the BPMDATA common block; a variable IND_DAT ("INDex into DATa arrays") is kept in order to locate this information. Other information needed for the display is in the database arrays initialized by BPMGETDB. For indexing into these arrays the variable STA_PTR is used. Finally, the values display needs to know the status of the processor corresponding to each BPMS displayed. This information is in the dynamic storage used for calibration information, which is moved to the local array STATP as needed, one micro at a time. The values display is also supported for toroids in a similar manner (except in this case there is no corresponding processor to worry about).

3.2.7 Data Accumulation For Applications (BPM_AVG) Application code for correlation plots (of different sets of BPM data or of BPM data versus other variables) and for modeling needs acces to BPM data and needs to control when (and to some extent how) the data is collected. These needs are met by the routine BPM_AVG. Before applications code can successfully call BPM_AVG the operator must have as current a valid measurement definition which has been calibrated.

BPM SOFTWARE INTERNALS Page 3-23 Calls to BPM_AVG will then collect data from the micros in the current range. BPM_AVG is an I*4 function which will return .FALSE. if some problem occured serious enough to prevent valid data from being collected for ALL of the micros in the range. If some micros fail and some succeed, BPM_AVG will return some TRUE status. The calling sequence is ISS = BPM_AVG(NMEAS, DEVICE) where NMEAS is an INTEGER*4 variable which is the number of measurements to be averaged (between one and ten, inclusive) and DEVICE is a BYTE variable which may take on the values 1 (measure BPM's only), 2 (measure toroids only) or 3 (measure both). DEVICE is optional. If omitted it defaults to "measure BPMs only". Parameters for the values DEVICE may take on are defined in the include file SLCSYS:BPMPARAM.TXT. Essentially BPM_AVG does the work of a call to BPMDATON followed by a call to BPMDAT (except that there is no group scheduling) or, if it is determined that no measurement preparation is necessary, just a call to BPMDAT. The protocol is changed slightly because of the added flexibility needed to support the input arguments, and a small amount of extra code is needed to determine just when measurement preparation is necessary.

3.2.8 Coroutines And Status Routine

BPM SOFTWARE INTERNALS Page 3-24

3.2.9 Diagnostics

3.2.9.1 TIMING (BPMSYNC) -

3.2.9.2 Single Unit Functions - 1. Select unit (BPMUNIT) 2. Display unit (BPMUNITD) 3. Toggle HSTA (BPMUNITH) 4. Histograms (BPMGET)

3.2.10 Clean-up (BPMUNLOCK, BPMSTOP, BPMCANDEF)

3.2.11 Miscellany

3.2.11.1 Logical Name Initialization (BPMINIT) -

3.2.11.2 Damping Ring Lifetime Display (BPM_DRLIFE) -

3.2.11.3 Damping Ring Ungated Read -

3.3 MICRO

3.3.1 Over-all Control Structure (BPMO_DRVR)

BPM SOFTWARE INTERNALS Page 3-25

3.3.2 Structure And Handling Of Beam Segments (relevant Parts Of BEAMDEF.P86; rationale for splitting code into Fortran and PLM pieces)

3.3.3 Initialization (BPMINIT)

3.3.4 Common Elements Of Calibration And Measurement:

3.3.4.1 Hardware Checks (PDU_CHECK, ONLINE, Re-get Relevant HSTAs) -

3.3.4.2 Preparation (set Up Timing And Reading Camac Packages; TIMEPACK, BPMPACK) - Trickle-down messages Data processing, reply to SCP

3.3.5 Calibration (CALBPREP, BEAMSEG$INIT, MUXSET, CALBPROC, BEAMSEG$CAL, MEASMULT)

3.3.6 Measurement (MEASPREP, BEAMSEG$PREP, ATTENPACK, BEAMSEG$PROC)

3.3.7 Clean-up (BEAMSEG$STOP, BEAMSEG$DEL, BPMCAN)

3.3.8 Miscellany:

BPM SOFTWARE INTERNALS Page 3-26

3.3.8.1 Communication Between Fortran And PLM (MISSING_LINK) -

3.3.8.2 Initialize When Crate Goes On (BPMPINIT) -

3.4 (APPENDIX) DATABASE

3.5 (APPENDIX) OTHER DATA STRUCTURES

3.5.1 Calibration Files Whenever a calibration is done, two files are written. One is an Ascii file which is essentially the same as the display generated. This file has several header records: a title line including a time stamp and SCP id, individual records for Display Group, micro range, PP, TS, bunch, bunch delay, attenuation, and beam button number, and then a couple of blank records. Then, for each micro there is a line for the Ascii microname. If the micro was successfully calibrated, this is followed by one record of calibration information for each BPMP. If the micro was not successfully calibrated, there is an explanatory line (e.g., "CALIBRATION FAILED" or "BPMs OFFLINE") The unformatted file only contains information for the micros which have successfully-calibrated BPMs (toroid-only sectors won't be included). This file has two header records. The first contains the name of the Display Group, the second a bitmap of the successfully calibrated micros. Then for each such micro there is a record containing the bitid of the micro, a record containing the number of BPMP units in the sector, and one record of calibration information for each BPMP.

BPM SOFTWARE INTERNALS Page 3-27

3.5.2 Measurement Definition Files

3.6 (APPENDIX) FUNCTION CODES (WITH FORM OF DATA)

3.7 (APPENDIX) ROUTINES

3.7.1 Alphabetical, With Description Of Arguments

3.7.2 By Function (who Calls Whom)

3.8 (APPENDIX) DATABASE

CHAPTER 4 TIMING SYSTEM

4.1 INTRODUCTION The SLC timing system allows precision (~1-2 nsec) control of the trigger times of klystrons, beam position monitors, and other devices on a pulse-to-pulse basis at up to 360 Hz. Facilities exist to set up and adjust the timing of devices or groups of devices independently for beam pulses having different destinations and purposes, which are run in an interlaced fashion during normal machine operation. The interlaced operation of beams with different paths, repetition rates, energies, and functions is based on a 16-bit code called PPYY. This code is used by the timing software and hardware to select the times at which devices should be triggered on an upcoming machine pulse. The high order eight bits, called PP or the "beam code", are used to select the time delays for klystrons, kicker magnets and other devices which are needed to produce a specific type of beam. The low order eight bits, called YY, are used to synchronize additional devices; for example, when a user wishes to gate and readout beam position monitors.

TIMING SYSTEM Page 4-2 The reference signal for timing, a 476 MHz cw signal with a phase-locked 2.1 nsec "fiducial pulse" superimposed at a rate of 360 Hz, appears on the main drive line. Communication of PPYY occurs on a dedicated subchannel of the CATV communications cable, the same cable which is used for communication between control programs residing in the VAX and the local micros. The same timing software runs in each of the sector microprocessors, with the particular configuration of triggered devices being specified in the appropriate section of the SLC database. In addition to the sector micros, there is a special micro, the Master Pattern Generator, which is responsible for broadcasting the PPYY code for each machine pulse. The PPYY code is broadcast on the cable through a Cable Access Transmitter (CAT)module and received by a Cable Access Receiver (CAR) module in each of the sector micros. Receipt of PPYY by the Cable Access Receiver module causes the Pattern Receiver Interrupt Module to produce a Multibus interrupt that invokes an interrupt handler in the micro's timing job.

4.1.1 THE PROGRAMMABLE DELAY UNIT (PDU) A central feature of the timing system is the Programmable Delay Unit (PDU) CAMAC module. The PDU has 16 channels, each of which can produce a trigger at a different time with respect to the fiducial. The PDU is clocked by a signal from the fiducial detector, which produces a 119 MHz pulse train (476 Mhz Main Drive Line signal divided by 4) with a missing pulse at fiducial time. Thus the PDU counts

TIMING SYSTEM Page 4-3 "ticks" of approximately 8.4 nsec (1/119MHz) starting from the fiducial. The output pulses from the sixteen channels of the PDU are distributed on the upper backplane of the CAMAC crate. These signals may also be brought out through the front panel of the Simple Timing Buffer (STB) CAMAC module. Each PDU channel can be programmed in one of four different modes. The timing system software uses information in the database to determine in which mode a channel is to be used. Internal to the PDU is an array, the pattern timing table, which can contain up to 256 19-bit delay values for each of the 16 channels. How (and whether) all these values are used for a given channel depends on which of the four programming modes is used for that channel: o PP mode: the delay time with respect to the fiducial depends on the beam code PP. Delay values for different PP's are stored and updated in an array in the VAX (see next section); the appropriate parts of this array are sent to the microprocessor, which loads them into the pattern timing table of the PDU via CAMAC. o YY mode: The delay time with respect to the fiducial depends on the value of YY. A particular YY value can be made to produce specified delay(s) from specified channel(s) by programming the appropriate locations in the PDU pattern timing table. o Base-rate mode: Only the first 36 locations in the part of the pattern timing table for a given channel are used, as a modulo-36 counter. The pattern of delays in these channels

TIMING SYSTEM Page 4-4 is repeated ten times each second. o Reuse mode: The same delay is produced on every pulse, regardless of the value of the PPYY code.

4.1.2 The T_MATRIX And Timing Data Structures The most important data structure used by the timing control software in the VAX is the T-MATRIX, which is in shared memory, accessible to the SLC Control Programs (SCPs) and to other programs running in the VAX. The rows of the T-MATRIX correspond to the beam codes and the columns to triggered devices. In other words, a row of the T-MATRIX contains the time delay with respect to the fiducial, in units of PDU ticks, for each of the devices in the system that are to be triggered according to the value of the PP part of the PPYY code. The time delay with respect to the fiducial of the pulse produced for a triggered device by its associated PDU channel is the sum of several components: TDELAY = TREF+PDUT+TNOMINAL+OFFSET Two of these components are independent of the beam code and are kept in the database. The first component, TREF, is associated with the PDU, while the second component, PDUT, is associated with the triggered device. TREF is the time delay needed to produce a PDU pulse that is simultaneous with the passage of a reference beam, as seen on an oscilloscope. The PDU pulse is brought to the oscilloscope through an

TIMING SYSTEM Page 4-5 STB, and the signal from the passage of the beam comes through a CAMAC module. The reference beam is produced 1025 microsecond after the fiducial, as measured by a standardized procedure at the injector. Thus TREF is essentially the time of passage of the beam with respect to the fiducial, when all propagation delays are taken into account. PDUT is a "standard" delay with respect to the passage of the beam for the triggered device with which it is associated. TNOMINAL is a term associated with a specific beam code, that takes account of the fact that the beam may be shifted with respect to the reference beam time. TNOMINAL can in fact be different for different sectors of the machine on the same beam code. Any additional corrections needed for the triggered device on a particular beam are represented by the OFFSET term. The T_MATRIX is automatically set up by a program called TGEN, using information in the database. TGEN searches the database for devices that are to be triggered according to the PP beam code, allocates space for each of them in the T-MATRIX, and sets up arrays of pointers into the T-MATRIX. TGEN is run immediately after a new database is generated or after changes have been made in the database that will affect the structure (as opposed to just the values) in the T-MATRIX. After TGEN has been run, saved sets of delay values for triggered devices can be restored to the appropriate locations in the T-MATRIX.

4.1.3 Pulse Class Devices (PCD'S) The PDU is the most important Pulse Class Device (PCD) in the timing system, but there are also two others. These are the Programmable

TIMING SYSTEM Page 4-6 Synchronization Unit (PSU) and the Pulsed Amplitude Unit (PAU). Each of these devices produces outputs depending on the value of the beam code PP, and so their values for all the different beam codes are kept in the T_MATRIX, just as for PDU channels.

4.1.3.1 PSU - The PSU produces a train of pulses starting at a specified delay after the fiducial. The value of this delay (in ticks) is what is kept in the T_MATRIX, while the number of pulses, the pulse spacing, and the pulse width are determined by database parameters (and at present can only be changed by doing a DBEDIT).

4.1.3.2 PAU - The PAU produces a voltage level, depending on the value of the beam code. Thus the value kept in the T_MATRIX for each beam code is not a time delay at all, but rather an index (between 0 and 32 inclusive) into an array of possible voltage levels.

4.1.4 DUPCD'S Each PDU channel that is being used in "programmed" mode (mode 1, 3, or 5) is associated with a device, which will often be referred to as a DUPCD (Device Using Pulse Class Device) in what follows. The most important examples of such devices are KLYS, SBST, and TRIG.

TIMING SYSTEM Page 4-7 Unlike the PDU, the PSU and the PAU are essentially single-channel devices, so they are each regarded as being their own DUPCD, where it is useful to preserve this analogy in the software.

4.1.5 Software Control Of Timing Devices

4.1.5.1 SCP - The SCP allows users to control the delay times that are output by PP-mode PDU channels in a straightforward manner. Users may activate and deactivate triggers from touch panel buttons and may adjust a delay or set of delays from a knob. Such functions are also supported for the PAUs and PSUs, and to some extent, certain other special devices (VDU, TGAS). The YY-mode channels delay times are put into the PDU's pattern timing table on request from the BPM or other software, in advance of the receipt of the desired YY(s). The reuse channel delay times can only be changed by editing the database and then rebooting the micro; these times are not intended to be changed casually. Programming of the base-rate mode PDU channels is also supported in the SCP.

4.1.5.2 Micro -

TIMING SYSTEM Page 4-8 Timing system software support in an individual sector microprocessor is provided by one of a set of jobs running in the multitasking environment provided by the Intel iRMX operating system. The timing job consists of a background task, a pattern interrupt task, and a pattern error interrupt task. Since the machine is run in a pipelined mode, the pattern interrupt task must read the 16-bit code PPYY for the "next plus two" beam from the pattern register on the PRIM board and then broadcast the three pipelined PPYY codes to the CAMAC crates. The most important functions of the timing job's background task are to initialize the PDUs and to update timing delay values in PDU memory upon request from SCPs or other programs running in the VAX. It also initializes and updates the other two Pulse Class Devices (the PAU and PSU modules), and handle some special devices, the Vernier Delay Unit (VDU) and Trigger Gate and Synchronizer (TGAS), each of which produces a delay with resolution smaller than a PDU tick by controlling the value of a timing increment to be added to the output of its associated PDU channel.

4.1.5.3 BDL - There exists a (now nearly obsolete) interactive standalone program called Beam Design Language (BDL) that can be used to change T_MATRIX values. Nearly all of its functionality has been moved to the SCP, but it is still minimally supported and is sometimes useful for testing and debugging of timing related software. See the BDL chapter in BUG for details.

TIMING SYSTEM Page 4-9

4.2 GENERATION OF THE T_MATRIX (TGEN) The program TGEN (actually, a set of subroutines in DBGEN, as well as being available as a standalone image) sets up the T_MATRIX using information in the database. TGEN also fills in several secondaries in the database: o Under the primary :PDU : -- - :CHMO: - Channel modes o Under each DUPCD primary -- - :TPNT: - T_MATRIX column allotted to the DUPCD (exactly one) TGEN allocates space in the T_MATRIX for each DUPCD it finds in the database. Each primary representing a device using a PDU channel and programmed on PP must have the following secondaries: :PDUC: xx,4,3I2; !PDU Channel Assignment (channel mode, !PDU unit number, and channel number) :PDUT: xx,4,1I4; !Standard activate time (ticks w.r.t TREF) :TPNT: xx,4,1I2: !T_MATRIX column (filled in by TGEN) Devices programmed in the modulo-36 channel mode have their own primary (probably :TRBR:) and include the following secondaries:

TIMING SYSTEM Page 4-10 :PDUC: ! - as above ( channel mode is redundant informaton) :TMSK: xx,2,2Z4; ! 36-bit trigger mask :PDUT: xx,2,1I4; ! Time with respect to TREF (ticks) Note that the secondaries TMSK and PDUT are supertype 2 since they are used by the micro at PDU initialization time. No information about the modulo-36 channels is kept in the T_MATRIX. Devices programmed on YY ( :BPMP:, :TORO:, :GADC:, :CALP:) are also searched for in the database by TGEN, even though no information about these devices is kept in the T_MATRIX. This is so that the channel mode (CHMO) secondary can be filled :CHMO: xx,2,16I2; Channel modes in correctly. All PDU channels not assigned to one of the above modes are taken to be reuse channels and are programmed accordingly by the micro when the PDU is initialized. Their times with respect to TREF are kept in the secondary :REUT: xx,2,16I4 under the PDU primary.

4.3 TIMING-RELATED PANELS There are several main classes of timing panels, described below.

TIMING SYSTEM Page 4-11

4.3.1 Master Timing Panel This is the top level panel, from which most other timing panels and various displays are accessed. It includes: o Individual-sector trigger panel select buttons o Timing displays panel select button o MPG code and MPG rate displays o Other panel select buttons

4.3.2 Individual-sector Trigger Panels These are analogous to the magnet and klystron sector panels in that there are a set of switches to choose the devices (in this case DUPCDs) to be controlled and a set of buttons to perform operations on these devices. These panels contain: o DUPCD select switches - Individual DUPCDs - excluding klystrons, whose timing would be handled from the set of klystron control panels (see below). These switches are labelled with DUPCD primary and unit, and alias name, if any. - All DUPCD units of a given primary, e.g. ALL TRIG, so that these groups of DUPCDs can be activated, deactivated, set to given TDES, etc. with a single button press. At present, the only important DUPCD primary associated with PDU's belonging on this panel is TRIG. However, the other DUPCDs namely PSU and PAU can be controlled from these panels.

TIMING SYSTEM Page 4-12 o Beam select button Pushing this button prompts for desired beam and writes it on the button, unless the beam number is hardcoded on the button, in which case no prompt is given. o Timing function buttons These include: - Assign knob to selected DUPCD(s) and beam A knob may be assigned to a single DUPCD or to all DUPCDs of a particular PRIM type (e.g. TRIG). The knob will be labelled with the alias name (up to 6 characters), the beam number, and the time with respect to TREF in nanoseconds, in the case of a knob assigned to a single unit. For example: ALIAS 12 -345.0 If there is no ALIAS in the database , then the first two letters of the primary name, and the unit number are used to label the knob, e.g. TR 204 5 84.03 for TRIG, 204 on beam 5. - Activate selected DUPCD(s) on selected beam This sets the pulse time to the "standard" activate value derived from the database quantities TREF and PDUT and the NOMINAL time for the sector.

TIMING SYSTEM Page 4-13 - Deactivate selected DUPCD(s) on selected beam - Reactivate selected DUPCD(s) on selected beam - Enter TDES for selected DUPCD(s) and beam: To be used in cases where it is inconvenient to knob from the standard activate value. Prompts for desired time with respect to TREF+NOMINAL (in nanoseconds). - Deactivate selected DUPCD(s) on all beams - Timing displays buttons - Diagnostics panel select button These timing unit select, timing functions, and timing knob assign buttons also appear on a number of special purpose panels in the SCP.

4.3.3 DUPCD Displays Panel Two displays having to do with DUPCDs are accessed from this panel: 1. DUPCD-active display: Shows the activity of selected DUPCDs on all beams. 2. Display giving timing data for selected DUPCDs on a single beam: Includes alias name, PDUT, time with respect to TREF+NOMINAL, and NOMINAL time for the sector, plus identification by database primary, micro, and unit. The DUPCDs are selected from a menu of buttons labelled with the database primary names of DUPCDs (TRIG,KICK,KLYS, etc) or ALL*. The micro(s) will be selected from one of three buttons:

TIMING SYSTEM Page 4-14 1. ALL* micros 2. Individual micro select buttons

4.3.4 Klystron Control Panels There is one such panel per sector, containing: - Device select buttons: - Individual KLYS and SBST units - ALL KLYS - ALL SBST - ALL UNITS (klystron and subbooster) 1. Function select buttons: - Activate selected DUPCD(s) on selected beam This sets the pulse time to the "standard" activate value derived from the database quantities TREF and PDUT and the NOMINAL time for the sector. - Deactivate selected DUPCD(s) on selected beam - Reactivate selected DUPCD(s) on selected beam - Enter TDES for selected DUPCD(s) and beam: To be used in cases where it is inconvenient to knob from the standard activate value. Prompts for desired time with respect to TREF+NOMINAL (in nanoseconds). - Deactivate selected DUPCD(s) on all beams - Timing displays buttons These panels are similar to the sector trigger timing panels. The function of the Activate button is basically to set the timing to the normal activate value derived from the database TREF for the PDU, the PDUT for the selected KLYS or SBST, and the current value of T_NOMINAL for the selected micro and beam, just as for TRIGs. However, if a KLYS is being activated, the SBST is also automatically activated if

TIMING SYSTEM Page 4-15 it is not already active. If the SBST is already active, but at an offset from the normal activate value, then the same offset is added to the normal KLYS value. Also whenever a KLYS or SBST is to be activated, its TMSK is checked for compatibility with the selected BEAM TMSK. The deactivate and assign-knob functions work the same as on the trigger timing panels.

4.3.5 Diagnostics Panel This is accessible from individual-sector timing panels. It contains additional diagnostics and displays, including: o Single unit database display for selected DUPCD o Single unit database display for selected PDU. o Display of channel allocation in selected PDU. o Button to reinitialize the selected PDU. This reinitializes the PDU just as if the micro were being rebooted, downloading the current data from the the T_MATRIX and database. o Buttons to select any other PDU in the micro

4.4 MAJOR SUBROUTINES IN THE SCP

4.4.1 T_MATRIX_ADJUST This is the main routine to make changes in the T_MATRIX via the sector timing panels. It handles the activate, deactivate, enter desired time, and deactivate-on-all-beams functions described above

TIMING SYSTEM Page 4-16 for the individual-sector timing trigger panels. Similarly, it handles the corresponding functions on the klystron timing panels (and on any other panels where this functionality is needed). T_MATRIX_ADJUST calls a routine TIMEUNIT_FILL to obtain some database information about the selected DUPCD unit(s) and store it in a common block. Then T_MATRIX_ADJUST calls TIME_BTN_HANDLER if one of the timing fucntion buttons (e.g. activate, deactivate, etc.) has been pushed.

4.4.2 TIME_BTN_HANDLER This routine handles the buttons that actually change T_MATRIX value(s) (or in certain cases, e.g. for TRBR's, database value(s)) for the selected device(s). The actual work of updating the TMATRIX and the PDU (or PAU, or PSU beam matrix in the micro) are done by calling the appropriate timing utilities.

4.4.3 T_MATRIX_KNOB This routine takes care of knob assignment, rotation, and deassignment on the sector trigger and klystron panels, as well as on any other panels where it is desired to assign a timing knob. It is permitted to assign ALL* units belonging to a DUPCD primary (e.g. TRIG or KLYS) to a knob. When the knob is turned, the T_MATRIX element(s) are updated and then a message is sent to the micro telling it to update the corresponding elements in the PDU internal memory (or the PAU internal memory, or the PSU beam matrix in micro memory) The actual work of updating the TMATRIX and the device are done by calling timing

TIMING SYSTEM Page 4-17 utilities.

4.4.4 KTRG_PNL This is the routine that handles the klystron and subbooster timing panels (just as T_MATRIX_ADJUST handles the trigger timing panels). Like T_MATRIX_ADJUST, it calls TIMEUNIT_FILL and TIME_BTN_HANDLER.

4.4.5 DEVICE_ACTIVE_DISP This routine creates the display showing the activity of selected DUPCDs on all beams. A '*' is displayed if the device is active on the beam, and a blank is displayed if it is not active on the beam.

4.4.6 TIMING_DISP This routine creates the display showing timing data for selected DUPCDs on a selected beam.

4.4.7 DEVICE_TIME_DISP This routine displays the timing values for the selected DUPCD for all beams on which it is currently active. There are also special branches in this routine to permit it to be used for TRBR's (which function independently of beam code), and for VDU's and TGAS's (each of which is essentially a vernier device that adds a small increment to the time output by its associated PDU channel.

TIMING SYSTEM Page 4-18

4.4.8 TIME_DIAGNOSTICS_PANL Handles the database displays, PDU channel allocation display, reinitialize PDU function, and PDU unit select on the timing diagnostics panel.

4.4.9 PDUXPGM, PDU_GETDELAY, PDU_GETPP, PDU_READ_PDU, And PDU_READ_STB These routines support the PDU diagnostic that compares the time values in the T_MATRIX, the time values inside the PDU, and the actual time values as seen through the STB.

4.4.10 BEAM_DISPLAY The routine generates the MPG rate and MPG code displays

4.4.11 BCOD_PNL And BCOD_DISP These are the panel handler and display routines used by the beam rate control panel.

4.5 BASE RATE TRIGGERS (TRBR'S) The database primary TRBR is the logical "device" associated with a base-rate (mode 6) PDU channel, just as the primary TRIG is a logical "device" associated with a program mode (mode 1,3, or 5) PDU channel. TRBR data is NOT kept in the T_MATRIX, since the T_MATRIX is indexed by beam codes and the output of a TRBR follows a repetitive pattern

TIMING SYSTEM Page 4-19 that is independent of the beam codes broadcast by the MPG. However, the exact analog of a T_MATRIX value is kept in the PDUN secondary under the primary TRBR. The pattern according to which this value is output by the PDU channel is determined by the TMSK secondary. The TRBR primary also has a secondary PDUT similar to that for TRIGs. Namely, the "standard" activate value for the TRBR is: TREF(of the PDU) + PDUT(of the TRBR) Note that T_NOMINAL values are ignored as far as TRBRs are concerned. The functions supported for TRBRs are similar to those for TRIG, KLYS,etc.): o Activate: Set to nominal value (PDUN = PDUT) and update PDU channel o Deactivate: Set the usual high order bit in PDUN, and update PDU channel o Reactivate: Remove the usual high order bit in PDUN, and update PDU channel o Enter desired value in nsec w.r.t. TREF, and update PDUN and the PDU channel o Change PDUN with a knob, updating PDU channel These functions are supported by branches in the following routines:

TIMING SYSTEM Page 4-20 o TIMBTNHND (call TRBR utilities where appropriate) o TIMEUNITFILL o TMATADJ (since TRBR's are supported on the normal trigger panels) o T_MATRIX_KNOB (separate branch(es) for TRBRs, which can use the same knob assign buttons used by TRIGs and other DUPCDs. The TRBR utility routines are: TRBR_GET TRBR_PUT TRBR_ACTIVATE TRBR_DEACTIVATE TRBR_REACTIVATE For details on these routines, see the utilities chapter in BUG.

4.6 THE VERNIER DELAY UNIT (VDU) The VDU is a device that receives input from a PDU channel and produces an output at a small specified increment of time later. Since the VDU has a very limited range (about 10 nsec), the PDU channel time as well as the VDU setting must change in a coordinated way when one requests an output at a specified delay with respect to the fiducial.

TIMING SYSTEM Page 4-21 It is not necessary to support the standard activate, deactivate, and reactivate functions for the VDU/PDU combination since they are already supported for the PDU channel alone. There is an enter-TDES function for the VDU/PDU combination, so that the user can set the VDU/PDU combination to a selected value before assigning a knob. The knob routine simply checks that the PDU channel is active on the desired beam (and no others) and then allows the knob to move the VDU/PDU combination from wherever it is. There exist the following utilities to read and set the value of a VDU/PDU combination: VDU_PDU_READ(MICR,UNIT,BEAM,NSEC_WRT_STD) VDU_PDU_SET(MICR,UNIT,BEAM,NSEC_WRT_STD) Here UNIT is the db unit number of the VDU. NSEC_WRT_STD is the time in nsec of the VDU/PDU with respect to TREF+PDUT+T_NOMINAL for the DUPCD associated with the PDU channel. The VDU primary has a 1R4 secondary VDES in which the current VDU setting is kept. The VDU register has 0.1 nsec per bit and a total range of 10.5 nsec. The VDES value is stored in units of nsec. The VDES secondary is updated by the above utilities every time the VDU is read or set. Also, the routine VDUINIT in the micro (called upon crate initialization) sets the VDU register according to the current database value of VDES. The VDU_PDU_SET routine sends a message to the micro, where another routine does the CAMAC operations and much of the other work.

TIMING SYSTEM Page 4-22

4.7 TRIGGER GATE AND SYNCHRONIZER (TGAS) There is another device, the Trigger Gate And Synchronizer (TGAS) CAMAC module, which produces a (gated) vernier delay of a PDU trigger by synchronizing it to a 178.5 MHz signal whose phase is controlled by a DAC. The TGAS+DAC combination is thus somewhat analogous to a VDU, in that it makes a fine adjustment to the time of a trigger produced by a PDU channel. Enter-TDES and knobbing are supported for the TGAS/PDU, via the following utilities (analogous to those mentioned above for the VDU/PDU): TGAS_PDU_READ(MICR,UNIT,BEAM,NSEC_WRT_STD) TGAS_PDU_SET(MICR,UNIT,BEAM,NSEC_WRT_STD) The TGAS_PDU_SET routine sends a message to the micro, where another routine does the CAMAC operations and much of the other work. It is important to do the CAMAC from the micro rather than using transparent CAMAC from the VAX, so that all the CAMAC operations can be put into a single package. A TGAS initialization routine (TGAS_INIT) exists in the crate job in the micro. This routine sets up the TGAS and DAC in accord with the current database values for :VDAC: and :EDGE:.

4.7.1 Details Of Algorithm The leading edges of the 178.5 MHz waveform move backwards in time one full cycle as the DAC setting goes from 8080H to FF80H (on channel 2

TIMING SYSTEM Page 4-23 at least). The TGAS takes the PDU input trigger and shifts it so that the TGAS output is synchronized to a leading edge of the 178.5 MHz waveform. The PDU input is first resynchronized to either the leading or falling edge of the 119 MHz clock, depending on the value of :EDGE:. The output of the TGAS then occurs at the time of the first 178.5 MHz leading edge following the resynchronized PDU input. The algorithm for setting the TGAS/DAC/PDU combination is contained in the micro timing job routine TGAS_WR, which should be consulted for details. However the basic ideas are as follows: Let NSEC_WRT_STD = desired time in nsec w.r.t. TREF + T_NOMINAL + PDUT and let PDU_TICKS_STD = standard time TREF+T_NOMINAL+PDUT (in ticks). Then NSEC_WRT_STD = (an even number of PDU ticks)/0.119 + (U_119 + 0.5*EDGE)/0.119 + FR_NSEC where U_119 = 0 or 1 ticks EDGE = 0 or 1 depending on whether TGAS resynchronizes to falling or leading edge of the 0.119 MHz waveform FR_NSEC = Leftover fractional part of 0.119 MHz cycle (in nsec) One wants to keep the output as smoothly varying as possible as the

TIMING SYSTEM Page 4-24 PDU ticks, the value of EDGE, and the DAC voltage are juggled. Thus, the change from one value of EDGE to the other is done when adjacent leading and falling edges of the 119 MHz wave form are symmetrically centered between the two leading edges of the 178.5 MHz waveform. Also, the jump from one end of the DAC's range to the other is done at a seleted place where the polynomial is supposed to give a smooth result (?). The conversion between DAC voltage and nsec is quite nonlinear (the conversion polynomial VCNV has 6 terms) There are roughly 10 DAC volts per cycle of 178.5 MHz.

4.8 TIME JOB IN THE MICRO The TIME job contains three tasks: a background task, a normal pattern interrupt task, and an error pattern interrupt task. The normal pattern interrupt task does programming of pulse class devices such as PDU's (programmable delay units) and PAU's (pulsed amplitude units) on a pulse to pulse basis. The error pattern interrupt task handles interrupts caused by error patterns. The background task, running at lower priority, performs all other functions of the TIME job. At start-up, the main things done by the TIME job are the following: o Download the data from the appropriate sections of the T_MATRIX to the micro. The section of the T_MATRIX that contain timing data for a particular Pulse Class Device (PDU, PAU, or PSU) in a particular micro will sometimes be referred to as the "beam matrix" for that device.

TIMING SYSTEM Page 4-25 o Initialize the PDUs, PAUs, and PSUs. o Initialize the PPYYNMI routines, which allow other subjobs to request that certain of their own routines be executed at NMI level. o Create the error interrupt task. o Set up and turn on the pattern interrupt handler. In the following sections, the downloading of T_MATRIX data and the initialization of the timing devices are discussed in more detail.

4.8.1 Downloading Of T_MATRIX Data The downloading of data for PDUs and PAUs differs somewhat from that for PSUs, because the beam matrices are stored internal to the PDUs and PAUs but must be kept in an array in the micro for the PSUs. Thus the crate job needs to have a mechanism for reacquiring new T_MATRIX data not only when the micro is IPLed but also whenever the PDU and PAUs in a crate need to be reinitialized. For PDUs and PAUs, the downloading of data is initiated by a message from the crate subjob in the micro (specifically, from routine CRATE_INIT) to PARANOIA. For PSUs, the downloading of data is initiated by a message from the routine PSU_SETUP (in the timing job) to PARANOIA. In all cases, PARANOIA then sends the data from the T_MATRIX to the timing job in the micro, by calling the timing utility routine TIME_SEND_DATA. PARANOIA sends the data for one PDU or PAU at a time, and the appropriate timing job initialization routine (PDU_INIT or PAU_INIT) is called for that device. PARANOIA sends the data for all the PSUs

TIMING SYSTEM Page 4-26 together, and the data is stored in the micro by the routine PSU_RCV_DATA. The CAMAC commands that initialize the PSU are done from the routine PSUINIT.

4.8.2 Initialization Of PDU's Upon receipt of the data from the T_MATRIX, the timing job routine PDU_INIT gets the rest of the data it needs to put into the PDU (recall that not all 16 PDU channels necessarily have data in the T_MATRIX --- only "PP channels" do) Once all the data has been obtained for a PDU, PDU_INIT can do the CAMAC commands to initialize the PDU: F(9) : Disable backplane drivers and LAM; Set all 16 channels in mode select table to reuse value; Set all entries in Pattern Timing Table reuse locations to 0FFFFFH Set up for each channel n that is to be fired on PP: Initialize pattern timing table pointer register (PTTPR) for channel n: F(17)A(0) Data: n 0 ------------ Set up mode select table entry for channel n:

TIMING SYSTEM Page 4-27 F(17)A(1) Data: 001,011, or 101, depending upon whether pattern input register 0,1, or 2 will be used. Write values into PTT for channel n: F(16)A(0) Data: 19-bit timing values for channel n (N_BEAMS or 254 values, depending on whether entire table was initialized to 07FFFFH. Also must put reuse value into 255th slot if value other other than 07FFFFh is desired.) Set up for each channel m that is purely a reuse channel: Initialize PTTPR : F(17)A(0) Data: m F F ------------ Set up mode select table entry for channel m: F(17)A(1) Data: 111 Write value into PTT for channel m: F(16)A(0) Data: 19 bit reuse value for channel m

TIMING SYSTEM Page 4-28 Set up for each channel q that is to be fired on YY: Initialize PTTPR : F(17)A(0) Data: q 0 ------------ Set up mode select table entry for channel q: F(17)A(1) Data: 000,010, or 100 Set up for each beam-pattern-independent channel s using time slot counter: For each location x in channel s of the PTT: Initialize PTTPR: F(17)A(0) Data: s x (x must be between ------------ 1 and 36) Write value into PTT: F(16)A(0) Data: 19 bit timing value Set up mode select register: F(17)A(1) Data: 110

TIMING SYSTEM Page 4-29 Read-back of data in pattern timing table and mode select table F(26)A(1) : Enable backplane drivers

4.8.2.1 Initialization Of The PAU - The routine PAU_INIT receives the T_MATRIX data and does CAMAC commands to initialize the PAU in a way that is analogous to the way PDU_INIT initializes PDUs. It then sends a message to the MGNT subjob so that it can do its part of the PAU initialization. Because the initialization sequence is rather involved, a database secondary called FLAG is kept under the PAU primary. It is updated at each stage of successful initialization so that in case of problems, one can see how far it got.

4.8.2.2 Initialization Of The PSU - Recall that PSUs do not in general just produce a single pulse at a specified delay after the fiducial, but rather produce a train of pulses at the specified delay. The delays are obtained from the T_MATRIX and stored in the micro as described above. The routine PSUINIT simply gets some database information and does the CAMAC commands telling the PSU how many pulses in the pulse train, the spacing between pulses, the width of the pulses, and whether the PSU is to run in programmed or reuse mode.

TIMING SYSTEM Page 4-30

4.8.3 Updating PDU's, PAU's, And PSU's When one changes the T_MATRIX using functions in the SCP, messages are sent to the micro to update the devices accordingly. Such messages are handled by the timing job routine TIMING_UPDATE.

4.8.3.1 Updating The PDU - TIMING_UPDATE calls the routine PTT_SGL_UPDATE or PTT_CHAN_UPDATE to update respectively a single value or an entire single channel of the PDU. 1) Single value, row, or column of beam matrix Initialize (Pattern Timing Table Pointer Register (PTTPR): F(17)A(0) Data: n (pp) ------------ where n=PDU channel index, pp=beam index F(16)A(0) Data: new 19-bit timing value(s) 2) Entire beam matrix Reinitialize the PDU as above

TIMING SYSTEM Page 4-31

4.8.3.2 Updating The PAU - TIMING_UPDATE calls the routine PAU_UPDATE, which updates the entire PAU beam matrix, even if only a single value has actually changed.

4.8.3.3 Updating For The PSU - Nothing needs to be done to the PSU. TIMING_UPDATE just updates the appropriate entry or entries in the PSU beam matrix (the array BEAM_PP_PSU).

4.8.4 Pattern Interrupt Handler The basic functions done by the interrupt handler are the following: o Receives PPYY for the n+2 beam. o Updates the array of PPYY's for the n+2,n+1, and n beams. o Checks to see whether the PP is valid (less than or equal to N_BEAMS, the maximum beam number supported by the software) o Check the flag SKIP. Proceed if SKIP is .FALSE., otherwise skip further processing on this pulse. o Broadcasts these 3 pipelined beam codes to each crate in the micro that contains PDUs and/or PAUs : F(19)A(8) Data=nth PPYY : broadcast nth beam code F(19)A(9) Data=n+1 PPYY : broadcast n+1 beam code F(19)A(10) Data=n+2 PPYY : broadcast n+2 beam code

TIMING SYSTEM Page 4-32 o Sends CAMAC pkg to load PSU's, if there are any: F(16)A(0) Data: Delay value o Call any NMI routines set up by calls to PPYYNMISET

CHAPTER 5 BEAM DEFINITION LANGUAGE (BDL)

5.1 INTRODUCTION BDL is an interactive language for setting values in the T_MATRIX. BDL operates on one BEAM at a time, allowing DEVICES to be ACTIVATED and DEACTIVATED and KLYSTRONS to ACCELERATE or STANDBY. KLYSTRONS may be set to ACCELERATE over an explicit range or may ACCELERATE until some energy GAIN is reached. All PDU's have a reference time defined by the arrival over the beam position monitor cables of signals from the reference beam. (The reference beam leaves the gun about 1025 micro seconds after the fiducial.) Normally all times are specified with respect to the PDU reference time TREF. A BDL global time offset called NOMINAL may be SET to be added to all times of DUPCDs belonging to a specified range of micros. Additionally an OFFSET may be specified on an ACTIVATE command which will also be added to the time for the particular device being activated. The exception is the qualifier ABSOLUTE on the ACTIVATE command which sets precisely the specified number in the T_MATRIX. All these commands operate only on the BEAM which has been SET.

BEAM DEFINITION LANGUAGE (BDL) Page 5-2

5.1.1 BEAM BDL operates on only one BEAM at a time (see SET/BEAM and SHOW/BEAM). The number BEAM equals the row of the T_MATRIX.

5.1.2 T_MATRIX The T_MATRIX is the master array in the VAX holding all the BEAM code dependent timing information. Be aware of the fact that changing the T_MATRIX does not necessarily transmit the new data to the micros where it is used (see the SEND and NOSEND commands). Each column of the T_MATRIX corresponds to a DUPCD (device using pulse class device) specified by PRIM,MICR,UNIT (PRIM = database primary, e.g. KLYS,SBST,TRIG,GUNS; MICR = sector micro name; UNIT = database unit number) Each row of the T_MATRIX corresponds to a BEAM. Initially (i.e., immediately after a DBGEN and before any BDL commands have been issued from a command file or by an interactive user) the T_MATRIX contains only null values, which are the values that cause PDU's to produce no pulse (For example, FFFF for Type 1 PCD's). Timing data in the T_MATRIX can be set to non-null values using the BDL commands ACTIVATE and ACCELERATE, for example.

5.1.3 DUPCD Pulse controlled devices are called Devices Using Pulse Class Devices (DUPCD's) to distinguish them from Pulse Class Devices. (PCD's).

BEAM DEFINITION LANGUAGE (BDL) Page 5-3 Examples of DUPCD's are Klystrons, sub-boosters, pulse magnets and toroids. DUPCD's can be explicitly activated by BDL, using the ACTIVATE command. Normally klystrons and sub-boosters are activated implicitly by the ACCELERATE and STANDBY commands, rather than by the ACTIVATE command.

5.1.4 PCD There are 3 kinds of pulse class devices (PCD's) at present. All 3 kinds contain 16 channels, each of which can produce a pulse at a specified delay after the fiducial. o Type 1: PDU (Programmable delay unit) using 16 bit transfers. Most of the T_MATRIX consists of timing data for DUPCD's controlled by type 1 PCD's. o Type 2: PDU using 19 bit transfers. Identical hardware to Type 1, but programmed differently Not as highly optimized as Type 1; used only where necessary. o Type 3: PAU (Pulsed amplitude unit) The data in the T_MATRIX is NOT a time value in ticks, as for Types 1 and 2, but rather is a number from 0 to 15 specifying the channel of the PAU to be used by the DUPCD and BEAM corresponding to that entry of the T_MATRIX. It will be apparent that some BDL commands do not apply to PAU's.

BEAM DEFINITION LANGUAGE (BDL) Page 5-4

5.1.5 BIT-ID Each micro has a BIT-ID, which is a number between 0 and N_MICROS (N_MICROS=63). BDL uses the micro name (e.g., LI01) rather than the BIT-ID in commands, however the user needs to be aware of the numerical order of the micros when issuing commands such as ACCELERATE and SET/NOMINAL that can take a range of micros as a parameter. Micros LI00-LI31 map to bitids 0-31 and the remaining micros map as follows: Name Bitid DR01 32 DR02 33 DR03 34 BL90 35 CL00 36 MP00 37 CL01 38 MP01 39 DR11 40 DR12 41 DR13 42 CA00 43 CA01 44 CA02 45 CA03 46 CA04 47 CA05 48 FF00 49 FF01 50 FF02 51 FF03 52

5.2 COMMANDS

5.2.1 SET SET sets various parameters.

BEAM DEFINITION LANGUAGE (BDL) Page 5-5

5.2.1.1 /BEAM - SET/BEAM=n defines the beam being operated on by BDL. n is an integer BETWEEN 0 and the maximum number of beams N_BEAMS. Note that BEAM number N_BEAMS is reserved as a pure STANDBY beam and is the beam at which BDL is set before any commands have been issued by the user. Before proceeding to do commands that change data in the T_MATRIX, it is necessary to do SET/BEAM=n where n is greater than or equal to 1 and is less than N_BEAMS (N_BEAMS=64 at present).

5.2.1.2 /NOMINAL - SET/NOMINAL=nnn defines a nominal time to be added to all DUPCD's in a specified range of micros, for the BEAM that is currently set. nnn is a signed integer number of ticks (tick=reciprocal of 119 MHz, approximately 8.403 nsec). This command takes an optional argument of the form SET/NOMINAL=nnn MIC1 or SET/NOMINAL=nnn MIC1,MIC2 where the argument is the micro or range of micros over which the NOMINAL value is to be set. In the second form, MIC1 must be a microname with a smaller BIT-ID than MIC2. (A table of micro names with their corresponding BIT-ID's can be seen by issuing the BDL command HELP/BIT-ID ). If this optional argument is not present, then NOMINAL is applied to all micros, i.e., nnn is added to all timing data (not, of course, to PAU channel data) in row BEAM of the T_MATRIX.

BEAM DEFINITION LANGUAGE (BDL) Page 5-6 Note that the NOMINAL values are used to increment the T_MATRIX values derived from the database TREF's and PDUT's. They are stored in a VAX global section and, like the T_MATRIX, are not stable across DBGENs. All NOMINAL values become zero at DBGEN time, but can be reinstated if desired, by making a BDL command file to be rerun after doing the DBGEN.

5.2.2 SHOW SHOW displays the value of various parameters and generates several displays

5.2.2.1 /BEAM - SHOW/BEAM displays the value of the BEAM being operated on by BDL.

5.2.2.2 /NOMINAL - SHOW/NOMINAL displays a table of the value of the nominal time offset in ticks for each micro, for the currently set BEAM. Note that only micros which actually have DUPCD's in the T_MATRIX are shown.

5.2.2.3 /DEVICE - In the context of BDL, a DEVICE is generally a DUPCD (Device Using Pulse Class Device) rather than a PCD (Pulse Class Device).

BEAM DEFINITION LANGUAGE (BDL) Page 5-7 SHOW/DEVICE identifies and shows the associated T_MATRIX value for the DEVICE (DUPCD) last operated upon. SHOW/DEVICE=(PRIM,MICR,UNIT) shows the associated T_MATRIX value for any DUPCD (specified by PRIM,MICR,UNIT) in the T_MATRIX. Note that the T_MATRIX value in ticks is shown (in decimal), as well as the time with respect to TREF (in nanoseconds), for DUPCD's using Type 1 and Type 2 PCD's. The T_MATRIX value for a DUPCD using a Type 3 PCD (i.e., using a PAU) is a channel number of the PAU, between 0 and 15.

5.2.2.4 /T_MATRIX - SHOW/T_MATRIX dumps a set of rows of the T_MATRIX. Note that the matrix is on its side to make the display more understandable. By default, the first 5 rows are displayed. Optionally, a row or range of rows may be specified as follows: SHOW/T_MATRIX=x SHOW/T_MATRIX=(x,y) where x and y are greater than or equal to 1 and are less than or equal to N_BEAMS. y must be greater than or equal to x, and at most 5 beams can be displayed at a time with the SHOW command (i.e., y-x must be no more than 4). Note that the T_MATRIX values in this display are in hex.

BEAM DEFINITION LANGUAGE (BDL) Page 5-8 After the display of the T_MATRIX, a display of the channel assignments of the DUPCD's (Devices Using Pulse Class Devices) is given for each PCD (Pulse Class Device). Then a display of the first column number and total number of columns for each micro in the T_MATRIX is given. It is possible to abort the rather long listing produced by the SHOW/T_MATRIX command without leaving BDL, by doing a Control O.

5.2.2.5 /KLYSTRONS - SHOW/KLYSTRONS displays a map of klystron activity by sector. An 'A' indicates ACCELERATE timing, an 'S' indicates STANDBY timing, a '-' indicates no pulse, and a blank indicates the device is unknown to BDL. (If it should really be there, a database error or omission is indicated.)

5.2.3 PRINT PRINT prints various displays on the line printer

5.2.3.1 /T_MATRIX - PRINT/T_MATRIX dumps a set of rows of the T_MATRIX. Note that the matrix is on its side to make the display more understandable. By default, the first 10 rows are displayed. Optionally, a row or range of rows may be specified as follows: PRINT/T_MATRIX=x PRINT/T_MATRIX=(x,y)

BEAM DEFINITION LANGUAGE (BDL) Page 5-9 where x and y are greater than or equal to 1 and are less than or equal to N_BEAMS. y must be greater than or equal to x, and at most 10 beams can be displayed at a time with the PRINT command (i.e., y-x must be no more than 9). After the display of the T_MATRIX, a display of the channel assignments of the DUPCD's (Devices Using Pulse Class Devices) is given for each PCD (Pulse Class Device). Then a display of the first column number and total number of columns for each micro in the T_MATRIX is given.

5.2.3.2 /NOMINAL - PRINT/NOMINAL prints a table of the value of the nominal time offset in ticks for each micro, for the currently set BEAM. Note that only micros which actually have DUPCD's in the T_MATRIX are printed. Note that the NOMINAL values are an increment to the T_MATRIX values derived from the database TREF's and PDUT's. All NOMINAL values vanish at DBGEN time and can only be saved across DBGEN's by making a BDL command file to be rerun after doing the DBGEN.

5.2.3.3 /KLYSTRONS -

BEAM DEFINITION LANGUAGE (BDL) Page 5-10 PRINT/KLYSTRONS displays a map of klystron activity by sector. An 'A' indicates ACCELERATE timing, an 'S' indicates STANDBY timing, a '-' indicates no pulse, and a blank indicates the device is unknown to BDL. (If it should really be there, a database error or omission is indicated.)

5.2.4 ACTIVATE ACTIVATE PRIM,MICR,UNIT "turns on" the specified device. The default timing is that implied by the PDU TREF, the device PDUT, and the NOMINAL time. Note that the PRIM,MICR,UNIT for all DEVICEs (DUPCDs) in the T_MATRIX can be seen using the BDL command SHOW/T_MATRIX or PRINT/T_MATRIX.

5.2.4.1 /OFFSET - ACTIVATE/OFFSET=nnn PRIM,MICR,UNIT is the same as activate but adds nnn ticks to the time value. Note that an OFFSET value is not saved anywhere, it is simply added to the T_MATRIX value that would otherwise be derived from the database TREF and PDUT (and the NOMINAL value, if any). All memory of the OFFSET value is lost as soon as the T_MATRIX value for the ACTIVATEd device changes again for any reason.

5.2.4.2 /ABSOLUTE -

BEAM DEFINITION LANGUAGE (BDL) Page 5-11 ACTIVATE/ABSOLUTE=nnn PRIM,MICR,UNIT set the specified device time to nnn. nnn is EXACTLY what goes in the T_MATRIX. Note that all memory of an ABSOLUTE value is lost as soon as the T_MATRIX element for the ACTIVATEd device is changed again for any reason.

5.2.5 DEACTIVATE DEACTIVATE PRIM,MICR,UNIT "turns off" the specified device by setting the implied T_matrix element to the null value (e.g., FFFF for DUPCD's controlled by type 1 PCD's).

5.2.6 ACCELERATE ACCELERATE first klystron /END=last klystron or ACCELERATE first klystron /GAIN=xxx will "turn on" the specified range of klystrons and subboosters. The "first klystron" parameter is specified : MICR,UNIT. Either /END or /GAIN must be specified. If /END=last klystron is specified, last klystron must be in the form (MICR,UNIT) ---note parentheses. Note that the MICR,UNIT for any klystron currently in the T_MATRIX can be seen using the BDL command SHOW/T_MATRIX or PRINT/T_MATRIX. The status of a klystron in the range specified by the ACCELERATE command is checked before putting it on accelerate timing ( the status is in the database secondary :STAT: under the primary :KLYS:). If the status is not OK, the klystron is put on standby timing.

BEAM DEFINITION LANGUAGE (BDL) Page 5-12 The subboosters in the sectors included in the range of the ACCELERATE command are activated by this command. NOMINAL times are added to the klystron accelerate times and to the subbooster times, but not to the klystron standby times.

5.2.6.1 /END - ACCELERATE LI00,11 /END=(LI30,81) will turn on all available klystrons for this BEAM. Note that parentheses are required on the /END qualifier.

5.2.6.2 /GAIN - ACCELERATE LI00,11 /GAIN=18.0 will turn on enough klystrons to produce an 18 GeV beam. If the GAIN specified is too high for the available set of klystrons (as specified by STAT indicating klystron availability and EREF indicating the energy gain for that klystron) an error message will be issued.

5.2.6.3 /BACKPHASE - Backphases the sector(s) included in the range of the accelerate command by changing the phase of the sub-booster(s) by 180 degrees. If a sub-booster receives a trigger on its backphase PDU channel before it receives a trigger on its pattern PDU channel, then it will be backphased on that machine pulse.

BEAM DEFINITION LANGUAGE (BDL) Page 5-13 (Not yet implemented)

5.2.6.4 /SLED - The SLED qualifier does not change any of the timing data in the T_MATRIX, nor does it control the tune of the SLED cavities in any way. However it is used for energy gain calculations by BDL --- if /SLED is present, the energy gains of the klystrons in the range specified in the accelerate command are assumed to be the SLED values. (Not yet implemented)

5.2.7 STANDBY STANDBY first_klystron last_klystron will put the specified range of klystrons on standby timing. Both the first_klystron and the last_klystron must be specified in the form : MICR,UNIT MICR,UNIT. It is wise when designing a BEAM to remember that a fresh beam has all klystrons off. Usually, one would put the whole machine on STANDBY and then set up the ACCELERATE klystrons. Subboosters in the sectors included in the range of the STANDBY command are activated by this command. NOMINAL times are NOT added to the klystron standby times, but ARE added to the subbooster times.

5.2.8 COPY The command

BEAM DEFINITION LANGUAGE (BDL) Page 5-14 COPY n (where parameter n is required) copies the T_MATRIX values for beam n to the currently set BEAM. The nominal values for beam n are also copied.

5.2.8.1 /NOMINAL - The command COPY/NOMINAL n not only copies the nominal values for beam n, but also adds them to the T_MATRIX values of beam n to produce the T_MATRIX values for the currently set BEAM. Obviously this applies only to the T_MATRIX values for Types 1 and 2 PCD's and not to PAU's.

5.2.9 LOADBEAM The command LOADBEAM or, LOADBEAM MICR or, LOADBEAM MIC1,MIC2 loads the T_MATRIX values, for the currently set BEAM only, into the range of micros specified. If no range is explicitly given (i.e., if the first form of the command above is used), the range is taken to be all micros which have DUPCD's in the T_MATRIX.

5.2.10 EXIT EXIT cause BDL to exit.

CHAPTER 6 LARGE POWER SUPPLY CONTROLLER

6.1 HARDWARE DESCRIPTION The Large Power Supply Controller is a single width CAMAC module capable of controlling and monitoring a single large power supply. It contains a 14 bit DAC which supplies the set point of the power supply and a 14 bit ADC which reads the current through a shunt monitoring the current output of the supply. In addition, it has several special features including a programmable ramping rate (.532 to 136.3 sec), ripple monitoring, self-test capability, and several protection features. For more information, refer to The large power supply controller is used to control a series string of magnets. There are two possible configurations:

6.1.1 Individually Shunted Magnets The shunted magnets have individual bypass shunts which can be controlled by one channel of a TRANSIAC 3016 16 bit DAC to shunt ______________________________ For more information, refer to: Specification of Power Supply Controller-Monitor Module by D. Horelick and H. Kang.

LARGE POWER SUPPLY CONTROLLER Page 6-2 current between 0 and 15 amps. The bypass current is monitored by a channel of a Smart Analog Monitor(SAM - #123-603). The current through a shunted magnet is equal to the current output by the power supply minus the current through the shunt as set by the DAC and measured by the SAM. Schematically, ------/------------- SHUNTED MAGNETS | | | | | | ____ | | | | |\ | | |LGPS|--/--| >---^^^^---------^^^^----...-------^^^^---- |____| |/ | | | | | | ---| | ---| | | | | s | | s | | | | s | | s | | | | -| | | -| | | | | ||--^^^-| | ||--^^^-| | | | | | | | | | | | | | | | | | | | | | | SAM DAC SAM DAC | | | | | | | | | |__________________________________________|

6.1.2 Series Magnets The series string magnets have no shunts and no individual readback or control. The current through each magnet is equal to the current output by the power supply.

LARGE POWER SUPPLY CONTROLLER Page 6-3 Schematically, ------/------------- SERIES MAGNETS | | | | | | ____ | | | | |\ | | |LGPS|--/--| >---^^^^-------^^^^----...-----^^^^---- |____| |/ | | | | | |______________________________________|

6.2 DATABASE STRUCTURE

6.2.1 Large Power Supply Controller The large power supply controller is entered in the database as a new primary LGPS (hereafter referred to as LGPS). It includes the same set of secondary names as a standard magnet, eg. QUAD, and can be calibrated, standardized, checked, and trimmed with the standard magnet control commands. In addition, three new secondaries are required: :RAMP: 32,1,1I2; !ramping rate code (0-7) :MAGS: 33,1,VI2; !list of magnets on this power supply 2 words each, eg. %QUAD,21 where %QUAD is the category number of QUAD and is defined as a symbol in DEFAULTS.DBS and 21 is the unit number :IDES: 34,3,1R4; !desired current calculated by the micro If the LGPS controls individually shunted magnets (see a above), it has the Hsta_shunted bit ON in HSTA. It has, properly speaking, no magnetic field associated with it, so it is set in terms of the current required by its shunted magnets. It has, for convenience, the same secondary names as a standard magnet, but all secondaries

LARGE POWER SUPPLY CONTROLLER Page 6-4 referring to field really refer to current, ie. BACT is really IACT, etc. Its I vs B polynomial, IVBU, is 0,1. Its set point, IDES, is calculated by the micro and BDES is meaningless. If the LGPS controls series magnets without individual shunts, (see b above) it has an I vs B polynomial which is typical of the polynomials of the individual magnets. Its set point, BDES, is specified by the SCP, and IDES is meaningless.

6.2.2 Individually Shunted Magnets Controlled By An LGPS These magnets have individual shunts with independent readback and control. They are entered in the database under the appropriate primary, eg. QUAD, with the standard set of magnet secondary names. In addition, one new secondary is required: :PSCP: 31,1,1I2: !unit number of the LGPS These magnets have the Hsta_shunted bit ON in HSTA to indicate that they are shunted magnets. They can be controlled with the standard magnet control commands, with the following considerations:

6.2.2.1 Calibration: - During calibration of shunted magnets, the LGPS must be set to the maximum operating current of the magnet string. If the LGPS is to be calibrated as well, it is done separately before calibrating the shunts. The max and min calibration current limits for the magnets

LARGE POWER SUPPLY CONTROLLER Page 6-5 represent max and min shunt currents.

6.2.2.2 Standardization: - The shunted magnets cannot be individually standardized; all magnets on an LGPS are standardized at once. During standardization, all shunts must be set to min to run full current through the magnets.

6.2.2.3 Check And Trim: - The current readback measures the shunt current so the actual current in the magnet is equal to the current in the LGPS minus the current read.

6.2.3 Series Magnets Without Individual Control These magnets have no readback or control and no individual shunts. They are entered in the database as new primaries, eg. BEND,QF,QD,SEPT. As they cannot respond to any of the standard control functions, they require only a limited number of secondaries: :Z : 23,4,1R4; !Z position of the magnet :PSCP: 31,1,1I2; !Unit number of the LGPS controller :LABL: 36,4,2A4; !Serial number or other label for the magnet :IVBU: 2,4,VR4; !I=F(B) going up :IVBD: 3,4,VR4; !I=F(B) going down :BACT: 15,4,1R4; !B at last check The I vs B polynomials are for reference only. The actual polynomial used to set the magnets is a composite and is in the LGPS definition.

LARGE POWER SUPPLY CONTROLLER Page 6-6

6.3 CAMAC COMMANDS

6.3.1 Addresses And Function Codes All Camac functions to the LGPS use the basic CTLW found in the secondary DACL, which contains the crate and module address bits. The branch is simply the micro name, e.g. 'LI01'. The appropriate function and subaddress codes for individual read, write, or test functions are parameters in the include file LGPSCNTL.

6.3.2 Analog Output In The Micros: All analog output to the magnets or LGPSes uses the function DACSET(DACL,DAC,MASK,STAT,PTRBFLAG) where DACL is the CTLW for the DAC DAC is the desired DAC setting MASK is a mask of bits used by this DAC STAT is the returned magnet status PTRBFLAG is a flag indicating if the value of DAC is absolute or incremental DACSET is identical for all magnets or LGPSes.

6.3.3 Analog Input In The Micros: All analog input from the magnets uses the function READADC(READTYPE,WAITFLAG) where READTYPE is a parameter defined in SHNTCNTL = Set_Lgps for LGPS read = Set_Shnt for normal magnet read = Set_All for both LGPS and other magnets WAITFLAG is a flag to indicate if a Sleep is required before reading the ADC

LARGE POWER SUPPLY CONTROLLER Page 6-7 If requested, magnets are read first; shunted magnets need no special consideration. When an LGPS is being read, READADC first loops checking ramping status, and then reads the LGPS ADC's only when ramping is completed. On initialization, READADC assigns its own internal ADC pointer, ADCP, for each LGPS. The database value of ADCP for an LGPS is 0.

6.4 ON/OFF/REVERSE CONTROL

6.4.1 Control Structure A large power supply is turned on or off or reversed ONLY by a SCP and ONLY in response to a touch panel command input. The control is handled by subroutine LGPSCNTL which is called from MAGDRVR. The power supply sector and unit number and the control function to be performed are selected on the appropriate sector magnet control panel, and transmitted to LGPSCNTL in the common block MAGUNITS found in the include file MAGUNITS.

6.4.2 Error Checking: All write functions are followed by a readback and the data is checked for validity. X and Q are expected for valid functions. On any write, read, or check error, a message is printed indicating where the error was detected, the Hsta_sick bit is turned on in the LGPS HSTA word, and the procedure is terminated.

LARGE POWER SUPPLY CONTROLLER Page 6-8 If the Enable bit is ON when the error occurs, an attempt is made to turn it OFF before termination.

6.4.3 Camac Functions: All Camac is handled by the function LGPSCAM with entry points o LGPS_CAMINIT(BRCH,CTLW) where BRCH = Camac branch CTLW = CAMAC control word for the LGPS This sets up the Camio package to be used by the other functions. o LGPS_CAMCHK(FUNCTION,SUBADR,DATA,MASK,ERRMSG) where FUNCTION = Camac read function code SUBADR = Subaddress for this function DATA = Data to be written out MASK = Mask of bits to be checked on readback ERRMSG = Character string to label error messages This writes data, reads back, and checks that the data read back equals data sent. (Note: This function explicitly uses the hardware design feature that a Write operation is performed by the Read function code + 16.) o LGPS_CAMOUT(COMMAND,MODE,ERRMSG) where COMMAND = Mask of bits to be written to the Digital output register MODE = String 'ON' or 'OFF' specifying action taken ERRMSG = Character string to label error messages This reads the contents of the digital output register, turns ON or OFF the new command bits, and writes it out.

LARGE POWER SUPPLY CONTROLLER Page 6-9 o LGPS_CAMSTAT(STATMASK,VALUE,TIMEOUT) where STATMASK = Mask of bits to be tested VALUE = Desired value of tested bits TIMEOUT = maximum number of milliseconds to wait This reads the contents of the digital output/status register and compares the contents of the bits masked by STATMASK with the value specified in VALUE. If the status read is not correct, CAMSTAT loops up to TIMEOUT milliseconds testing for good status. A decoded error message is printed for each incorrect bit. o LGPS_CAMTST This loops through the 14 bits of the DAC and ADC, writing to the DAC, reading back the ADC, and checking readback against preset tolerances. The test uses first a walking bit and then a walking zero pattern. At each step, the DAC readback is also checked against the data written. (After setting the DAC, there is a 230 msec wait necessary before reading the ADC.) o LGPS_RAMPTST(RAMP) where RAMP = Ramping code (0-7) This loops testing ramping status up to a maximum ramping time specified by the ramping code.

6.4.4 LGPSCNTL Procedure:

LARGE POWER SUPPLY CONTROLLER Page 6-10 1. Get database information HSTA,DACL,RAMP for this unit and turn off old status summary bits in HSTA 2. Set up Camio package with LGPS_CAMINIT 3. Check Local/Remote status bit with LGPS_CAMSTAT If not Remote, print error message and continue 4. Set DAC to 0 and check with LGPS_CAMCHK 5. Test ramping status and wait for Q=1 with LGPS_RAMPTST 6. If function requested is On, o Set ramp rate register to RAMP and check with LGPS_CAMCHK o Select Self-test for ADC input and check with LGPS_CAMCHK o Write 0 to ramp register and check with LGPS_CAMCHK o Cycle through test with LGPS_CAMTST o Write RAMP to ramp rate register with LGPS_CAMCHK o Select Analog_in for ADC input and check with LGPS_CAMCHK o Check Interlock bits with LGPS_CAMSTAT o Turn on Enable with LGPS_CAMOUT o If supply is reversible, turn ON or OFF Polarity bit and check latched polarity and polarity status bit (ON=normal,OFF=reverse) o Check Enable and System ready with LGPS_CAMSTAT o Turn on DC ON bit with LGPS_CAMOUT o Check DC ON, and all other ON bits with LGPS_CAMSTAT 7. If function requested is OFF, o Turn OFF Enable with LGPS_CAMOUT o Check DC ON, Enable bits are OFF, Interlocks still ON with LGPS_CAMSTAT 8. If function requested is Reverse, o Check Hsta_reversible bit is ON o Turn OFF Enable with LGPS_CAMOUT

LARGE POWER SUPPLY CONTROLLER Page 6-11 o Check DC ON, Enable bits are OFF, Interlocks still ON with LGPS_CAMSTAT o Turn ON or OFF Polarity bit (ON=normal,OFF=reverse) o Check latched polarity and status bit with LGPS_CAMSTAT o Turn on Enable with LGPS_CAMOUT o Check Enable and System ready with LGPS_CAMSTAT o Turn on DC ON bit with LGPS_CAMOUT o Check DC ON, and all other ON bits with LGPS_CAMSTAT 9. Set appropriate bits in HSTA and update database Stat_good = LGPS turned on Stat_ok = LGPS reversed Stat_dead = LGPS turned off Stat_sick = LGPSCNTL failure

6.4.5 BULKCNTL Procedure Bulk supplies feeding several LGPS controllers are treated as a single unit for the purposes of ON/OFF control by the panels. When a bulk supply is to be controlled, the routine BULKCNTL is called by MAGDRVR, with a unit number set to the unit identifier of the Bulk supply. At the present time there is only one bulk supply in the system, so the unit number is not being used. The BULKCNTL routine loops over the LGPS units on the bulk supply, turning them ON or OFF in a predetermined order. If an error occurs while turning ON any of the units, an attempt is made to turn OFF all units, thus leaving their DAC's at 0 and the Enable OFF.

LARGE POWER SUPPLY CONTROLLER Page 6-12 Error messages generated indicate which LGPS produced the fault and the error condition, as with LGPSCNTL.

6.4.6 DEGAUSS Subroutine Magnets in critical beam line positions where the residual magnetic field must be minimized after use have been equiped with reversible LGPS controllers so they can be degaussed. To DEGAUSS a magnet, three additional secondaries must be defined: :GSCY: 42,4,2I2; !Number of Degauss cycles, Nwait(msec) for switch :GLIM: 43,4,2R4; !IPOS, INEG currents for Degauss cycle :GTIM: 44,4,2I4; !Last time successfully Degaussed Only a single LGPS can be degaussed at a time. It must have the HSTA_Reversible bit on in HSTA and have non-zero values for GSCY and GLIM. If the magnet has not been calibrated, DVI will be used to calculate the set points. Otherwise, DVIC will be used. Degauss procedure: 1. Check that magnet is ON and correct polarity 2. If not, set correct polarity and turn ON 3. Loop over GSCY(1) cycles, once for each polarity o Calculate DAC setting for Degauss current GLIM(1) or GLIM(2) o Set DAC and check o Wait for ramping o Sleep GSCY(2) milliseconds o Read back ADC, convert to current and check against ATOL o Print error or success message

LARGE POWER SUPPLY CONTROLLER Page 6-13 o Set opposite polarity 4. If successful, print message and put time stamp GTIM in database 5. On any error except tolerances, quit immediately with an error message 6. On a tolerance error, continue but print Failed message 7. In all cases, turn off supply before returning

6.5 MAGNET CONTROL IN THE MICROS

6.5.1 Initialization On IPL, the micro constructs database lists for all LGPSes and magnets. The LGPS lists MUST precede the magnet lists. Series magnets without shunts are not considered by the micro. For each LGPS with shunted magnets, the micro gets the list of magnets on this LGPS from MAGS and constructs a list of pointers to its magnets, where the pointer is the index of each magnet in the database lists. The LGPS pointer, PSCP, of each shunted magnet is also converted to an index pointer. READADC constructs its own internal ADC pointers for each LGPS.

6.5.2 Magnet Control All magnet control in the micro is handled by MAGCNTL.

LARGE POWER SUPPLY CONTROLLER Page 6-14 All special setting of the LGPS or shunted magnets required for calibration or standardization is handled by the function SHUNTSET(TYPE,MODE) where TYPE = parameter to select LGPS or shunts MODE = parameter to select min, max, or previous current The parameters for TYPE and MODE, as well as the call arguments for the individual control routines are found in the include file SHNTCNTL. MAGCNTL procedure: 1. Update all type 2 database lists, ie. HSTA,BACT,CMND 2. Select desired control function according to bits set in GCMD, the cluster global command word. 3. If calibrate, call CALIBALL(SET_LGPS) to calibrate LGPSes call CALIBALL(SET_SHNT) to calibrate magnets 4. If standardize, call STDZALL(SET_ALL) to do all magnets at once 5. If check or trim, call LGPSCHK to get setpoints for shunted LGPSes call MAGTRCK(SET_LGPS) to check and trim LGPSes call MAGTRCK(SET_SHNT) to check and trim magnets 6. Refresh and send back to VAX database all new type 3 data.

6.5.3 Calibration Calibration of the large power supply DAC vs current is done by the individual sector micros using the same algorithm as used for standard magnets.

LARGE POWER SUPPLY CONTROLLER Page 6-15 The series magnets without shunts need no individual calibration. The shunted magnets are calibrated individually using the standard calibration procedure, where the max and min current limits now represent max and min shunt currents. Calibration procedure: 1. Calibrate the LGPS first, if requested. 2. Set the LGPS to IMMO(2) which is the max operating current if any of its individual shunts need calibration, by calling SHUNTSET(SET_LGPS,SET_MAX) 3. Calibrate all magnets including shunted magnets 4. Set the LGPS back to the current INOW that it had before step 2 by a call to SHUNTSET(SET_LGPS,SET_SAV) This guarantees that a request to calibrate an individual shunt will restore the LGPS and its other shunts to their previous status after the calibration is finished.

6.5.4 Standardization Standardization of magnets powered by a large supply is done for all magnets on a supply at the same time. For shunted magnets, it is necessary to set all shunt currents to min before starting standardization. Standardization procedure: 1. If necessary, set all shunt currents to min for all magnets listed in the MAGS list of an LGPS by a call to SHUNTSET(SET_SHNT,SET_MIN)

LARGE POWER SUPPLY CONTROLLER Page 6-16 2. Standardize all magnets and LGPSes 3. Shunts are left at min and set going down.

6.5.5 Check And Trim An LGPS controlling shunted magnets is trimmed to a desired current, IDES, which is calculated by LGPSCHK from the currents required by the individual shunted magnets requesting trim. An LGPS controlling series magnets without shunts is trimmed like any standard magnet. Shunted magnets are checked against their set point using the standard procedure, except that current in the magnet equals current in the LGPS minus measured current in the shunt. Shunted magnets require no special handling for trim. Check and Trim procedure: 1. Calculate the set_points for all shunted LGPS with LGPSCHK 2. Check and trim the LGPS 3. Check and trim all magnets

6.5.6 LGPSCHK LGPSCHK is an integer function which calculates the setpoints, IDES, for the large power supplies which control a set of shunted magnets.

LARGE POWER SUPPLY CONTROLLER Page 6-17 LGPSCHK procedure for each shunted LGPS: 1. Loop over the magnets on that LGPS with the Trim bit on o Calculate the desired current from BDES o Find the maximum current required, CMAX o Find the minimum current required, CMIN 2. If any of the magnets have the Check and/or Trim bit set, then the LGPS will also be checked and/or trimmed. 3. If any of the magnets have the Trim bit on, calculate a new setpoint for the LGPS as follows o CMAX must be less than the maximum operating current of the LGPS o CMAX - CMIN must be less than the maximum shunt current available, SMAX, if both max and min are to be satisfied at the same time o The setpoint is chosen to be 5% above CMAX, but not greater than the maximum operating current of the LGPS o If CMAX - CMIN is too close to SMAX, then the setpoint is chosen to be (CMAX + CMIN + SMAX)/2 to optimize between the max and min requirements

CHAPTER 7 STEPPING MOTOR CONTROL

7.1 HARDWARE DESCRIPTION Individual stepping motors for the SLC are controlled by the Joerger Enterprises Stepping Motor Controller and Driver Model SMC-24. This is a single width CAMAC module with a 24 bit 2's complement count register to specify the number of steps to be moved, a 16 bit control register to select speeds and an 8 bit status register. External logic signals inhibit the driver if a limit is reached. All modules should contain the Programmable Speed option to guarantee interchangeability and correct setting of the speed after maintenance or replacement. Where 24 bit range is not required, the 16 bit Model SMC-LP modules already in use may be controlled by the same software. For more information, refer to the Joerger Enterprises specification. Where control of many motors is required, as in the collider arcs, the 16 channel SLAC module xxx is used. This is a single width CAMAC module with a 16 bit 2's complement count register for each channel. There is no speed control and no external limit switches are implemented. The function F27 Ax is used to determine the status of a specific channel, x.

STEPPING MOTOR CONTROL Page 7-2 It is the responsibility of the system engineer to mechanically design the motor such that the gear ratio and screw pitch provide the required displacement resolution and to choose the stepping motor with adequate torque for the application. The limit switches protect the hardware in that whenever they are reached the motor cannot be stepped further in that direction. The device position is read back by means of a linear or rotary motion transducer (potentiometer). The requirements on the stability of the potentiometer polarizing supply and on the temperature are relaxed by the fact that both the cursor voltage and the total voltage are read and their ratio computed to determine the actual cursor position. The voltages are read on two channels of a Smart Analog Monitor (SAM) where the pointer to the Cursor channel is found in the database secondary, ADCP, and the pointer to the Total or reference channel is in ADCR.

7.2 DATABASE STRUCTURE The stepping motor controller is entered in the database as a new primary STEP (hereafter referred to as STEP). It includes the same set of secondary names as a standard magnet-like device, e.g. PHAS, and has all the standard magnet control functions except standardization. In addition, three new secondaries are required: :ADCR: 32,1,1Z2; !Pointer to ADC location in buffer ! of reference channel :SPED: 33,1,1Z2; !Speed and acceleration time (Hex) !Low byte selects speed (0 = minimum) !High byte selects acceleration/deceleration

STEPPING MOTOR CONTROL Page 7-3 ! time (0 = longest time) :CSTA: 39,3,1Z2; !Status register readout The following discussions assume that all magnet secondary names that refer to B for field and I for current will be changed for all magnet-like devices to V for value and A for ADC reading respectively. This includes the following list: :BCON: -> :VCON: !Value from configuration :BMAX: -> :VMAX: !Maximum value allowed :BDES: -> :VDES: !Value desired :BACT: -> :VACT: !Value at last check :IVBU: -> :AVSV: !ADC volts = Function(Value) :IEXP: -> :ADES: !ADC volts calulated from VDES :INOW: -> :AACT: !ADC volts at last check :IPRV: -> :APRV: !Last recorded ADC volts in tolerance :IMMO: -> :AMMO: !Min, Max ADC volts for operating conditions :IMMS: -> :AMMS: !Min, Max, Set point for Calibrate :DVI : -> :DVA : !DAC counts = Function(ADC volts) trial polynomial :DVIC: -> :DVAC: !DAC counts = Function(ADC volts) calibrated For stepping motors, the secondaries referring to ADC volts always refer to the transducer cursor position, ie. the ratio of the two ADC channels used to read the cursor and total voltages.

7.3 CONTROL FUNCTIONS IN THE MICRO

7.3.1 Calibration The calibration function calculates a linear polynomial for Counts (Steps) versus potentiometer position, DVAC. It checks out the motor and its database entries using the standard magnet procedure. First the device is moved to the maximum excursion specified in the database, AMMS(2), using the test polynomial DVA to determine the number of steps required to go from the current position AACT. When

STEPPING MOTOR CONTROL Page 7-4 motion stops, AACT at MAX is calculated. Then the device is moved to the minimum excursion AMMS(1) and AACT at MIN is calculated. The calibrated polynomial DVAC can be derived from the number of steps taken and the measured AACT values and compared with the test DVA using the tolerances ATOL. The device is then moved to the set point AMMS(3).

7.3.2 Check And Trim The check function compares the current value of the device VACT with the desired value VDES using the tolerances specified in TOLS and reports status. If the device is out of tolerance and a trim is requested, then the DVAC polynomial is used to calculate the appropriate number of steps to go from AACT to ADES and the device is moved. When motion stops, the new position is read and checked against the tolerances. The procedure can be iterated if necessary.

7.3.3 Perturb The perturb function is an open loop setting procedure used for knob applications. The previous value of VDES is subtracted from the new value of VDES and the difference used to calculate the needed number of steps to move the device. No attempt is made to wait for the device to actually complete the motion and no check is performed.

7.3.4 Home The home function is the stepping motor equivalent of the Dac Zero

STEPPING MOTOR CONTROL Page 7-5 function for magnets. The current value of the position AACT is read and the DVAC polynomial used to calculate the number of steps needed to move the device to its database set point AMMS(3).

7.3.5 Reset The reset function is used to initialize devices after a crate is powered on. For stepping motors it must write SPED, the speed and acceleration time, to the controller if speed is programmable. In addition, the appropriate SAM's are reset to IEEE mode as for magnets, and all previously trimmed devices are re-trimmed.

7.4 CONTROL AND DISPLAY FUNCTIONS IN THE VAX

7.4.1 Control Functions The VAX magnet control routine sends standard Calibrate, Check, Trim and Zero(=Home) commands for a stepping motor to the micro. It also allows entering of values for VDES and VCON. Necessary revisions are minor.

7.4.2 Adjust Knobs The magnet adjust knob handling routine uses the perturb function to allow the VDES of a stepping motor to be changed with a knob. Only minor revisions are required to handle the alternate secondary names.

STEPPING MOTOR CONTROL Page 7-6

7.4.3 Checkout Knobs The magnet checkout knob routine when used for stepping motors reads the two SAM channels assigned to the STEP and uses the DVA or DVAC polynomial to calculate the current 'absolute' DAC setting. This is used as the starting point for the knob. Knob turns are treated as increments and written directly to the STEP's DAC register. The display is an expansion of the normal magnet checkout display and includes the DAC increment, equivalent 'absolute' DAC setting, status register, both SAM channels and ripple measured on each, calculated cursor position and status. Messages are generated as usual when limits or errors are detected.

7.4.4 Displays The magnet display routines also display stepping motors in all the standard magnet display formats, where the appropriate secondaries VCON, VDES, and VACT are substituted for the magnet B field values. An additional field on the All unit display is used to specify appropriate units for the values.

7.5 SOFTWARE DETAILS IN THE MICRO Since all Camac reading and writing for magnet control use two routines, DACSET and READADC, most of the important modifications to the micro software are in these routines.

STEPPING MOTOR CONTROL Page 7-7

7.5.1 DACSET(Unit,Dac_value,Ptrbflag) The DACSET routine must calculate the value to be written to the DAC differently for STEPs. For normal magnets, if they are not being perturbed, Dac_value is masked, checked for limits and written to the DAC. If perturbed, the current DAC setting is read and the argument Dac_value is treated as an increment. For STEPs this logic is reversed as all values written are increments and not absolute. If a STEP is perturbed, Dac_value can be written directly to the DAC (after appropriate checks). If a STEP is not perturbed, an absolute DAC value corresponding to the current AACT is calculated and subtracted from Dac_value to give the incremental value to be written to the DAC. There are three other important differences in setting stepping motors: 1. The software must require that the count register is at zero and that the motor has stopped moving before writing a new value to the controller. This is a problem only on Perturb functions where the software does not wait for motion to complete before accepting a new command. This certainly affects the response time of stepping motor knobs. 2. To support 24 bit controllers, the value written must be 4 bytes and the CAMAC operation must use Pack 24. 3. As soon as the value is written to the count register, the stepping motor begins to move and to decrement the count register. This implies that the DAC readback check normally performed is meaningless and must be bypassed for STEPs.

STEPPING MOTOR CONTROL Page 7-8 These differences should be transparent to the control routines, except for the additional delay on Perturb functions.

7.5.2 READADC(Type,Waitflag) The READADC routine treats SAM's and PSC's separately. The SAM channels used by STEPs are read at the same time as the other SAM channels and are treated similarly. However, if STEPs are present and READADC is called with Waitflag set so that it waits for data to be valid before reading, then it must read the STEP status registers and wait for motion to finish before reading the SAM's. In addition, after the SAM's are read it must loop over the STEPs and calculate the cursor position by dividing the first STEP channel by the second. These differences are transparent to the control routines.

7.5.3 SAMRESET() This routine must write the SPED value to the STEP as well as sending the reset commands to the SAMs. In order to provide support for modules not equipped with the programmable speed option, the software must not require correct X and Q response if the value of SPED is zero.

7.5.4 DACZERO() This routine must set the STEP to the database set point value AMMS(3) instead of to 0.0 for PSCs or to 32768.0 for the offset binary Transiac channels.

STEPPING MOTOR CONTROL Page 7-9

7.5.5 CALIBALL(Type) This routine must call READADC to calculate current STEP values before calibrating STEPs.

CHAPTER 8 SOFTWARE TO CONTROL GENERALIZED ANALOG KNOBS The SLC system will need a facility to control a number of different analog devices using a Transiac DAC channel to output a voltage and a SAM channel to monitor the setting. In general, these devices look like magnets with the following exceptions: o They do not need to be calibrated, and should not be. o They are not standardized. o When trimmed, the DAC should be set but no attempt should be made to improve the setting by iteration. Since the necessary functions are properly a subset of the magnet control functions, it will be possible to use the existing magnet control software to control these analog channels with only minor modifications.

8.1 PRESENT SOFTWARE In the present magnet control software, there are five possible control functions:

SOFTWARE TO CONTROL GENERALIZED ANALOG KNOBS Page 8-2 o CALIBRATE The Calibrate function sets the DAC to specified high and low values and recalculates a linear fit to the DAC vs I transfer function. o CHECK The Check function reads the appropriate SAM channel and calculates the present value of current and B field, BACT. It then compares BACT with the desired field, BDES, and sets status bits to indicate if the reading is within tolerance. o PERTURB The Perturb function sets a new value of BDES by extrapolating from the present DAC setting. There is no readback or checking. o TRIM The Trim function takes the desired field, BDES, calculates the appropriate DAC setting, and sets the DAC. It then reads back the field, BACT, compares it with BDES, and iterates up to 10 times with new DAC settings to get BDES within tolerance of BACT. o STANDARDIZE The Standardize function cycles the magnet from full high to full low current a specified number of times, NSCY, to reproduce the cycle used by the magnetic measurements group to give the magnet amnesia. If NSCY is 0, a magnet is not

SOFTWARE TO CONTROL GENERALIZED ANALOG KNOBS Page 8-3 standardized. The present software requires a magnet to be calibrated before it can be Perturbed, Trimmed, or Standardized as all three functions use the DAC vs I transfer function from the calibration to calculate desired DAC settings. The present software has reserved two hardware status, HSTA, bits to indicate that a magnet is not capable of full control. These bits are: o HSTA_NOCTRL to indicate that the magnet can be read but not controlled. If this bit is set, all functions except Check are disabled. o HSTA_NOTRIM to indicate that the magnet can be controlled but not trimmed independently. This has been used in cases where multiple magnets share a common DAC and ADC channel. If this bit is set, the Trim function is disabled.

8.2 PROPOSED MODIFICATIONS The new devices may be controlled using the existing routines in the Micros and the existing control routines in the VAX. They can use the existing magnet displays, but they will not be included when the ALL magnet button is selected.

SOFTWARE TO CONTROL GENERALIZED ANALOG KNOBS Page 8-4 It is suggested that the 2 HSTA bits currently in use be expanded to 4 disable bits, one for each actual control function. o HSTA_NOCALB to indicate that calibrate is disabled for this device o HSTA_NOPTRB to indicate that perturb is disabled for this device o HSTA_NOTRIM to indicate that trim is disabled for this device o HSTA_NOSTDZ to indicate that standardize is disabled for this device In addition, one extra bit is needed to indicate that the device can be trimmed, but that no attempt should be made to iterate to improve the setting. o HSTA_NORETRY to indicate no iterations on trim The standard bit configurations would then be as follows: o NO BITS SET for normal magnets with full control available. o HSTA_NOCALB+HSTA_NOPTRB+HSTA_NOTRIM+HSTA_NOSTDZ for extra magnets sharing a single DAC and ADC channel. o HSTA_NOCALB for malfunctioning magnets which will not calibrate but are still needed by the system in a limited capacity.

SOFTWARE TO CONTROL GENERALIZED ANALOG KNOBS Page 8-5 o HSTA_NOCALB+HSTA_NOSTDZ+HSTA_NORETRY for the new analog devices. It is also necessary, to allow devices with the HSTA_NOCALB bit on to be perturbed, trimmed or standardized using the test DAC vs I transfer function instead of the calibrated transfer function.

8.3 PROBLEMS AND COMMENTS Problem: These devices will be grouped under a new database Primary name or names, e.g. :PHAS:. As the present set of primary definitions have used all the available primary definition space, the database will need to be modified before these devices can be defined. Problem: After the addition of the 5 bits described above, there remain only 2 unassigned bits in the Hardware status word. This is not much growing room. Comment: For present applications, the HSTA_NOSTDZ bit is unnecessary as magnets which should not be standardized have the number of cycles, NSCY, set to 0. In addition, HSTA_NOTRIM and HSTA_NOPTRB are probably redundant and could be combined. This may be necessary if more status bits are needed. Comment: Since the HSTA word is in the database supertype 2, and hence modifiable by the VAX, software could be written to turn these bits ON and OFF dynamically. This may be more dangerous than useful.

SOFTWARE TO CONTROL GENERALIZED ANALOG KNOBS Page 8-6 Problem: Since the new devices will be controlled by the same routines in the micros as the magnets, there is a possible problem arising from the fact that all devices with the Trim command bit set will be Trimmed whenever the magnets in that sector are Trimmed. Other functions will not be used, except check and perturb, and will not be likely to cause problems. Comment: Care will have to be taken to define tight Trim tolerances and loose Check tolerances for the new devices so that they will be trimmed whenever their BDES is changed but they will not fail Check due to the inaccuracy of the readback.

CHAPTER 9 DIGITAL STATUS CONTROL SYSTEM

9.1 INTRODUCTION This document describes a software system for handling simple on/off devices which operate through the SLC digital input and output CAMAC modules: SLC Hardware Manual: Pulsed Power Output Module (PPOM) Isolated Digital Output Module (IDOM) Isolated Digital Input Module (IDIM) The digital output system, as described here, incorporates both digital input modules and digital output modules. However, for devices which use only digital input modules, a simpler (but similar) scheme is used, as will be described in the chapter Digital Input System. The goal of the system is to provide o Complete software to allow one to add simple on/off type devices to the system by additions to the data base, without the need for software tailored to the specific device.

DIGITAL STATUS CONTROL SYSTEM Page 9-2 o User hooks in the software to allow the user the ability to add tailored software for exceptional devices or conditions. (NOT YET IMPLEMENTED) o Canned routines which can be called from tailored software to operate the devices. (NOT YET IMPLEMENTED) Operation of the devices is done through the micro-clusters, while control of the operation remains in the VAX. Communication between the VAX and micros will be done primarily through through the SLCNET message facility and secondarily through the database.

9.1.1 Digital Output Devices The collection of all digital output signals and their associated digital input signals are logically divided into generic DIGITAL OUTPUT DEVICES (DODs). A given DOD may have up to 8 output bits, and 16 input bits. All output bits must be contained in a single output module. Input bits may be contained in more than one input module.

9.1.2 States The state of a DOD is described by a STATE VECTOR. Subject to restrictions on the total number of input and output bits, each vector may have an arbitrary number of COMPONENTS, each of which may take an arbitrary number of VALUES. A component of the state vector is independent of all other components; i.e. the value of one component does not affect or restrict the value of any other component. In practice this will mean that different components cannot share input

DIGITAL STATUS CONTROL SYSTEM Page 9-3 or output bits. The set of values of a given component is that set of legal values which can be taken by the input and output bits of the component. Examples: A device with N independent bits, each of which may be on or off, has N components, each of which has 2 possible values (on/off). An auto-radio-push-button type device with N buttons has one component with N possible values. In the absence of tailored software it must be possible to correlate the OUTPUT STATE of the device, as defined by the state of the output lines which the computer thinks it last requested, with the INPUT STATE, as defined by the input lines to digital input modules and the readback of the digital output modules. This will be accomplished by providing masks for each value of each component of the output state vector such that each input and each output bit of the DOD is specified as must-be-on, must-be-off, or dont-care. Since the input state matches the output state only in the mind of the computer, we define the following terms: o INCONSISTENT STATES occur if the input state does not match ANY possible output state. o UNREQUESTED STATES occur if the input state matches a possible output state which is different from the current output state. o ABNORMAL STATES occur if the input state matches the current output state, but is categorized as abnormal by the current Mode (see below).

DIGITAL STATUS CONTROL SYSTEM Page 9-4 o NORMAL STATES occur if the input state matches the current output state and is categorized as normal by the current Mode.

9.1.3 Modes In operation, one expects to keep a DOD in a normal state. However, if the device were always kept in this state, there would be no need to control (rather than simply monitor) its state from software. Hence one would like a means of dynamically redefining which states are normal and which are abnormal. This is determined by the DOD MODE, which defines a severity level associated with each value of each component. By changing the mode, one can then change the severity level to be associated with possible input states.

9.1.4 Example Consider a hypothetical device named GATE which has a single IDOM line DOM_GATE (which can be read back through the output module), and two IDIM lines SW_OPEN and SW_CLOSD. GATE has one component, GSTATE, with two possible values, OPEN or CLOSED; output bit DOM_GATE has two values, OPEN and CLOSED; input bit SW_OPEN has possible values OPEN or NOT_OPEN; and SW_CLOSD has possible values CLOSED and NO_CLOSD. There are two possible consistent states: Input State = (DOM_GATE, SW_OPEN,SW_CLOSD) _____ _____ ________ ________ ________ OPEN = ( OPEN, OPEN,NO_CLOSD) CLOSED = ( CLOSED,NOT_OPEN, CLOSED)

DIGITAL STATUS CONTROL SYSTEM Page 9-5 All other input states are classed as inconsistent states. The device has three possible modes: OFFLINE: All states (including inconsistent states) are given severity levels which do not issue error messages. ACCESS: The OPEN state is normal, the CLOSED state is abnormal. NOACCESS: The CLOSED state is normal, the OPEN state is abnormal.

9.2 DATA BASE STRUCTURE The digital output system uses five primary data types: o DODD = Digital Output Device Definition. This data type defines a logical device structure, which may be common to many (physically different) device types. o DODN = Digital Output Device Names. This data type contains information (primarily names) which needs to be accesed only by the VAX (not micros). This information is independent of the micro or unit of devices to which it applies and is therefore stored only in micro-cluster VX00. o = Digital Output Device, where is any four-character name defining the DOD. (Note that a DOD is a logical rather than physical device.) While different DOD types have different primary data types, the structure of this primary is identical for all DODs. This data type contains information unique to a single unit

DIGITAL STATUS CONTROL SYSTEM Page 9-6 of a DOD type. o DOM = Digital Output Module. This data type defines the physical digital output modules, independent of which DODs it controls. o DIM = Digital Input Module. This data type defines the physical digital input modules, independent of the nature of the data they read.

9.2.1 DODD - Digital Output Device Definition Secondary Supertype Conversion Usage _________ _________ __________ _____ NOB 1 1I2 # output bits NIB 1 1I2 # input bits NM 1 1I2 # modes ESCR 1 1A8 (VS4) User escape routine PLSE 1 1I2 Pulse or level spec NSC 1 1I2 # state components NSV 1 NSC*I2 # values of each compon NS 1 1I2 Total # state values OBSD 1 NS*Z2 Output Bit State Def. IBSD 1 NS*Z4 Input Bit State Defin. SEV 1 (NS+1,NM)*Z2 Severity Level x Log DODU 1 VI2 Device primaries and units

9.2.1.1 NOB = # Output Bits. - NOB specifies the number of output bits associated with DOD. RESTRICTION: NOB .LE. 8

DIGITAL STATUS CONTROL SYSTEM Page 9-7

9.2.1.2 NIB = # Input Bits. - NIB specifies the number of input bits associated with DOD. RESTRICTION: NIB .LE. 16

9.2.1.3 NM = # Modes. - NM specifies the number of modes of the DOD. RESTRICTION: NM .LE. 8

9.2.1.4 ESCR = User Escape Routine - ESCR is an 8 character name which specifies the name of a user routine to be called to handle tailored applications. If this parameter is left unspecified, no user routine will be called. If specified, the name must be associated with a subroutine using the SLC logical name services. The routine will be called at various points in the processing of any unit of this device. Specification of which points at which the routine will be called, calling arguments, and return codes have yet to be determined.

9.2.1.5 PLSE = Pulse Or Level Specification. - PLSE specifies whether the device operates in pulsed or level mode: o 0 = non-pulsed (level) IDOM

DIGITAL STATUS CONTROL SYSTEM Page 9-8 o Non-0 if PPOM: Fixed pulse width = 250 msec. If bit is set in OBSD, then pulse is positive; if reset, negative. o N if IDOM: (0 .lt. N .lt.256) pulse IDOM for 25*N msec. If bit is set in OBSD, then IDOM is pulsed ON; if reset, IDOM is pulsed OFF. RESTRICTION: For a given DODD either all bits must be pulsed for the same duration or all bits must be levels.

9.2.1.6 NSC = Number Of State Components - NSC gives the number of independent components of the state vector. Specifically, by independent, we mean that output and input bits used to specify the value of the component are not used by any other component.

9.2.1.7 NSV = Number Of State Component Values - NSV is an array of NSC I*2 words giving the number of possible values for each of the NSC state vector components.

9.2.1.8 NS = Total Number Of State Values. - NS is a redundant quantity giving the total number of possible state values, i.e. the sum of the NSC quantities NSV.

DIGITAL STATUS CONTROL SYSTEM Page 9-9

9.2.1.9 OBSD = Output Bit State Definition - OBSD is a array of NS Z*2 words containing the masks which define the output values of each of the NS possible state values. For a given value, the most significant byte of the word contains a mask of all output bits which must be either set or reset (as opposed to dont-care). The least significant byte contains the values for those bits, i.e. For each must-be-set bit, the corresponding low byte bit is 1; for each must-be-reset bit the corresponding low byte bit is 0; for each dont-care-bit the corresponding high byte bit is reset. Note that the bits referred to here are a purely logical construction and are independent of bit assignments in the DOMs. (The connection between DOM bits and logical bits is made in the secondary data type OBIT of the .) Entries for NSV(IC) values of component (IC) should be made before entries for component (IC+1).

9.2.1.10 IBSD = Input Bit State Definition. - IBSD is an array of NS Z*4 words containing the masks which define the IDIM input values of each of the NS possible state values. For a given value, the most significant two bytes contain a mask of all input bits which must be either set or reset. The least significant two bytes contain values for those bits. The order of IBSD entries should match that of OBSD.

9.2.1.11 SEV = Severity Level X Log -

DIGITAL STATUS CONTROL SYSTEM Page 9-10 SEV is an (NS+1,NM)*Z2 array giving the severity level associated with possible states for each mode. The Index NS+1 is associated with Inconsistent States, Unrequested States, or CAMAC errors. The severity levels are %NORMAL = Normal state, no warning action %DISPLAY = Color code display, but do not issue warning message. %WARNING = Issue warning message at terminal(s). %PROHIBIT = Do not allow entry to this state in this mode. %ESCAPE = Call user escape routine to handle this situation In addition to the severity level one may append a log bit %LOG = Log entry to this state in permanent records.

9.2.1.12 DODU = DOD Primaries And Units - DODU is a (2,N)*I2 array which specifies the primary catalog number and the unit number of (arbitrary) N dod units associated with this DODD

9.2.2 DODN - Digital Output Device Names Secondary Supertype Conversion Usage _________ _________ __________ _____ DNAM 4 1A8 Device Type Name DEVP 4 1A4 Device primary name DODP 4 1I2 Device primary number SCNM 4 NSC*A8 (VS4) State Component Names SVNM 4 NS*A8 (VS4) State Value Names ONAM 4 NOB*A8 (VS4) Output bit names INAM 4 NIB*A8 (VS4) Input bit names OLBL 4 2*NOB*A8(VS4) Output bit state labels ILBL 4 2*NIB*A8(VS4) Input bit state labels MNAM 4 NM*A8 (VS4) Mode names. TRNT 4 NSC*I2 Transition times

DIGITAL STATUS CONTROL SYSTEM Page 9-11

9.2.2.1 DNAM = Device Type Name - DNAM is an 8-character name associated with this device. DNAM must be unique accross all DODNs. In addition to simply being an informative name, this variable is used to distinguish between devices of the same primary, but somewhat different logical structure.

9.2.2.2 DEVP = Primary - DEVP is the 4 character primary data type name associated with this device.

9.2.2.3 DODP = Device Primary Number - DODP is the primary catalog number of the associated .

9.2.2.4 SCNM = State Component Names - SCNM is an array of NSC 8 character names of each of the state vector components. The order of SCNM entries should match the component order of the associated DODD OBSD

9.2.2.5 SVNM = State Value Names - SVNM is an array of NS 8 character names of each of the possible state values. The order of SVNM entries should match the order of entries of the associated DODD OBSD.

DIGITAL STATUS CONTROL SYSTEM Page 9-12

9.2.2.6 ONAM = Output Bit Names - ONAM is an array of NOB 8 character names for each of the output bits. The order of ONAM entries should correspond to the least to most significant bit order of the associated DODD OBSD.

9.2.2.7 INAM = Input Bit Names. - INAM is an array of NIB 8 character input bit names. The order of INAM entries should correspond to the least to most significant bit order of the associated DODD IBSD.

9.2.2.8 OLBL = Output Bit State Labels - OLBL is a (2,NOB)*A8 array of output bit state labels (eg. ON/OFF, OPEN/NOT_OPEN). The index 1 is used for the set (1) state, the index 2 for the reset (0) state.

9.2.2.9 ILBL = Input Bit State Labels - ILBL is a (2,NIB)*A8 array of input bit state labels (eg. ON/OFF, OPEN/CLOSE). The index 1 is used for the set (1) state, the index 2 for the reset (0) state.

9.2.2.10 MNAM = Mode Names -

DIGITAL STATUS CONTROL SYSTEM Page 9-13 MNAM is an array of NM 8 character mode names.

9.2.2.11 TRNT = Transition Times. - TRNT is an array of NSC I*2 words specifing the time (in units of 0.1 seconds) required for each state component to accomplish a state transition. This parameter is used to prevent the checking of the device during the specified time interval after a transition has been requested.

9.2.3 - Digital Output Device Secondary Supertype Conversion Usage _________ _________ __________ _____ ALNM 1 A12 (VS4) Alias Name UNIT 1 3I2 DODN,DODD,DOM unit numbers OBIT 1 NOB*I2 Output bit #s IBIT 1 2*NIB*I2 DIM Units and bit #s CNTL 2 1Z2 Control word STAT 3 4+2*NSC*Z2 Device Status

9.2.3.1 ALNM = Alias Name - ALNM is a 12 character alias name (label) which may be used to give the device an alternate, more English-like, name. Note, however, this will work in one direction only: Given a name and unit, programs will be capable of displaying the alias, but input to programs must still be name/unit, not alias.

9.2.3.2 UNIT = DODN, DODD, DOM Unit Numbers. -

DIGITAL STATUS CONTROL SYSTEM Page 9-14 UNIT is a 3*I2 array giving the DODN, DODD, and DOM unit numbers associated with this unit.

9.2.3.3 OBIT = Output Bit Numbers - OBIT is an NOB*I2 array giving the bit number (0-31) within the physical output module of each of the NOB output bits. The order of OBIT entries should match the least to most significant bit order of the corresponding DODD OBSD.

9.2.3.4 IBIT = DIM Unit And Input Bit Numbers - IBIT is a (2,NIB)*I2 array giving the DIM module unit number and the bit number (0-31) within the physical input module of each of the input bits. Numbers are entered as unit, bit, unit, bit ... The order of entries should match the least to most significant bit order of the corresponding DODD IBSD.

9.2.3.5 CNTL = Control Word. - CNTL is an Z2 word allowing some control functions through the data base: bit 0: If set, allows unit to be disabled from touch panel. 1: If set, allows mode to be set from touch panel. 2: If set, device is offline.

9.2.3.6 STAT = Status -

DIGITAL STATUS CONTROL SYSTEM Page 9-15 STAT is a 4+2*NSC *I2 array reflecting the state of the DOD Unit. Word 1 : Input bits as read Word 2: bits 0-7: Output bits as read 8-15: Output bits as written Word 3: bits 0-2: Mode 8: Initialized: If this bit is zero (after data base re-gened), then micro-cluster will initialize the expected state to that actually observed from readback. The bit is then set. 9: Error messages supressed by VAX command 10: Error messages supressed by state transition 11: Error messages supressed by mode transition 12: Error messages supressed by error timer Word 4 : Used internally by the program for storage of disable timer. Not used by normal applications. Word 3+2*IC: bits 0-7: State value (0 .le. state value .lt. NS) as read and decoded for component IC. 8-15: State value as written for component IC. Word 4+2*IC: bits 0-2: Severity of state 3: Log requested 8: CAMAC error on reading output module. 9: CAMAC error on reading input module. 10: Inconsistent state 11: Unrequested state

9.2.4 DOM - Digital Output Module Secondary Supertype Conversion Usage _________ _________ __________ _____ OMTP 1 I2 Output module type

DIGITAL STATUS CONTROL SYSTEM Page 9-16 CTLW 1 Z4 CAMAC control word DATA 3 Z4 Data STAT 3 Z4 CAMAC status

9.2.4.1 OMTP = Output Module Type - OMTP specifies the type of Digital Output Module: 0 = IDOM (see SLC Hardware Manual) 1 = PPOM (see SLC Hardware Manual)

9.2.4.2 CTLW = CAMAC Control Word - CTLW is the standard CAMAC Control Word for the output module. Function code should be F0; subaddress A0; No scan modes.

9.2.4.3 DATA = Data - DATA contains the readback of the output lines for IDOMs and is not used for PPOMs.

9.2.4.4 STAT = CAMAC Status - STAT contains the CAMAC status returned by the MBCD interface.

9.2.5 DIM - Digital Input Module Secondary Supertype Conversion Usage _________ _________ __________ _____ CTLW 1 Z4 CAMAC control word DATA 3 Z4 Data STAT 3 Z4 CAMAC Status

DIGITAL STATUS CONTROL SYSTEM Page 9-17

9.2.5.1 CTLW = CAMAC Control Word - CTLW is the standard CAMAC Control Word (F0,A0) for the input module.

9.2.5.2 DATA = Input Data - DATA contains the 32 bits of data read.

9.2.5.3 STAT = CAMAC Status - STAT contains the CAMAC status returned by the MBCD interface.

9.2.6 Example: The following shows the data base for the previously discussed example. <:DODD:LI00,1; !Dig. Output Device Definition :NOB :=1; !One output bit :NIB :=2; !2 input bits :NM :=3; !3 modes :ESCR:=" "; !No escape routine :PLSE:=0; !Output levels, not pulses :NSC :=1; !1 State component :NSV :=2; !2 State values :NS :=2; !2 Consistent states :OBSD:=0101, !OPEN state : DOM_GATE=OPEN 0100; !CLOSED state: DOM_GATE=CLOSED :IBSD:=00030001, !OPEN state : SW_OPEN =OPEN, ! SW_CLOSD=NOTCLOSD 00030002; !CLOSED state: SW_OPEN =NOT_OPEN ! SW_CLOSD=CLOSED :SEV :=%NORMAL, !Offline: OPEN=Normal %NORMAL, ! CLOSED=Normal %DISPLAY, ! Error=Display ! %NORMAL, !Access: OPEN=Normal %WARNING, ! CLOSED=Abnormal %WARNING, ! Error=Abnormal ! %WARNING, !Noaccess:OPEN=Abnormal %NORMAL, ! CLOSED=Normal

DIGITAL STATUS CONTROL SYSTEM Page 9-18 %WARNING; ! Error=Abnormal :DODU:=35,1,35,2,35,3; ! (primary,unit)s > <:DODN:VX00,1; !Digital Output Device Name Definition :DNAM:="WBLYGATE"; !device name :DEVP:=GATE; ! primary (name) :DODP:=35; ! primary (number) :SCNM:="GSTATE "; !State component name :SVNM:="OPEN ", !State value names "CLOSED "; :ONAM:="DOM_GATE"; !Output bit Name :INAM:="SW_OPEN ", !OPEN switch bit name "SW_CLOSD"; !CLOSED switch bit name. :OLBL:="OPEN ", !DOM_GATE Labels "CLOSED "; :ILBL:="OPEN ", !SW_OPEN Labels - OPEN State "NOT_OPEN", ! - CLOSED State "CLOSED ", !SW_CLOSD Labels- OPEN State "NOTCLOSD"; ! - CLOSED State :MNAM:="OFFLINE ", !Modes "ACCESS ", "NOACCESS"; :TRNT:=10; !Transition time = 1 second > <:GATE:LI00,1; !Digital output device :ALNM:="GLDNGATE"; !Device Alias Name :UNIT:=1,1,1; !DODN,DODD,DOM units :OBIT:=0; !DOM_GATE in bit 0 of output module :IBIT:=1,0, !SW_OPEN in bit 0 of input module 1 1,1; !SW_CLOSD in bit 1 of input module 1 :CNTL:=%SETDIS+%SETMODE;!Allow disabling and mode chng from TP. :STAT:=0,0,0,0,0,0; !Status > <:DOM:LI00,1; !Digital output module :OMTP:=%IDOM; !IDOM Module :CTLW:=%CR1+%M18; !CTLW :STAT:=0; !Module status :DATA:=0; !Current module data > <:DIM:LI00,1; !Digital Input Module :CTLW:=%CR1+%M2; !CTLW :STAT:=0; !module status :DATA:=0; !current module data >

9.3 SEMI-CUSTOM USER PANELS Touch panel facilities exist to allow the "user" to construct panels for the display and control of sets of Digital Control devices. The typical panel

DIGITAL STATUS CONTROL SYSTEM Page 9-19 o Selects a group of micros and primaries to be displayed o Selects a single micro primary and unit to be displayed and controlled. o Displays the status of all devices in the group o Displays the status of the single selected device o Controls the single selected device. In addition to Digital Control functions, the panel may mix other related functions, e.g. DAOCS, Digital Status devices.

9.3.1 Example The following example shows the code for a sample panel containing both digital status and digital control devices: SHADOW: 0,7, ,DODCLEAR,DOD_SEL ,DODUPNL , ,* SCRIPT: 0,5, ,DIGITAL CONTROL SWITCH: 0,4,TST_DV_1 ,PRFV 1,DODDEVU ,DODUPNL , > CL01 ,DODMICRO, ,* SWITCH: 1,4,TST_DV_2 ,PRFV 2,DODDEVU ,DODUPNL , > CL01 ,DODMICRO, BUTTON: 0,2,SCREEN IN ,TARGET ,DODCOMP ,DODUPNL , > IN ,DODSTATE, BUTTON: 0,1,SCREEN OUT ,TARGET ,DODCOMP ,DODUPNL , > OUT ,DODSTATE, BUTTON: 1,2,IRIS OPEN ,IRIS ,DODCOMP ,DODUPNL , > OPEN ,DODSTATE, BUTTON: 1,1,IRIS CLOSE ,IRIS ,DODCOMP ,DODUPNL , > CLOSE ,DODSTATE, ! ! SHADOW: 3,7, ,DIDCLEAR,DID_SEL ,DIDUPNL , ,* SCRIPT: 5,5, ,DIGITAL STATUS SWITCH: 5,4,TEST DEVICE ,DIG1 1,DIDDEVU ,DIDUPNL , > CL01 ,DIDMICRO, ,* ! SWITCH: 0,6,DISPLY SINGL UNITS,DOD_SING,DST_DISP,DEXEC ,DSTATDSP, SWITCH: 3,6,DISPLY MULT UNITS,DSP_DODI,DST_DISP,DEXEC ,DSTATDSP, SWITCH: 5,6,DISPLY SINGL UNITS,DID_SING,DST_DISP,DEXEC ,DSTATDSP,

DIGITAL STATUS CONTROL SYSTEM Page 9-20

9.3.2 Panel Subroutines Three subroutines (apart from DEXEC) are referenced: o DODUPNL is the routine for handling user-custom digital control functions. o DIDUPNL is the routine for handling user-custom digital status functions (see Digital Input System). o DSTATDSP is the routine for generating all digital status and control displays.

9.3.3 DODUPNL Panel Variables The following variables are associated with subroutine DODUPNL: o DOD_SEL - Initialization variable. For purposes of this discussion, this variable is always filled with the value 'DODCLEAR'. It is associated with a SHADOW button and the initialization flag '*'. This function instructs DODUPNL to clear the list of micros and device primaries which will be included in the multiple device display. Hence it should precede the later statements which will fill the list (see below). The shadow button is also used as the button on which the micro, primary, and unit of the singly selected device are displayed, so space for 14 characters should be reserved.

DIGITAL STATUS CONTROL SYSTEM Page 9-21 o DODMICRO - When used with the initialization flag '*', the value specified for this variable is added to the list of micros to be included in the multiple unit display. When activiated by a button push, the value is used to specify the singly selected micro to be displayed in the single unit display, and to be controlled when this or some future button push specifies a value for the variable DODSTATE (see below). o DODDEVU - The four leftmost characters of the value of this variable specify a DOD device primary, and the four rightmost characters specify the unit. When used with the initialization flag '*', the primary is added to the list of primaries to be displayed in the multiple unit display. When activated by a button push, the primary and unit number specify the singly selected device to be displayed in the single unit display, and to be controlled when this or some future button push specifies a value for the variable DODSTATE (see below). o DODCOMP - The value of this variable specifies the component of the device to be controlled when this or some future button push places a value into the panel variable DODSTATE. o DODSTATE - When activated by a button push, the device component specified by DODMICRO, DODDEVU, and DODCOMP is set to the state named by DODSTATE. After the device is set, this variable is cleared so that no device will be set again until a new value for DODSTATE is activated.

DIGITAL STATUS CONTROL SYSTEM Page 9-22 o DODSWTCH - is a dummy variable. One frequently wishes to associate the variables DODMICRO and DODDEVU with a switch button specify the device currently being controlled and displayed. The value of the switch variable must be unique across all buttons comprising the switch. If DODMICRO or DODDEVU were used as the switch variable (as in the example above) the values used might not be unique; e.g. if (LI01,PRFV0001), (LI01,PRFV0002), and (LI02,PRFV0001) are used for the three buttons comprising the switch, then neither DODMICRO nor DODDEVU is unique across all three buttons. Hence the DODSWTCH variable is defined so that it may used as the switch variable and given unique, but otherwise arbitrary, values.

9.3.4 DSTATDSP Variables The following variables are associated with subroutine DSTATDSP: o DOD_SING - Displays all the gory details of the current singly selected device. o DOD_MULT - Displays minimal information for all units of all multiply selected devices in all multiply selected micros. o DOD_DODI - Same as DOD_MULT except that Digital Status devices (see Digital Input System) as well as Digital Control devices are displayed.

DIGITAL STATUS CONTROL SYSTEM Page 9-23 o DOD_BAD - Displays all Digital Control devices (independent of selection variables) with severity levels of DISPLAY or worse. o DOD_DEVS - Displays list of all DOD primaries and types, with multiply selected primaries color coded. o DOD_MICR - Displays list of all micros containing DOD devices, with multiply selected and offline micros color coded. o DOD_UNIT - Displays list of all units for current multiply selected micros and dod primaries. o DOD_DOMS - Displays CAMAC addresses for all DOMs associated with currently selected devices. o DOD_DIMS - Displays CAMAC addresses for all DIMs associated with currently selected devices. The following variables are associated with subroutine DOSELECT and are used to control paging of displays: o PAGE_1: Horizontal and vertical pages are both set to 1. Values of the current page number are written to this button. Hence this button must be included (whether shadow or otherwise) on any panels which use the paging variables. o PAGE_DWN - Vertical page number is increased by one. If vertical page number is greater than the number of pages in the current display, the page number is reset to 1.

DIGITAL STATUS CONTROL SYSTEM Page 9-24 o PAGE_UP - Vertical page number is decreased by 1 (if currently >1) o PAGE_RT - Horizontal page number is increased by 1. If greater than the total number of pages, then last page will be displayed. o PAGE_LFT - Horizontal page number is decreased by 1 (if <1).

CHAPTER 10 DIGITAL STATUS INPUT SYSTEM

10.1 INTRODUCTION This document describes a software system for monitoring logical devices which consist only of status bits which are read through SLC Isolated Digital Input Modules (IDIMs, see SLC Hardware Manual). A similar but somewhat more complicated system for devices which have digital control as well as status information is described in the chapter "Digital Status Control System". The goal of the system is to provide complete software to allow one to monitor devices which consist solely of read-only status bits. Such devices can be added to the system by additions to the data base, without the need for software tailored to the specific device. Digital Status "devices" are logical constructions and place no restrictions on the IDIM units or channels from which the data are read. Monitoring of the devices is done through the micro-clusters, while display and error reporting functions remain in the VAX. Communication between the VAX and micros will be done primarily through through the SLCNET message facility and secondarily through the database.

DIGITAL STATUS INPUT SYSTEM Page 10-2

10.1.1 Digital Input Devices The collection of all digital input signals are logically divided into generic DIGITAL INPUT DEVICES (DIDs). A given DID may have up to 8 input bits, which may originate from more than one input module.

10.1.2 Severity Levels In order to provide flexibility in error reporting, several severity levels are defined on a bit by bit basis: In a normal state, no action is taken. For bits in an abnormal state the DISPLAY severity level color codes these bits on displays, but issues no error messages. The WARNING level will issue error messages, and the ESCAPE level will call a tailored software routine to handle truly exceptional conditions for which special action is required. Additionally, a TOGGLE level exists for which a warning message is issued any time the status bit changes, independent of its final state. A LOG level is also available to allow states to be logged in the message file without issuing warning messages.

10.1.3 Modes The severity levels associated with different states may be dynamically redefined through the use of DID MODEs. Separate severity levels are defined for each mode of the device.

10.2 DATA BASE STRUCTURE The digital input system uses four primary data types:

DIGITAL STATUS INPUT SYSTEM Page 10-3 o DIDD = Digital Input Device Definition. This data type, of which there is only one unit per micro, simply provides a list of (see below) primary data types o DIDN = Digital Input Device Names. This data type contains information (primarily names) which needs to be accesed only by the VAX (not micros). This information is independent of the micro or unit of devices to which it applies and is therefore stored only in micro-cluster VX00. o = Digital Input Device, where is any four-character name defining the DID. This data type contains information unique to a single unit of a DID. o DIM = Digital Input Module. This data type defines the physical digital input modules, independent of the nature of the data they read.

10.2.1 DIDD - Digital Input Device Definition Secondary Supertype Conversion Usage _________ _________ __________ _____ DEVP 1 VI2 Device primaries

DIGITAL STATUS INPUT SYSTEM Page 10-4

10.2.1.1 DEVP - Device Primaries - DEVP is a variable length array giving the primary category numbers of all s for this micro.

10.2.2 DIDN - Digital Input Device Names Secondary Supertype Conversion Usage _________ _________ __________ _____ NIB 4 1I2 # input bits NM 4 1I2 # modes DNAM 4 1A8 Device Type Name DEVP 4 1A4 Device primary name DIDP 4 1I2 Device primary number INAM 4 NIB*A8 (VS4) Input bit names ILBL 4 2*NIB*A8(VS4) Input bit state labels MNAM 4 NM*A8 (VS4) Mode names. ESCR 4 1A8 (VS4) User escape routine

10.2.2.1 NIB = # Input Bits. - NIB specifies the number of input bits associated with the DID. RESTRICTION: NIB .LE. 8

10.2.2.2 NM = # Modes. - NM specifies the number of modes of the DID. RESTRICTION: NM .LE. 8

10.2.2.3 DNAM = Device Type Name -

DIGITAL STATUS INPUT SYSTEM Page 10-5 DNAM is an 8-character name associated with this device. DNAM must be unique across all DIDNs. In addition to simply being an informative name, this variable is used to distinguish between devices of the same primary, but somewhat different logical structure.

10.2.2.4 DEVP = Primary - DEVP is the 4 character primary data type name associated with this device.

10.2.2.5 DIDP = Device Primary Number - DIDP is the primary catalog number of the associated .

10.2.2.6 INAM = Input Bit Names. - INAM is an array of NIB 8 character input bit names. The order of INAM entries should correspond to that of the corresponding IBIT entries (see below), and to the least to most significant bit order of the associated DIDD SEVMs.

10.2.2.7 ILBL = Input Bit State Labels - ILBL is a (2,NIB)*A8 array of input bit state labels (eg. ON/OFF, OPEN/CLOSE). The index 1 is used for the set (1) state, the index 2 for the reset (0) state.

DIGITAL STATUS INPUT SYSTEM Page 10-6

10.2.2.8 MNAM = Mode Names - MNAM is an array of NM 8 character mode names.

10.2.2.9 ESCR = User Escape Routine - ESCR is an 8 character name which specifies the name of a user routine to be called to handle tailored applications. If this parameter is left unspecified, no user routine will be called. If specified, the name must be associated with a subroutine using the SLC logical name services. The routine will be called if a state is detected with severity level ESCAPE

10.2.3 - Digital Input Device Secondary Supertype Conversion Usage _________ _________ __________ _____ ALNM 1 A12 (VS4) Alias Name DIDN 1 I2 DIDN unit number IBIT 1 2*NIB*I2 DIM Units and bit #s SEVM 1 (5,NM)*Z2 Severity Level Masks CNTL 2 1Z2 Control word STAT 3 3Z2 Device Status

10.2.3.1 ALNM = Alias Name - ALNM is a 12 character alias name (label) which may be used to give the device an alternate, more English-like, name. Note, however, this will work in one direction only: Given a name and unit, programs will be capable of displaying the alias, but input to programs must still be name/unit, not alias.

DIGITAL STATUS INPUT SYSTEM Page 10-7

10.2.3.2 DIDN = DIDN Unit Number. - DIDN specifies the DIDN unit number (see above) associated with this unit.

10.2.3.3 IBIT = DIM Unit And Input Bit Numbers - IBIT is a (2,NIB)*I2 array giving the DIM module unit number and the bit number (0-31) within the physical input module of each of the input bits. Numbers are entered as unit, bit, unit, bit ... The order of entries should match that of the coressponding DIDN INAM entries.

10.2.3.4 SEVM = Severity Level Masks - SEVM is a (5,NM)*Z2 array of masks used to define the severity level of different states and modes. The first index specifies the severity level in the order DISPLAY, WARNING, ESCAPE, LOG, TOGGLE. For each mask, the most significant byte selects the bits of interest, and the least significant byte specifies the state of those bits required to match the NORMAL state. i.e. the specified severity level will be true iff (data .and. hi-byte) .ne. lo-byte. The TOGGLE level operates somewhat differently than the other levels. Only the most significant byte is used. If a bit which is set in the TOGGLE mask is also set in the most significant byte of the WARNING, ESCAPE, or LOG masks, then the WARNING, ESCAPE, or LOG level is invoked any time that bit changes state, independent of the direction of change.

DIGITAL STATUS INPUT SYSTEM Page 10-8 DISPLAY = Bits failing the DISPLAY will be color coded yellow on all displays, but no error messages will be issued. This level is overridden by the WARNING or ESCAPE levels, but may be used in parallel with the LOG level. WARNING = Warning messages will be issued for bits failing the WARNING mask, and these bits will be color coded BLUE in displays. This level can be used in parallel with the LOG and TOGGLE levels. ESCAPE = For bits failing the ESCAPE mask, the user-specified escape routine (see above) will be called, and these bits will be color coded cyan in displays. This level can be used in parallel with the LOG and TOGGLE levels. LOG = For bits failing the LOG mask, information will be logged in the Message file. This level can be used in parallel with any of the other levels TOGGLE = As described above, this level is used to set the WARNING, ESCAPE, or LOG levels any time the bit changes state.

10.2.3.5 CNTL = Control Word. - CNTL is an Z2 word allowing some control functions through the data base: bit 0: If set, allows unit to be disabled from touch panel. 1: If set, allows mode to be set from touch panel.

10.2.3.6 STAT = Status - STAT is a word array reflecting the state of the DID Unit. Word 1 : Least significant byte: Input bits as read Most significant byte: CAMAC read errors Word 2: bits 0-2: Mode 9: Error messages supressed by VAX command 12: Error messages supressed by error timer Word 3 : Used internally by the program for storage of disable timer. Not used by normal applications.

DIGITAL STATUS INPUT SYSTEM Page 10-9

10.2.4 DIM - Digital Input Module Secondary Supertype Conversion Usage _________ _________ __________ _____ CTLW 1 Z4 CAMAC control word DATA 3 Z4 Data STAT 3 Z4 CAMAC Status

10.2.4.1 CTLW = CAMAC Control Word - CTLW is the standard CAMAC Control Word (F0,A0) for the input module.

10.2.4.2 DATA = Input Data - DATA contains the 32 bits of data read.

10.2.4.3 STAT = CAMAC Status - STAT contains the CAMAC status returned by the MBCD interface.

10.2.5 Example: The following shows the data base for a hypothetical device BOX. Box has four input bits: TEMP has states HOT and COLD. The normal state is COLD. If the device becomes HOT, an escape routine is triggered. POWER has states ON and OFF. The normal state is ON. If the device is turned OFF, the bit is color coded in displays but no warning messages are issued. DOOR has states OPEN and CLOSED. Any time this state changes

DIGITAL STATUS INPUT SYSTEM Page 10-10 a warning message is issued and logged. DOG has states BARKING and QUIET, either of which is considered normal. <:DIDD:LI00,1; !Dig. Output Device Definition :DIDU:=35,36; ! (primary,unit)s > <:DIDN:VX00,1; !Digital Output Device Name Definition :NIB :=4; !4 input bits :NM :=1; !1 mode :DNAM:="BLACKBOX"; !device name :DEVP:=BOX ; ! primary (name) :DIDP:=35; ! primary (number) :INAM:="TEMP ", !Bit names "POWER ", "DOOR ", "DOG "; :ILBL:="HOT ", !Bit labels - TEMP "COLD ", "ON ", ! POWER "OFF ", "OPEN ", ! DOOR "CLOSED ", "BARKING ", ! DOG "QUIET "; :MNAM:=" "; !Default Mode :ESCR:="BOX_TRIP"; !Escape routine > <:BOX :LI00,1; !Digital input device :ALNM:="BLUEBOX "; !Device Alias Name :DIDN:=1; !DIDN,DIDD units :IBIT:=1,0, !TEMP in bit 0 of input module 1 1,1, !POWER in bit 1 of input module 1 1,2, !DOOR in bit 2 of input module 1 1,29; !DOG in bit 29 of input module 1 :SEVM:=0202, !DISPLAY on POWER OFF 0400, !WARN on DOOR toggle 0100, !ESCAPE on TEMP HOT 0400, !LOG on DOOR toggle 0400; !TOGGLE mode for DOOR :CNTL:=%SETDIS+%SETMODE;!Allow disabling and mode chng from TP. > <:DIM:LI00,1; !Digital Input Module :CTLW:=%CR1+%M2; !CTLW :STAT:=0; !module status :DATA:=0; !current module data >

10.3 SEMI-CUSTOM USER PANELS Touch panel facilities exist to allow the "user" to construct panels

DIGITAL STATUS INPUT SYSTEM Page 10-11 for the display of Digital Status devices. The typical panel o Selects a group of micros and primaries to be displayed o Selects a single micro primary and unit to be displayed o Displays the status of all devices in the group o Displays the status of the single selected device In addition to Digital Status functions, the panel may mix other related functions, e.g. DAOCS, Digital Control devices.

10.3.1 Example The following example shows the code for a sample panel containing both digital status and digital control devices: SHADOW: 0,7, ,DODCLEAR,DOD_SEL ,DODUPNL , ,* SCRIPT: 0,5, ,DIGITAL CONTROL SWITCH: 0,4,TST_DV_1 ,PRFV 1,DODDEVU ,DODUPNL , > CL01 ,DODMICRO, ,* SWITCH: 1,4,TST_DV_2 ,PRFV 2,DODDEVU ,DODUPNL , > CL01 ,DODMICRO, BUTTON: 0,2,SCREEN IN ,TARGET ,DODCOMP ,DODUPNL , > IN ,DODSTATE, BUTTON: 0,1,SCREEN OUT ,TARGET ,DODCOMP ,DODUPNL , > OUT ,DODSTATE, BUTTON: 1,2,IRIS OPEN ,IRIS ,DODCOMP ,DODUPNL , > OPEN ,DODSTATE, BUTTON: 1,1,IRIS CLOSE ,IRIS ,DODCOMP ,DODUPNL , > CLOSE ,DODSTATE, ! ! SHADOW: 3,7, ,DIDCLEAR,DID_SEL ,DIDUPNL , ,* SCRIPT: 5,5, ,DIGITAL STATUS SWITCH: 5,4,TEST DEVICE ,DIG1 1,DIDDEVU ,DIDUPNL , > CL01 ,DIDMICRO, ,* ! SWITCH: 0,6,DISPLY SINGL UNITS,DOD_SING,DST_DISP,DEXEC ,DSTATDSP, SWITCH: 3,6,DISPLY MULT UNITS,DSP_DODI,DST_DISP,DEXEC ,DSTATDSP, SWITCH: 5,6,DISPLY SINGL UNITS,DID_SING,DST_DISP,DEXEC ,DSTATDSP,

DIGITAL STATUS INPUT SYSTEM Page 10-12

10.3.2 Panel Subroutines Three subroutines (apart from DEXEC) are referenced: o DODUPNL is the routine for handling user-custom digital control functions (see Digital Output System). o DIDUPNL is the routine for handling user-custom digital status functions. o DSTATDSP is the routine for generating all digital status and control displays.

10.3.3 DIDUPNL Panel Variables The following variables are associated with subroutine DIDUPNL: o DID_SEL - Initialization variable. For purposes of this discussion, this variable is always filled with the value 'DIDCLEAR'. It is associated with a SHADOW button and the initialization flag '*'. This function instructs DIDUPNL to clear the list of micros and device primaries which will be included in the multiple device display. Hence it should precede the later statements which will fill the list (see below). The shadow button is also used as the button on which the micro, primary, and unit of the singly selected device are displayed, so space for 14 characters should be reserved.

DIGITAL STATUS INPUT SYSTEM Page 10-13 o DIDMICRO - When used with the initialization flag '*', the value specified for this variable is added to the list of micros to be included in the multiple unit display. When activiated by a button push, the value is used to specify the single micro to be displayed in the single unit display. o DIDDEVU - The four leftmost characters of the value of this variable specify a DID device primary, and the four rightmost characters specify the unit. When used with the initialization flag '*', the primary is added to the list of primaries to be displayed in the multiple unit display. When activated by a button push, the primary and unit number specify the single device to be displayed in the single unit display. o DIDSWTCH - is a dummy variable. One frequently wishes to associate the variables DIDMICRO and DIDDEVU with a switch button specify the device currently being displayed. The value of the switch variable must be unique across all buttons comprising the switch. If DIDMICRO or DIDDEVU were used as the switch variable (as in the example above) the values used might not be unique; e.g. if (LI01,PRFV0001), (LI01,PRFV0002), and (LI02,PRFV0001) are used for the three buttons comprising the switch, then neither DIDMICRO nor DIDDEVU is unique across all three buttons. Hence the DIDSWTCH variable is defined so that it may used as the switch variable and given unique, but otherwise arbitrary, values.

DIGITAL STATUS INPUT SYSTEM Page 10-14

10.3.4 DSTATDSP Variables The following variables are associated with subroutine DSTATDSP: o DID_SING - Displays all the gory details of the current singly selected device. o DID_MULT - Displays minimal information for all units of all multiply selected devices in all multiply selected micros. o DID_DODI - Same as DID_MULT except that Digital Control devices (see Digital Output System) as well as Digital Control devices are displayed. o DID_BAD - Displays all Digital Status devices (independent of selection variables) with severity levels of DISPLAY or worse. o DID_DEVS - Displays list of all DID primaries and types, with multiply selected primaries color coded. o DID_MICR - Displays list of all micros containing DID devices, with multiply selected and offline micros color coded. o DID_UNIT - Displays list of all units for current multiply selected micros and DID primaries. o DID_DIMS - Displays CAMAC addresses for all DIMs associated with currently selected devices.

DIGITAL STATUS INPUT SYSTEM Page 10-15 The following variables are associated with subroutine DOSELECT and are used to control paging of displays: o PAGE_1: Horizontal and vertical pages are both set to 1. Values of the current page number are written to this button. Hence this button must be included (whether shadow or otherwise) on any panels which use the paging variables. o PAGE_DWN - Vertical page number is increased by one. If vertical page number is greater than the number of pages in the current display, the page number is reset to 1. o PAGE_UP - Vertical page number is decreased by 1 (if currently >1) o PAGE_RT - Horizontal page number is increased by 1. If greater than the total number of pages, then last page will be displayed. o PAGE_LFT - Horizontal page number is decreased by 1 (if <1).

CHAPTER 11 ANALOG STATUS SYSTEM

11.1 INTRODUCTION The analog status system is used to monitor an arbitrary number of quasi-static voltages on the accelerator. Data is read through 32 channel Smart Analog Monitors (SAMs). No restrictions are placed on the crate or channel locations of specific inputs. In order to separate logical functions from physical crate and channel addresses the total system is divided into logical subsystems. A subsystem consists of a set of channel names. For a given channel name, corresponding voltages may exist in some or all micro-clusters. Operational access to the system is through the Analog Status touch panel. Provision exists in the software for the following functions: 1. Automatic monitoring of the voltages to within fixed or adjustable tolerances. 2. Enabling and disabling (with automatic timeout) of error messages on individual channels. 3. Scaling from volts to arbitrary units.

ANALOG STATUS SYSTEM Page 11-2 4. Display of current values by channel across micros, or by micro across channels. 5. Time plots of selected channels (software chart recorder).

11.2 DATA BASE STRUCTURE Two primary data types define the data base for the analog status system. Primary data ASDF is used to define subsystems, and ASTS defines data specific to a single micro and SAM.

11.2.1 Primary Data Type ASDF Secondary Supertype Conversion _________ _________ __________ SNAM 4 2A4 Subsystem name CNAM 4 VS4 Channel names and scaled units. where o SNAM is the 8-character subsytem name, which should not contain blanks, commas, equal signs or quotation marks. o CNAM defines the 8-character channel names and the 4-character scaled units (e.g. vlts, amps, yen, ...). Format: NAME1,UNITS1,NAME2,UNITS2,...,NAMEN,UNITSN. where both the names and units are 8-character strings (Note, however, that only the first 4 characters of the units are used.) Channel names must be unique across all subsystems unless one wants a single channel to belong to more than one

ANALOG STATUS SYSTEM Page 11-3 subsystem. Names should not contain blanks, commas, equal signs, or quotation marks.

11.2.2 Primary Data Type ASTS Secondary Supertype Conversion _________ _________ __________ CTLW 1 1Z4 Module CAMAC CTLW CHAN 1 2I2 Starting and total # channels NAME 2 VS4 Channel names LIMS 2 VR4 Limits SCAL 1 VR4 Scale factors CTRL 2 VZ2 Control words DATA 3 VR4 Raw and scaled channel readings STAT 3 VZ2 Micro status words where o CTLW is the CAMAC address (CTLW, F0) of the SAM. o CHAN is a 2-word array giving then starting channel number (0-32) and the number of consecutive channels to be read. o NAME is an array of 8-character channel names whose dimension must match the total number of channels as given by CHAN(2) above. A SAM channel is associated with a specific subsystem by matching NAME to an identical CNAM for primary data type ASDF. Names should not contain blanks, commas, equal signs or quotation marks. o LIMS is a (2,NCHAN) real array giving the tolerance limits, in scaled units, for the channel. If the %TOLS bit of the corresponding control word (see CTRL below) is set,

ANALOG STATUS SYSTEM Page 11-4 LIMS(1,ICHAN) is the reference value for the channel, and LIMS(2,ICHAN) is the channel tolerance. If the %TOLS bit is reset, LIMS(1,ICHAN) and LIMS(2,ICHAN) are the lower and upper limits respectively, within which the channel is within tolerance. o SCAL is a (2,NCHAN) real array giving the scale factors used to convert from raw to scaled values. Normally a linear relationship is assumed: = SCAL(1,ICHAN) + SCAL(2,ICHAN)*. However, non-linear 2-parameter relationships can be handled using special bits of the control word (see CNTRL below) if appropriate software is written. o DATA is a (2,NCHAN) real array giving the unscaled (volts as read by ADC) and scaled data values. o CTRL is a (2,NCHAN) word array used for control purposes: CTRL(1,ICHAN) Bit 0- 2 give the severity level used if channel is out of tolerance: 0 = %DISPLAY: Display only; no error mesages. 1 = %WARNING: Warning messages issued. 7 = %PANIC: Special computer action required through tailored software. 3 = %LOG : Log data in error file if out of tolerance. 4 5 Set to disable error messages for a finite time duration. Should normally be intialized to 0, and set only through the operator console. 6 Used internally as a toggle bit informing the micro that it should examined and heed the disable bit (bit 5 above). Should normally be intialized to 0.

ANALOG STATUS SYSTEM Page 11-5 7 8 = %TOLS: If set indicates that LIMS (see above) should be interpreted as reference values and tolerances. If reset, indicates that LIMS should be interpreted as lower and upper tolerance limits. 9 = %THRMOCPL: If set, indicates that channel is a thermocouple and requires non-standard scaling. 0-11 2 = %ADJUST : If set, indicates that LIMS is allowed to be changed from the console. Note, however, that such changes will be lost if the data-base is re-gened. 3-15 CTRL(2,ICHAN) gives the disable time in minutes for which the channel can remain disabled. Normally initialized to 0, and set from the operator console. o STAT is a (2,NCHAN) word array used for status information from the micro. Normally initialized to 0 and used internally by the programs. STAT(1,ICHAN) Bit 0 is set by the micro if the channel is out of tolerance. 1 is set by the micro if a CAMAC or other error occurred in reading the data 2 is set by the micro if the device is "dead" or disabled 3 is set by the micro if the channel is out of tolerance. 4 is used internally by the micro to prevent more than one out-of-tolerance message from a single channel within one minute 5 is set to disable error messages for a finite time duration. Controlled internnaly by the micro: When bit 6 of CTRL(1,ICHAN) is set to a state different from bit 6 of STAT(1,ICHAN), the micro copies the disable bit (bit 5) from CTRL(1,ICHAN) to STAT(1,ICHAN). After the timeout occurs the micro resets the disable bit in STAT, independent of that in CTRL

ANALOG STATUS SYSTEM Page 11-6 6 Used internally as a synchronization bit. Whenever bit 6 of CTRL(1,ICHAN) is different from that in STAT(1,ICHAN) the micro copies the disable bit, the synchronization bit, and the disable time from CTRL to STAT. This exercise is necessary to allow the micro to reset the disable bit, since the micro does not have write access to CTRL. 7-15 STAT(2,ICHAN) is the disable time, initially copied from CTRL, and counted down to 0 by the micro, at which time the disable bit is reset.

CHAPTER 12 CRATE MONITORING AND INITIALIZATION

12.1 INTRODUCTION The CRATE job in the micro takes care of monitoring CAMAC crates, intialization of crates when necessary, and performing crate verification upon request.

12.2 MONITORING CRATE STATUS One function of the CRATE job is monitoring the status of the CAMAC crates associated with a micro. The data register of each crate verifier is initialized with the word TEST_DATA. If power to the crate is lost, the TEST_DATA pattern in the verifier will be destroyed. The CRATE job waits at its mailbox with a finite TIMEOUT (currently 5 seconds). If it has received valid mail during that time, it decodes the low order function code and carries out the actions corresponding to that code. If the wait at the mailbox has timed out, i.e. if there is nothing else that it is requested to do, then the CRATE job calls CRATE_WATCH to loop over all crates, checking the data register in each crate verifier to see if the data is still equal to TEST_DATA and checking the CAMAC status return to see if the crate is presently on line. If a crate is now online, but was offline

CRATE MONITORING AND INITIALIZATION Page 12-2 during or since the last call to CRATE_WATCH, then the crate initialization procedure is performed.

12.3 CRATE INITIALIZATION PROCEDURE The following sequence of initialization is done on each crate at start-up and whenever the CRATE job detects that a crate is now online but has been offline since it was last initialized: o Clear ("Z") to the crate, if power has been off. o Make sure inhibit is turned off. o Initialize data register in crate verifier with TEST_DATA. o If the crate contains a cable access receiver module (CARM), then reset it with CAMAC code F(9). o If the crate contains a PDU, then do PDU initialization o If the crate contains magnet DACs and SAMs, send a message to MGNT job to have it do its own initialization. o If crate controls klystrons, send a message to KLYS job to do its own initialization. o Additional initialization messages for other jobs will be added as needed. o

CRATE MONITORING AND INITIALIZATION Page 12-3 Read back data in crate verifier and check CAMAC status return to be sure that crate is now online and has been online during the initialization procedure. If so, update the crate status :CRTS: in the database to be online.

12.4 CRATE VERIFICATION Upon receipt of the function code CRAT_VEREX from the VAX, the CRATE job does a verify of the requested crate and sends the results back to the VAX for display.

CHAPTER 13 THE CABLE VIDEO SOFTWARE.

13.1 FUNCTIONAL REQUIREMENTS. The Cable Video software enables users to turn on and off Cable Video transmitter modules and to select a Video Channel to broadcast the Input signal. Presently, there are 4 Channels (54, 55, 56 and 58) which are reserved for the Cable Video system. There are currently 10 transmitter modules each with 8 Inputs, although many Inputs are not physically connected to any Video signal. Users communicate their desires to the Cable Video software via the Cable Video touch panel.

13.1.1 The Cable Video Touch Panel. The touch panel consists of 4 sets of buttons, namely :- - The Channel Select Buttons. There is one button for each Channel allowing the user to select the Channel on which he wants to broadcast.

THE CABLE VIDEO SOFTWARE. Page 13-2 - The Module Select Buttons. There is one button for each transmitter allowing the user to select on which module he wants to operate. - The Input Select Buttons. There are 8 of these buttons for each module. Each Input button may have a legend describing the Video input physically connected - if there is no Video input, then there should be no legend on the button. This set of buttons allows the user to select an Input, and implicitly turn ON the selected transmitter. - The Turn Off Buttons. There are 2 of these, namely Turn Off Channel and Turn Off Module. These allow the use to turn off the selected Channel or Module.

13.1.2 The Cable Video Database Records. In order that different users may control the Cable Video System from different Cows or Calfs at the same time, a current description of the state of the system is kept in the Database. The relevent Database entries are :- - TVCH:MODL - The name of the Module currently transmitting on this Channel. - TVCH:HSTA - The Channel hardware status.

THE CABLE VIDEO SOFTWARE. Page 13-3 - TVCH:INPT - The legend of the Input currently being broadcast on this Channel. - TVMD:CTLW - The Camac address of the transmitter Module. - TVMD:DATA - A copy of the data last written to Camac for this transmitter. - TVMD:HSTA - The Module hardware status. - TVMD:INPT - Eight Input legends for this Module. The above Database entries are written and read whenever necessary to ensure both that the DB and the touch panel buttons truly reflect the current Cable Video state as far as is possible.

13.1.3 The Software Source Files. The source files which make up the Cable Video package are :- - CAVMBUTN - the panel button handler - CAVMCAMAC - the Camac access routine - CAVMCAMER - the Camac error processor - CAVMDBUPD - the (partial) Database update routine - CAVMINIT - the initialisation routine and - CAVMUPDAT - the panel and internal array update procedure.

THE CABLE VIDEO SOFTWARE. Page 13-4

13.2 SOFTWARE FUNCTIONAL DESIGN

13.2.1 CAVMINIT This module is called by a shadow button when the Cable Video button is pressed on the Index panel. 1. Set up as nothing yet selected. 2. Read DB for Channel and Module status ( TVCH:HSTA and TVMD:HSTA ) 3. First time the SCP is called (or if software is set as inconsistent) :- i. Set up DB Clists for future DB accesses ii. Read DB for Camac hardware addresses (TVMD:CTLW) iii. Get all the transmitter modules' names (DB_MICROUNITS) iv. Write 'Disabled' onto unavailable channel and module buttons 4. Call CAVMUPDAT to update touch panels and internal arrays.

13.2.2 CAVMBUTN CAVMBUTN is the collection of modules which handle the various Cable Video touch panel buttons. There are four collections of buttons in order to enable Channel selection, Module selection, Input selection (which is also implicitly a turn on function) and Turn Off function

THE CABLE VIDEO SOFTWARE. Page 13-5 buttons. Note that each time a button is pressed, a check is made on the software consistency. The consistency state is set inconsistent when the software detects a fatal condition after which it would be at the best pointless, and at the worst dangerous, to allow further Cable Video operations. Such a condition would be a bad Database call resulting in the software not knowing the Transmitter Module names for example. This allows controlled processing of SCP internal software inconsistencies. The entries and software design of CAVMBUTN is as follows :-

13.2.2.1 Entry CAVMCHNS - Channel Select. 1. If the software is inconsistent, then O/P error message and exit. 2. Set no Input selected. 3. If the Channel button name is not recognised, send an error and exit . 4. If the Channel is not available (off-line), O/P an error, set no Channel selected and exit. 5. Call CAVMUPDAT to update touch panels and internal arrays.

13.2.2.2 Entry CAVMMODS - Module Select.

THE CABLE VIDEO SOFTWARE. Page 13-6 1. If the software is inconsistent, then O/P error message and exit. 2. Set no Input selected. 3. If the Module button name is not recognised, send an error and exit . 4. If the Module is not available (off-line), O/P an error, set no Module selected and exit. 5. Call CAVMUPDAT to update touch panels and internal arrays.

13.2.2.3 Entry CAVMINPS - Input Select (Implicit Turn On). 1. If the software is inconsistent, then O/P error message and exit. 2. Call CAVMUPDAT to update touch panels and internal arrays (another COW may also be using this software at the same time). 3. If no Channel or no Module has been slected yet, O/P an error, set no Input selected and exit. 4. If the Input name is not recognised, then send an error and exit. 5. If the selected Channel is currently broadcasting, then :-

THE CABLE VIDEO SOFTWARE. Page 13-7 i. Call CAVMCAMAC in order to turn OFF the module transmitting on the selected Channel. ii. Call CAVMDBUPD to update the Database to the new situation. iii. Call CAVMUPDAT to update the internal arrays and touch panel. 6. If the selected Module is currently transmitting, then :- i. Call CAVMCAMAC in order to turn OFF the selected module. ii. Call CAVMDBUPD to update the Database to the new situation. iii. Call CAVMUPDAT to update the internal arrays and touch panel. 7. Call CAVMCAMAC in order to turn ON the selected transmitter module with the selected Input to broadcast on the selected Channel. 8. Call CAVMDBUPD to update the Database to the new situation. 9. Set no Input selected. 10. Call CAVMUPDAT to update the internal arrays and touch panel.

13.2.2.4 Entry CAVMOFFC - Turn Off Channel.

THE CABLE VIDEO SOFTWARE. Page 13-8 1. If the software is inconsistent, then O/P error message and exit. 2. Call CAVMUPDAT to update touch panels and internal arrays (another COW may also be using this software at the same time). 3. Set no Input selected. 4. If a Channel has not yet been selected, O/P a message to the user and exit. 5. If the selected Channel is not broadcasting, O/P a message to the user and exit. 6. Call CAVMCAMAC in order to turn OFF the module which is transmitting on selected Channel. 7. Call CAVMDBUPD to update the Database to the new situation. 8. Call CAVMUPDAT to update the internal arrays and touch panel.

13.2.2.5 Entry CAVMOFFM - Turn Off Module. 1. If the software is inconsistent, then O/P error message and exit. 2. Call CAVMUPDAT to update touch panels and internal arrays (another COW may also be using this software at the same time).

THE CABLE VIDEO SOFTWARE. Page 13-9 3. Set no Input selected. 4. If a Channel has not yet been selected, O/P a message to the user and exit. 5. If the selected Module is not transmitting, O/P a message to the user and exit. 6. Call CAVMCAMAC in order to turn OFF the selected module. 7. Call CAVMDBUPD to update the Database to the new situation. 8. Call CAVMUPDAT to update the internal arrays and touch panel.

13.2.3 CAVMCAMAC All Camac accesses for the Cable Video package are made via this CAVMCAMAC routine. As you shall see, as well as doing the Camac commands necessary for the requested function, CAVMCAMAC initiates other Camac accesses to check on the Database/Camac consistency. 1. Call CAMIO in order to read the last data written to relevent Camac module. 2. If the above call was bad for any reason, then call CAVMCAMER to process the error, and then exit. 3. If the Camac data and the Database data don't agree, and if there has been no reset of the Camac module, then send an error message to inform the user (and log it).

THE CABLE VIDEO SOFTWARE. Page 13-10 4. Call CAMIO in order to write a data word to the Camac module which will then execute the required action. 5. If the above call was bad for any reason, then call CAVMCAMER to process the error, and then exit. 6. Call CAMIO to read back the data which has just been written. 7. If the above call was bad for any reason, then call CAVMCAMER to process the error, and then exit. 8. If the Camac write data and the Camac read-back data don't agree, then :- i. Send and log an error message. ii. Call CAMIO in order to attempt to turn the relevent transmitter OFF. iii. If the above call was bad for any reason, then call CAVMCAMER to process the error. ( Note that we do not exit this time! ) iv. Call CAVMDBUPD to update the Database to show that the module is no longer transmitting. 9. Update the Database with the last written Camac data (TVMD:DATA).

13.2.4 CAVMCAMER This module is the Camac error processor - it is entered only if a

THE CABLE VIDEO SOFTWARE. Page 13-11 previous call to CAMIO resulted in a bad return code. It is only called from CAVMCAMAC. 1. If the return code is a message service error, then send and log an error such as 'Can't talk to micro LIXX', and then exit. 2. If the return code is no Camac X response, then :- i. Send and log an error message. ii. Call CAVMDBUPD to update the Database to show that the module is not transmitting. iii. Update the Database with the last written Camac data set to HEX 7F. (This is the data in the Camac module after a reset is made, and a reset must be made to the Camac module before we can use it again).(TVMD:DATA). iv. Exit. 3. If the return indicates a crate timeout, then :- i. Send and log an error message. ii. Call CAVMDBUPD to update the Database to show that the module is not transmitting. iii. Update the Database with the last written Camac data set to HEX 7F. (This is the data in the Camac module after a reset is made, and a reset must be made to the Camac module before we can use it again).(TVMD:DATA).

THE CABLE VIDEO SOFTWARE. Page 13-12 iv. Exit. 4. Send and log a Camac error message. 5. Set no Module and no Input selected.

13.2.5 CAVMUPDAT This routine is called at least once every time any Cable Video touch panel button is pressed. Its function is to read the Database to get all the latest CAVM information and to update the touch panel buttons accordingly. 1. Read the DB to get the currently transmitting Modules (TVCH:MODL). 2. Read the DB to get the Inputs connected to the transmitting Modules (TVCH:INP). 3. Read the DB to get the last written Camac data (TVMD:DATA). 4. Set up an array of the Channels broadcasting the transmitting modules. 5. Write the Module name of the transmitting Module on each Channel button ( or blanks if none ). 6. Write the Input name of the connected Input on each Channel button ( or blanks if none ).

THE CABLE VIDEO SOFTWARE. Page 13-13 7. If no Channel has been selected, then clear any bars on the Channel buttons. 8. Write the broadcasting Channel name on each transmitting module button. 9. If no module has been selected, then clear any bars on the Module buttons, and clear all the Input buttons. 10. If a module has been selected, then :- i. Read the DB to get the transmitter's Input names (TVMD:INPT). ii. Write out the Input names on the Input buttons. iii. Clear the Input buttons of any '*ON*' messages. iv. If no Input has been selected, then clear any bars on the Input buttons. v. If the selected module is currently transmitting, then write '*ON*' onto the connected Input button.

13.2.6 CAVMDBUPD This little routine simply updates a couple of things in the Database. It is called whenever a successful Camac operation has taken place which has turned on or off a transmitter, or whenever it has been deduced that a particular transmitter cannot be transmitting (e.g. if there is no power to a particular Camac crate).

THE CABLE VIDEO SOFTWARE. Page 13-14 1. Write out the current Modules being broadcast on the Channels (TVCH:MODL). 2. Write out the current Inputs connected to transmitting modules (TVCH:INPT).

CHAPTER 14 KLYSTRON SUPPORT

14.1 OVERVIEW *** Not yet written ***

14.2 KLYSTRON TIMING -- HEURISTIC FUDGE FACTORS The trigger system for SLC is dependent of the propagation of triggers from the PDU's to all devices. The trigger is started from a Fiducial on the main drive line, and software applies a correction TREF to the nominal PDUT time such that time=zero is defined such that a PDUT=0 trigger appears coincident with the "TREF" beam (upstairs!) at the beam-position monitor. The logical reference for klystrons, however, is of the RF as observed at the RF input coupler (downstairs!) as the beam passes. There are two independent correction factors designed to allow the operators to become independent of the various sources of apparent time errors. TERR is described in the database, and is the correction for any environmental errors. HERR is known by the PIOP and is the correction for the channel dependent timing errors. The overall goal of the timing is to present FTP's with time axis' which are with respect to the time=0 defined by the beam entering the waveguide.

14.2.1 Delay Calculation The (sample and modulator) trigger associated with each klystron and subbooster starts with a PDU trigger which occurs approximately 8 microseconds prior the beam-time. The PIOP synchronously delays this trigger by 8, and programs the PAD and MKSU to generate sample delays and the modulator trigger with an intrinsic resolution of 67, 34, and 34 nanoseconds. The following equation describes the calculation of the actual (additional) delay the appropriate hardware delay counter must impose in the PAD/MKSU. As usual, this calculation is done in

KLYSTRON SUPPORT Page 14-2 the micro/piop processors. Delay_register = ! Value loaded into register ( Sample/trigger time ! Requested time wrt Input Coupler - ( (PDUT + TERR) ! Effective trigger time to PIOP ! (calculated by the micro) + HERR ) ) ! Trigger generation delays in MKSU/PAD / (4 or 8) ! Hardware countdown rate in MKSU or PAD As a feature to allow a smooth transition to time-invariance, the old calculation will occur if any of the following exist: o The (PDUT + TERR) has a numeric value of '8181'. o The FTP channel number has the '1000' bit off. In these conditions, the delay will be: Delay_register = ! Value loaded into register ( Sample/trigger time )! Requested time / (4 or 8) ! Hardware countdown rate in MKSU or PAD

14.2.1.1 Delay Register The internal delay register in the MKSU and the PAD counts either half or whole cycles of 14.875 MHz (for MKSU's and PAD's). Beam Phase Units (which look like PAD's in many other respects) have been modified to count in half cycles. The 3 delay registers are reloaded by the interrupt handler in the PIOP for the next pulse if the klystron is expected to fire.

14.875 is derived from the 119 MHz through a re-synchronized divide by 8 chip. The countdown starts at the appearance of the PDU trigger and the divider is reset.

14.2.1.2 Sample/Trigger Time The PIOP is informed of the desired trigger or sample time by the micro as part of the normal action associated with database updates or FTP requests. The data is in PDU ticks. The PIOP massages the start time a) by subtracting the HERR hardware error for the selected channel path, b) by adding the PDUT/TERR correction, and c) (for non-zero step-size FTP requests) by forcing the start delay is to be divisible by 8 so that the resultant FTP is not a victim of integer truncation errors, The actual start time and step size are returned by the PIOP for FTP's, with the best estimate (HERR) of the hardware delay added to the start time in the result block.

KLYSTRON SUPPORT Page 14-3

14.2.1.3 PDUT The timing support software uses this database secondary as part of the normal computation of the PDU's delay from the fiducial. The operation of the klystron station is independent of the actual choice of PDUT if the following conditions are met: o The PDUT is sufficiently negative to allow enough trigger time for long-pulse modulators. o The PDUT is sufficiently positive to allow the MKSU to delay the modulator trigger such that the Beam Voltage does not significantly overlap the RF Drive. o Whatever value is also used in the computation of the reuse-type standby trigger.

14.2.1.4 TERR The "TREF" time which is used as the invariant reference aligns the observed beam signal and the PDU outputs (upstairs!). There are three errors (which contribute in the same direction) involved in klystron timing: o The beam passed downstairs one standard BPM cable length ago. o The RF downstairs at the input coupler was started upstairs 60 feet of waveguide ago. o There might be an appreciable cable run between the PIOP and the MKSU. Note that cables are never run directly, but rather on cable trays. All of these factors suggest that the computed PAD/MKSU delay should be shorter than originally predicted. Therefore: TERR is positive. TERR is of order 300 nanoseconds. (40 ticks).

14.2.1.5 HERR The MKSU trigger, MKSU sample, MKSU/PAD sample and PAD-only samples all follow the trigger by different times. Since TERR compensates (in the micro) for cable etc errors, HERR (in the PIOP) must cope with the hardware dependent errors. The values of HERR are measured in a test sector (such as LI31), where the cables are all "short" (ten feet), and there are no waveguide considerations.

KLYSTRON SUPPORT Page 14-4 There are several separate affects which contribute to the HERR. o The sample gate used in the PAD and MKSU each have a "generation time" which is the delay from the upper backplane to the actual sample and hold chip (neglecting cable delays, which are accounted for in TERR). Additionally, the sample networks have a finite (order 100nS) switch opening time. o The actual signal in question is delayed by the amplifier network. o There is a timing repeater delay (32 nS) for the PAD sample gate if there is a MKSU involved. Using a PDU trigger, activate to provide a pre-trigger to the signal source in question, and enter TDES such that the mid-point (50 %) is at coincident with a trigger programmed at the TDES=0 time. The FTP facility is used to observe the pulse, and the 50% point should be at t=zero. If the time observed is negative, HERR for that path should be increased. Values for HERR were measured in March 1986, and were found to be: Signal name Path Leading Trailing Average Amplitude piop/mksu/pad 248. 181. 214 Forward RF piop/mksu 117. 91. 104 Beam Current piop/mksu 168. 168. 168 Beam Voltage * piop/mksu 168. --- Beam Voltage + piop/mksu 134. 134 134 Mod Trigger piop/mksu 246. 246 PAD sample gate piop/mksu/pad 311. (not used) * high voltage test + low voltage test The following values were chosen, and implemented in the PIOP: FTP Flavor Correction ----------- ---------- Amplitude, Phase 25 ticks (22 without MKSU) FE, RE, Drive 12 Beam Voltage 16 Beam Current 20 Trigger ----------- Modulator Trigger 29 ticks

KLYSTRON SUPPORT Page 14-5

14.3 MESSAGE SERVICE PROTOCOL

14.3.1 VAX-VMS To MICRO Message Structure The VAX to Micro message format is of one of the following forms: This form is used for the "Check Status" command only. Primary Unit is ALL* ALL*. Word # Item +-------+----------+ | -10 | MSG | + ... + Service | | -1 | Header | +-------+----------+ The historic form allows a single list item for control. The Primary Unit may contain wild cards. Word # Item +-------+----------+ | -10 | MSG | + ... + Service | | -1 | Header | +-------+----------+ | 0 | | One of the set of +-------+ PRIMARY | 'KLYS', 'SBST', | 1 | | 'DKLY', or 'ALL*' +-------+----------+ | 2 | | ASCII or Numeric values. ie: +-------+ UNIT | ' 21', 21, or 'ALL*' | 3 | | +-------+----------+ | 4 | Function | As required for function +-------+ Specific | code in msg_header for | ... | Data | single unit above +-------+----------+ The "LIST" form of a klystron command. Any number of Primary Unit elements may be supplied, but service for a specific Primary/Unit may only be requested once. Word # Item +-------+----------+ | -10 | MSG | + ... + Service | | -1 | Header | +-------+----------+ | 0 | | +-------+ 'LIST' | Special value | 1 | | +-------+----------+ | 2 | N_ITEMS | Number of Primary/Unit that follow +-------+----------+

14.3.2 MICRO To VAX-VMS Message Structure The Micro to VAX message format is of one of the following two forms: The check status and non-list requests only return a summary status. Fast Time Plot data is returned for a single unit. Word # Item +-------+----------+ | -10 | MSG | + ... + Service | | -1 | Header | +-------+----------+ | 0 | STAT | +-------+ | | 1 | Summary | +-------+----------+ | 2 | Function | As required for the single unit +-------+ Specific | for single unit function request. | ... | Data | +-------+----------+ "LIST" based requests return individual status information as well as an expanded Primary/Unit list. Word # Item +-------+----------+ | -10 | MSG | + ... + Service | | -1 | Header | +-------+----------+ | 0 | STAT | +-------+ |

14.4 KLYSTRON FUNCTION CODES o KLYS_CHCK_STATUS -- Check PIOP's in micro. Two forms are supported, the terse form, which updates only a small set of the digital status information, and a verbose form which updates the entire database. o KLYS_CRATE_RESET, KLYS_CRATE_RESET_Z -- Message from the Crate Watch service of the micro. Function service data is the crate number, and all units in the affected crate are (perhaps) IPL'ed, and always updated with a fresh set of DataBase values. o KLYS_FOXHOME -- Request that the PIOP move the Fox phase shifter until the "pin" is found, and return to the same electrical phase position. DataBase value is updated. o KLYS_FTP -- Do a FTP on the selected unit/units. Function specific command data is:

KLYSTRON SUPPORT Page 14-8 SLEEP -- milli-seconds between polls for data (8 tries max). PIOP_Command -- PIOP_CBLK_FTP. PIOP_Channel -- ie: PIOP_MK2_FTP. FTP_Delay -- Start value for dependent variable. FTP_Step -- Step size for dependent variable. FTP_TSPP -- (PPYY??) TS = 0-35 or 'FF'X for any. PP = 1-254 or 'FF'X for any. Function specific returned data is: FTP_Return -- I*2 success code. FTP_Delay -- Actual Start for dependent variable. FTP_Step -- Step Size for dependent variable. DATA -- 64 I*2 words of data. o KLYS_IPL_START -- IPL the indicated PIOP's, and update with a current copy of DataBase parameters. o KLYS_PTRB_PHASE -- Perturb the phase of the selected units. o KLYS_SEND_IMG -- Message service data field contains the "next" block of the PIOP image. All PIOP's with their IPL pending bit set are loaded following receipt of last block. o KLYS_TRIM_PHASE -- Move the Fox phase shifter of the selected units so that PHAS is within +- PMET/2.0 of PDES. o KLYS_TRIM_SLED -- Send the command to the PIOP to move the SLED needles to the state indicated in the HSTA of the DataBase. o KLYS_UPDATE_PIOP, ...PIOP_PADONLY, ...PIOP_MK2ONLY -- Update both, or one of the buffers of the selected units from the DataBase.

KLYSTRON SUPPORT Page 14-9

14.5 SPECIAL SECRETS OF THE KLYSTRON JOB The KLYS subjob uses a number of special buffers and include files to allow intraprocess communication. Some of the includes contain commons with such common information as the current PRIM/UNIT and friendly constants such as "ALL*" and "KLYS", while others contain information lists used by subroutines which process several units in an ensemble manner.

14.5.1 KLYSDATA.INC Most of the unit specific information, including: o PRIM_NAME, PRIMARY o UNIT, UNIT_NAME o PLOC o STATUS_SUMMARY, LSTATUS_SUMMARY o HSTA o STAT o SWRD o Hollerith Constants: SELF, ALL, KLYS, SBST, DKLY, READ, WRIT, FTPB, CBLK, SBLK, RESP, NONE, LIST

14.5.2 KLYSUNITS.INC Contains list-directed information. Supertype 1, 2, 3, 4, and 5 (5 is micro-only!) data lists, including values updated in KLYSDATA above. o MAX_UNITS, MAX_KLYSTRONS, MAX_SUBBOOSTERS, MAX_DKLYSTRONS. o NUM_UNITS, NUM_KLYSTRONS, NUM_SUBBOOSTERS, NUM_DKLYSTRONS. o KSD_ENTRY -- Entry number for following lists. maintained by SEQUENCER routines. o KSD_PRIMS(MAX_UNITS) o KSD_PRIM_NAME(MAX_UNITS) o KSD_UNITS(MAX_UNITS)

KLYSTRON SUPPORT Page 14-10 o KSD_UNIT_NAME(MAX_UNITS) o KSD_PLOC(MAX_UNITS) o KSD_OLDPDES(MAX_UNITS) o KSD_OLDGOLDMSTR(MAX_UNITS) o KSD_HSTA(MAX_UNITS), o KSD_STAT(MAX_UNITS), o KSD_SWRD(MAX_UNITS)

14.5.3 FUNC2.INC A variety of items required by some of the routines taking special advantage of the features of SEQUENCER. o TRY, TRY_TOTAL -- Indicating how many passes are to be done, and the pass number. Useful in masking errors except on the last pass. o SEQ_STAGE, SEQ_STAGE_TOTAL -- Is this the first part, or the second? Used by the FTP and UPDATING routines. o SEQ_IN_POINTER, SEQ_OUT_POINTER -- Routines which require input or output data use these. The pointers index into this element's data space in: I2_MSGDATA(n) or I4_MSGDATA(m) -- input I2_MMSGDATA(n) or I4_MMSGDATA(m) -- output Where n = SEQ_xxx_POINTER, and m = (n+1)/2. The user of the output data may always assume that the 8 bytes preceding his data area is available for his own use. (for camac status, for example.) Mail buffers are found in MSGMAIL.INC and KLYSMAIL.INC, which are both required, and in that order.

CHAPTER 15 A DEVICE DESCRIPTOR FOR CERTAIN APPLICATION PROGRAMS. Document dated: 13th. June 1985 Author: Julian Kupiec

15.1 INTRODUCTION Some application programs (e.g. The Correlation Plots and Knob Utility) access very different kinds of devices in the control system. The combined set includes database variables, triggered devices, BPM's, Toroids, Analog Status, and the Emittance Measurement software. It is extremely likely that in the future there will be further inclusions. This note suggests a naming method and simple data organisation that will describe all the current devices being used, and hopefully will cater for future additions. Several useful utility routines are also suggested, (most to be extracted from the existing software). When a new device is to be included in one or more applications this will facilitate a minimal number of code additions rather than major code editions. The new code would be added to unique sources (a set of utility routines) rather than to several 'similar but not quite the same' code copies. It will also help in the development of future applications.

15.2 DEVICE TYPES CURRENTLY USED The following is a list of the currently used device types. In the following, all primary names are coded as hollerith data in integer*4 words :- 1. Database devices. 4 Integer*4 words for Prim, Micro, Unit, Secn. Each contains hollerith information, except the Unit, which is coded as a true integer. (The type of database

A DEVICE DESCRIPTOR FOR CERTAIN APPLICATION PROGRAMS. Page 15-2 device is restricted to that which yields a single REAL*4 data type). 2. Triggered devices. 5 Integer*4 words for Prim, Micro, Unit, Secn(=TDES), Beam no. All are holleriths except for Unit and Beam which are true integers. 3. Analog Status devices. 5 Integer*4 words for Prim, Micro, Unit, Secn, Secn2. Unit is a true integer. Secn, Secn2 contain hollerith info. that represents an eight character channel name. 4. Sampled/Step Variables (Correlation Plot only). In addition to all of the above, there are some 'special' primaries for sampled variables. These are ZERO, SAMP and TIME. These are completely defined by their primary name. The primary DTIZ specifies Emittance Measurements using the Video Digitiser EMittance software (VDEM). This sampled variable requires a secondary name that may be up to eight characters long, and coded as holleriths in Secn, Secn2. No Micro or Unit no. is required. There are also sampled variables for BPM's and Toroids:- BPMS, Micro, Unit, Secn (Secn = X, Y or TMIT). TORO, Micro, Unit. (Secn = TMIT). Unit is true integer. There is a step variable which is defined by the Primary KNOB, which indicates that stepping is going to be done with a Multi-device knob file.

15.2.1 Summary The following list summarises how the different device types are named:- Database Devices Prim, Micro, Unit, Secn Triggered Devices Prim, Micro, Unit, Secn(=TDES), Beam Analog Status Devices Prim(=ASTS), Micro, Unit, Secn, Secn2 Special Sampled/Step Variables:- ZERO, TIME, SAMP, KNOB Prim DTIZ Prim(=DTIZ), Secn, Secn2 BPM Prim(=BPMS), Micro, Unit, Secn TORO Prim(=TORO), Micro, Unit, Secn(=TMIT)

A DEVICE DESCRIPTOR FOR CERTAIN APPLICATION PROGRAMS. Page 15-3

15.3 A DATA ORGANISATION TO DESCRIBE THE VARIOUS DEVICE TYPES Unfortunately FORTRAN does not support data structures or records containing mixed data types, only arrays of a given type. The choice of integer*4 as data type is obvious, considering the existing software. Different data types can be accessed by equivalence. The last paragraph indicates a sufficient the length of the array as 5 integer*4 words. Should this increase, the appropriate parameter (AP_DESCSIZE) should be altered, and all software would have to be re-compiled. (This would not happen often). A future problem may be that one large device type requires much more space than any other, resulting in inefficient use of storage. An application could maintain efficient storage by a trade-off. This would involve extra handling and require some form of additional descriptor (perhaps supplied to the utility routines as an optional argument). Considering the current situation and anticipated future needs it seems appropriate to adopt a device descriptor of 5 integer*4 words. The prefix AP_ (Application Program) is conveniently terse. Thus to define a descriptor:- INTEGER*4 AP_DESCSIZE PARAMETER (AP_DESCSIZE = 5) INTEGER*4 AP_DESC(AP_DESCSIZE) The various access indices that are necessary are:- INTEGER*4 (AP_PRIM, AP_MICR, AP_SECN, AP_UNIT, AP_SECN2, AP_BEAM) PARAMETER ( AP_PRIM = 1, AP_MICR = 2, AP_UNIT = 3, AP_SECN = 4, AP_SECN2 = 5, AP_BEAM = 5) Some primaries (ASTS, DTIZ) have 'secondary' names that can be up to eight characters long. The second 4 characters of the secondary name can share the space occupied by a Beam no., as the use is mutually exclusive.

CHAPTER 16 DEVICE ACCESS USING THE DEVICE DESCRIPTOR.

16.1 INTRODUCTION A device descriptor has been suggested, which provides a unified way of naming different types of device. It is a simple fixed- size array. Different index parameters enable different parts of the name to be accessed. The Primary (and Secondary) names determine which indices are to be used. The next step is to use the descriptor in a unified framework to access device control values. There are several pertinent aspects to this.

16.2 CRITERIA 1. It should be as simple as possible and allow for future extensions, but not require major additions to existing code. 2. Certain supplementary data must sometimes be generated, in order to access a device. E.g. The T matrix column for a triggered device. 3. It should be possible to access more than one device per I/O function call. 4. The arrangement should support ways of making access as efficient as possible. The database CLIST is an example of efficient access for more than one device. This implies that all the supplementary data should not be re-generated for each access. 5. The 'updating' of a device control value often consists of several parts:- Changing values in the database, T matrix etc., and also in the corresponding Micro. The whole procedure involved in updating should be considered.

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-2 6. The device control values may have different types. E.g. A T matrix value represented as a real value requires a REAL*8, but typically database variables are REAL*4.

16.3 EVALUATION OF CRITERIA If supplementary data were generated for each access, the routines would have limited application, due to inefficiency. Let this data be called the 'X descriptor' (X-extra). A means of constructing the X descriptor for a device descriptor must be provided, and ideally its inclusion should have as little impact as possible. The X descriptor would only need to be re- generated whenever the contents of its associated device descriptor are modified. It would be convenient to supply several device descriptors per call to an I/O routine. It would seem natural to pass these as a contiguous array to the routine, and indicate the no. of descriptors with an (optional) argument. This obviates the effort and manipulation of any 'list header'. It is worth considering whether lists of X descriptors should be built, then manipulated (like data base CLISTS). Indeed the X descriptor for a database variable, would be its actual CLIST entry. Thus for a list containing only database devices, the list of X descriptors degenerates to a CLIST which can be used with optimal efficiency by DBLGET, and DBLPUT. The problem here is that for mixed device types in a list (as is often the case), it is no longer possible. A set of different lists would be required, and the format of such lists for other devices (e.g. Triggered devices, BPM's) would need specification now. This task is perhaps too onerous for present purposes. It would seem appropriate to have other AP_ utility routines to abstract a CLIST of all database devices in a set of mixed descriptors. The CLIST would be used specifically with DBLGET/DBLPUT. Other device types would be separately treated, using the present routines until future list oriented ones become available. It would be a modular future addition to have routines which generate separate X descriptor lists from a mixed list, and perform the appropriate I/O using each. Updating devices (5) would fit naturally into an arrangement of separate lists, as the operations required are very dependent on device type.

16.4 CONTENTS OF THE X DESCRIPTOR The following list indicates what information should be in the X descriptor for the current device types. The name in brackets, prefixed by X_ e.g. (X_DBPTR), denotes a reference index within the X descriptor:-

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-3 1. Database Devices. 1 integer*4 word containing the database pointer. (X_DBPTR). 2. Triggered Devices. 2 integer*4 words. The T Matrix Column (X_TCOL) and device PCD type (X_PCDTYPE) can both be contained in an integer*4 (by equivalencing with two integer*2 words). Also required is the 'T Matrix offset' (X_TOFF). It is the value of :- TREF + T_NOMINAL + PDUT/PSUT). 3. BPM's/Toroids. 1 integer*4 word for a pointer into the appropriate BPM common block array. (X_BPMINDEX) 4. Analog Status Devices. 2 integer*4 words. A node pointer, and a Sub-block pointer (X_ASTSDBNOD, X_ASTSUBLK) From the above it is evident that two integer*4 words are required by an X descriptor.

16.4.1 Summary The following list summarises the different X descriptor indices for the various device types:- Database Devices X_DBPTR Triggered Devices X_TCOL, X_PCDTYPE, X_TOFF Analog Status Devices X_ASTSDBNOD, X_ASTSUBLK Special Sampled/Step Variables:- ZERO, TIME, SAMP, KNOB None required. (Values derived by the DTIZ None required. Corr. Plot program). BPM X_BPMINDEX TORO X_BPMINDEX

16.5 ALTERNATIVE SOLUTIONS AND RECOMMENDATION For purposes of unifying the current software (Correlation Plots and Multi-device knob utility), a practical yet flexible solution is needed. To accommodate future changes in the addressing mechanism for the X descriptor, it is convenient to have its contents accessed via function calls. The simplest place for the X descriptor is within the device descriptor itself. The advantages in terms of manipulation and simplicity are obvious. The disadvantage is that the amount of reserved storage must always be large enough for the maximum size of X

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-4 descriptor for any device. This does not currently present any problem, but in future if one device type has an inordinately large X descriptor compared to any other, storage inefficiency results. There is another arrangement which at the cost of somewhat increased complexity, overcomes possible storage inefficiency (as always). It has the same advantage as the previous possibility, in that the X descriptor is transparent. In the scheme, the device descriptor has an entry which contains the address of its X descriptor so the latter can always be found from the former. The routine which fills in the X descriptor would also allocate its space efficiently, according to its device type. It would seem logical to adopt the simplest solution (the first). If in future it became unsatisfactory, then only the routines which access the X descriptor would require additional code. (The structure of the device/X descriptors would also need alteration). Application code would remain unaffected.

16.6 DEVICE I/O USING THE DEVICE DESCRIPTOR. As noted above, an I/O routine does not necessarily perform its function for all device types, because it may be meaningless. In cases of misuse the routines return an error. It should be noted that error codes from several facilities can be returned. Three routines will enable basic I/O to be done:- 1. X_SET_DESCR(AP_DEV). This function sets up the X descriptor for the device named in AP_DEV. It returns a status indicating that it could successfully construct the descriptor. 2. AP_DEVGET(AP_DEV, AP_VAL, N_DEVS, AP_ERR). Read device control values for the single or array of devices given in AP_DEV. The corresponding array of values read is passed back in AP_VAL. The last two arguments are optional. N_DEVS indicate the no. of devices supplied in AP_DEV and AP_ERR returns the individual read status for each device. This function returns OP_OKOK if all the individual reads were OK, otherwise the status of the last bad read. 3. AP_DEVPUT(AP_DEV, AP_VAL, N_DEVS, AP_ERR). Write device control values for the single or array of devices given in AP_DEV. The corresponding array of values read is passed back in AP_VAL. The last two arguments are optional. N_DEVS indicate the no. of devices supplied in AP_DEV and AP_ERR returns the individual write status for each device. This function returns OP_OKOK if all the individual writes were OK, otherwise the status of the last bad write.

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-5

16.6.1 Summary The following list indicates the location to which the device control values are read/written. Database Devices The database Triggered Devices The T Matrix Analog Status Devices The database Special Sampled/Step Variables:- ZERO, TIME, SAMP, KNOB Corr. Plot Common block DTIZ Corr. Plot Common block BPM BPM Common Block TORO BPM Common Block

16.7 THE VALUE DESCRIPTOR It should be noted that the AP_VAL argument used with AP_DEVGET and AP_DEVPUT is an array of two integer*4 words for each value. Its contents must be interpreted in different ways according to device type. Database devices values are real*4, but T matrix values require real*8 (to maintain precision in Nsec). BPM data consists of two real*4 words, one for the value, and the other for the error in its measurement. A 'Value descriptor' has been provided (as an include file) to enable application programs to equivalence data correctly from the AP_VAL argument. The contents are shown below:- * VDESC.TXT * * The V descriptor enables applications to interpret the * value parameter used by the AP_DEVGET/AP_DEVPUT routines. * Depending upon the primary name, the value must be * interpreted differently. * For a database value it is a REAL*4 (V_DB) * * Triggered devices are REAL*8 * * Bpm/Toroid values are 2 REAL*4: * Value and Error. (V_BPMVAL, V_BPMERR) * * Here a global array is declared which application programs * can use, to enable different types of data equivalencing. * INTEGER*4 V_DESC(2) REAL*4 V_R4VAL(2) REAL*8 V_R8VAL EQUIVALENCE (V_DESC, V_R4VAL) EQUIVALENCE (V_DESC, V_R8VAL)

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-6 * * Access indices * INTEGER*4 V_DB, V_BPMVAL, V_BPMERR PARAMETER (V_DB = 1, V_BPMVAL = 1, V_BPMERR = 2)

16.7.1 Valid I/O Operations For The Different Device Types. For certain devices, read or write operations are not meaningful. Consideration of the following list will make this fact self-evident:- Database Devices Read/Write Triggered Devices Read/Write Analog Status Devices Read only Special Sampled/Step Variables:- BPM Read only TORO Read only ZERO, TIME, SAMP, DTIZ Read only (Values derived by the Corr. Plot program) KNOB None. (used by the Corr. Plot program) It should be noted in the above that certain primaries (i.e. ZERO, TIME, SAMP, DTIZ, KNOB) are recognised as valid, but for which the I/O routines take no action at all. The reason for this is that they are only meaningful in the context of a particular application (the Correlation Plots) and its environment. It is thus appropriate to cater for them there. They are integrated into the general arrangement because the application can then benefit from the use of the utility routines (mentioned later), for parsing and display, without special handling.

16.8 ASSOCIATED CONSIDERATIONS FOR DEVICE I/O There are two important aspects of device I/O which are not within the scope of the I/O routines themselves:- 1. Ensuring that the most recent device control values are read. 2. Ensuring that the physical device is updated to its control value. When a list of many devices is involved in an acquisition/ control operation, it is not practical to perform the above two tasks on a device by device basis as it would take a long time. What is typically required is that the device list is separated into different

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-7 classes (magnets, klystrons, triggered devices etc.). These classes are then treated separately with their appropriate special handling. It is not within the current scope of support by the AP_ routines to do this. Please refer to the sections 2.2-Criteria, 2.3-Evaluation of criteria and 2.11-Future suggestions. For devices whose control values are contained in the database (database and ASTS devices), these operations have a characteristic form. A 'message sync.' (MSG_SYNC) is made to the appropriate micros with a given function code. This ensures that the database is updated before a read, or the micros are updated after a write. For triggered devices, the AP_ I/O routines access only the T Matrix. For reading, the T Matrix is considered the correct source. After writing to the T Matrix, micros must be updated (e.g. using the AP_TMAT_UPDAT function). The values for BPM's and Toroids are obtained from common block arrays (in BPMSCP.TXT). In order to get a fresh data sample the function BPM_AVG must be called prior to reading the arrays.

16.9 UTILITY ROUTINES The set of utility routines which perform operations using device descriptors are listed below:- 1. AP_DEV_TO_BUT(AP_DESC, BUTTON). A subroutine which writes the name of a device on a button. 2. AP_DEV_TO_STR(AP_DESC). A character function which returns the name of a device in a string. 3. AP_DEVGET(AP_DESC, VALUE). A function which returns the current value of the device. 4. AP_DEVPUT(AP_DESC, VALUE). A function which writes a value to a device. (Other device dependent operations may be required, e.g. to update a micro). 5. X_SET_DESCR(AP_DEV). This function sets up the X descriptor for the given application descriptor. 6. X_GET(AP_DEV, X_INDEX, X_VAL). A function which enables the contents of the X descriptor to be read. Its major use is by the above AP_ routines. 7. X_PUT(AP_DEV, X_INDEX, X_VAL). A function which enables the contents of the X descriptor to be set. Its major use is by the above AP_ routines. 8. AP_PARSE(PARSE_LINE, NEW_DEV, CURR_DEV). A subroutine to parse a line of character text, and construct a device descriptor (NEW_DEV) from it (and where necessary, combine

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-8 parts of an existing name CURR_DEV). It is used in conjunction with an interactive input routine. 9. AP_TMAT_OFFSET(AP_DEV, TMAT_OFFSET). A function which finds the T matrix offset for a triggered device. I.E:- TREF + T_NOMINAL + PDUT(or PSUT). 10. AP_TMAT_UPDAT(AP_DEV). Write the T matrix value defined by AP_DEV to its associated Micro. 11. AP_GET_TMATCOL(AP_DEV, COLUMN). This subroutine finds the T matrix column for the triggered device defined by AP_DEV. 12. AP_GET_PCDTYPE(AP_DEV, PCD_TYPE). A function which finds the PCD type for the triggered device defined by AP_DEV. 13. AP_VFY_TMATVAL(AP_DEV, AP_VAL, TOO_LOW, TOO_HIGH, DEV_DEACT). A function which checks the validity of a value (AP_VAL) for the triggered device AP_DEV. It indicates if the value is below the minimum T matrix value or above the maximum value permissible for this PCD type. (AP_VAL is adjusted appropriately if necessary). It also indicates whether the device is currently de-activated. 14. AP_DBGET(AP_DEV, VALUE). A function which reads a single REAL*4 database device, WITHOUT using the device X descriptor.

16.10 ADDENDUM: SOFTWARE STATUS (JUNE 1985) At present the source code for the software proposed above has been written and incorporated within the Correlation Plots and Multi-device Knob Utility. It is present in SLCSYS and (when appropriate) development versions can be found in [JMK.APP]. The files involved are:- 1. APDESC.RNO: The RUNOFF source for this document. 2. APDESC.TXT: The Definition of the Device and X descriptors, and associated information. 3. APVDEMDEF.TXT: Declarations for the interface to the VDEM software. 4. APPSUPP.FOR: The Main source code for the 'Application Support'. 5. APPARSE.FOR: The source code for the interactive parsing routines.

DEVICE ACCESS USING THE DEVICE DESCRIPTOR. Page 16-9 6. VDESC.TXT: The definition of the Value descriptor.

16.11 SUGGESTIONS FOR FUTURE DEVELOPMENT Briefly, the application support routines would benefit particularly from development in the following respects:- 1. More instructive error code returns (perhaps from an AP_ facility). At present they are either from the OPDEF facility or a facility corresponding to a given device type. 2. A simplified non-interactive version of the parsing routine. It would fill in a device device descriptor from a charcters string containing a device name. 3. Routines to split a list of mixed device types into separate lists each containing devices of a given 'class' (E.g. magnets, klystrons triggered devices etc). The latter may take the form of X descriptors rather than device descriptors, for efficient list-oriented I/O. 4. List-oriented routines to aid in the updating of various micros. E.g. for building micro-lists for use with MSG_SYNC, from a list of devices of a particular class. %RUNOFF-W-COR, Can't open required file "doc$0:poop.rnx" on output page 16-9; on input line 40 of page 1 of file "DOC$:[000000.POOP]POOP.RNO;5"

Contact (until Aug. 15, 1996): Jeffrey Miller
Owner: Bob Sass

Converted from VAX Runoff output using doc2html.pl