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 dat