hardware - DESYhasyweb.desy.de/services/computing/hardware/hardware.pdf · 2020. 2. 4. · 11 Galil DMC Controller, Tango 30 ... 30 Micro-Zugvorrichtung, BW4 100 31 Monochromator,

Hardware

Contents

1 Introduction 10

2 ATVME (AT-VME Interface) 11

3 CAMAC (Kinetic Systems) 12

4 Andor Camera, Lima 13

5 Attribute Motor, Gap, Tango 15

6 Absorber Box (via Beckhoff), Tango 17

7 DC Motor 19

8 DGG, DGG2 (Dual Gate Generator, DESY, Janz) 20

9 Diffractometer, Tango 25

10 FMB-Oxford DCM, PMAC, Tango 26

11 Galil DMC Controller, Tango 30

11.1 online.xml, from P03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

11.2 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

11.3 Hardware reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

11.4 Galil as virtual motor (haspp10e1) . . . . . . . . . . . . . . . . . . . . . . . . . . 36

12 Gpib, Tango 44

13 I404, BPM, Tango 45

13.1 USB Port Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

13.1.1 i404USB.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

13.2 USB: persistent naming for USB-Serial converters . . . . . . . . . . . . . . . . . 53

14 IK220 (Encoder, PCI, Heidenhain) 54

15 IK320 (Encoder, VME, Heidenhain) 56

15.1 Examples from hasfpgm2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

16 IP DIGI 60

17 KETEK 4K MCA 61

1

18 Kohzu, Tango 63

18.1 Kohzu Test Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

19 Lambda, X-Spectrum 68

19.1 Start the Tango Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

19.2 Tango Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

19.3 Image Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

20 LeCroy DSOs 70

21 Large Offset Monochromator, Lom (DESY), Tango 71

21.1 P03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

21.2 P08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

22 LCX Camera, P10 81

23 M663 (Piezo Motor, PI) 84

24 M665 (Piezo Motor, PI) 85

25 MARCCD 86

26 MAR Image Plate Scanner 88

27 Maxipix51 (ESRF) 89

28 MCA 8701, MCA 8715 (DESY, VIPC616, TVME200) 90

29 MDGG8, VME, Wiener 98

30 Micro-Zugvorrichtung, BW4 100

31 Monochromator, Tango 101

32 MultipleMotor 102

33 Mythen 104

34 NIGPIB (PCI-GPIB Interface, National Instruments) 105

35 OMS58, OMS58S (Oregon Micro Systems VME58) 106

35.1 Check-motor-registers, cmr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

36 OMSMAXV (Pro-Dex, Oregon Micro Systems) 111

36.1 OMSMAXV with Encoder, NON-Tango . . . . . . . . . . . . . . . . . . . . . . 112

36.2 Check-motor-registers, cmr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

36.3 Homing, OMSMAXV with Encoder, Tango . . . . . . . . . . . . . . . . . . . . . 116

36.4 Closed loop, OMSMAXV with Encoder, Tango . . . . . . . . . . . . . . . . . . . 118

36.5 Variable Velocity Contouring Feature . . . . . . . . . . . . . . . . . . . . . . . . 119

36.5.1 demoVVC.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

36.5.2 demoVVCwithGraphic.py . . . . . . . . . . . . . . . . . . . . . . . . . . 121

36.6 Error: message sempahore remains 0 . . . . . . . . . . . . . . . . . . . . . . . . . 123

37 PCO4000 Camera 124

38 Perkin Elmer Detector 125

39 Photonic Science Camera, P03 128

40 PIDPC (PI Digital Piezo Controller) 129

41 PIE710, PIE712 (PI Digital Piezo Controller, Tango) 130

41.1 PIE710 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

41.2 PIE712 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

42 Quadpack, Sixpack (Trinamic) 136

43 Pilatus100k, 300k, Tango 137

44 Prosilica Camera 143

45 RGH25F (Encoder, TCP/IP, Renishaw) 144

46 Roper Scientific Quadro 145

47 SDD7 147

48 SF7210 (GPIB) 149

49 SIS1100/3100 PCI - VME Adaptor 150

50 SIS3302 (FADC,MCA) 152

51 SIS3600 (Input Register) 164

51.1 Tango . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

52 SIS3610 (I/O Register) 166

53 SIS3820 (Multi Channel Scaler) 169

54 Slits 173

55 SMCHYDRA ( Tango) 174

56 Slt/Spk PLC, Beckhoff, Tango 175

56.1 Spk, A1 (incl. screen shots) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

56.2 Slt, P01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

56.3 Slt, P02 (incl. screen shots) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

56.4 Slt/Spk, P03 (incl. screen shots) . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

56.5 Spk, P04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

56.6 Slt, P05, P06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

56.7 Slt, P07 (incl. screen shots) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

56.8 Slt, P08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193



56.11 Slt, P11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

57 T95 Linkam Temperature Controller, hasbw5, hasgksspp07eh2a 206

58 Tango, Sardana, Attribute as a Counter 214

59 Tango, AttributeMotor 215

60 Tango, Generic Device 216

61 Tango, Generic Motor 217

62 Tango, Monochromator, BLEnergy 218

63 TcpIpMotorP10 220

64 TIP551-10 (DAC, 16 Bit, 4 Channel, TEWS) 222

65 TIP830-20 (ADC, 16 Bit, 8 Channel, TEWS) 226

66 TIP850-10 (ADC/DAC, 12 Bit, TEWS) 230

66.1 TIP850, Tango . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

67 TwoThetaP07 234

68 Undulator, Tango 237

68.1 Petra3Undulator server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

68.2 Petra3Undulator gap, attribute motor . . . . . . . . . . . . . . . . . . . . . . . . . 237

68.3 Instant TINE Client access to the undulator . . . . . . . . . . . . . . . . . . . . . 238

68.4 A virtual motor to move the gap, obsolete . . . . . . . . . . . . . . . . . . . . . . 238

69 V260 (Scaler, CAEN) 245

70 V462 (Gate Generator, CAEN) 247

71 V513 (CAEN) 248

72 VcExecutor (Tango) 249

73 VDIN96 (Janz) 250

74 VDOT32 (Janz) 251

74.1 VDOT32 Tango . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

75 VDOT96 (Janz) 253

76 VFCADC (DESY, H. Zink) 254

77 VHQ205L 258

78 VHSC005N 259

78.1 BLSC for VHSC005 (online -tki) . . . . . . . . . . . . . . . . . . . . . . . . . . 259

79 VmExecutor (Tango) 262

80 VPAP (ESRF) 263

81 XIA, DXP-XMAP, Tango 264

81.1 ’Live Time’ to FIO Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

List of Figures

5.1 Attribute Motor, create the server . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.2 Properties of an Attribute Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1 Jive: Absorber Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.2 Jive: Absorber Box PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.3 BLSC: Absorber Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8.1 DGG2 V6, total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8.2 DGG2 V6, detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.3 DGG2 V6, detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.4 DGG2 V6, detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.5 DGG2, Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

8.6 DGG2, Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

8.7 DGG2, Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

10.1 FMB, create the Energy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10.2 FMB, create Ctrl server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

10.3 FMB, create ther Motor server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

10.4 Properties of the FMB Energy Server . . . . . . . . . . . . . . . . . . . . . . . . . 27

10.5 Properties of the FMB Ctrl Server . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10.6 Properties of the FMB Motor server . . . . . . . . . . . . . . . . . . . . . . . . . 29

11.1 Jive: Galil-DMC Motor Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

11.2 Jive: Galil-DMC Ctrl Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

11.3 Jive: Galil-DMC Slit Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

11.4 Jive: Galil-DMC Ctrl Server Properties . . . . . . . . . . . . . . . . . . . . . . . 32

11.5 Jive: Galil-DMC Motor Server Properties . . . . . . . . . . . . . . . . . . . . . . 33

11.6 Jive: Galil-DMC Slit Server Properties . . . . . . . . . . . . . . . . . . . . . . . 34

12.1 Properties of a GPIB device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

13.1 Properties of the I404 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

21.1 Lom500, create the PLC server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

21.2 Lom500, create ther Lom server . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

21.3 Properties of the PLC Server for the Lom500, P03 . . . . . . . . . . . . . . . . . . 72

21.4 Properties of the Lom500 Server, P03 . . . . . . . . . . . . . . . . . . . . . . . . 73

21.5 Lom, create the PLC server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

21.6 Lom, create the LomEnergyserver . . . . . . . . . . . . . . . . . . . . . . . . . . 75

21.7 Lom, create ther Lom server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

21.8 Properties of the PLC Server for the Lom, P08 . . . . . . . . . . . . . . . . . . . . 76

21.9 Properties of the Lom Server, P08 . . . . . . . . . . . . . . . . . . . . . . . . . . 77

21.10Properties of the LomEnergy Server, P08 . . . . . . . . . . . . . . . . . . . . . . 78

6

22.1 Jive, LCX, Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

22.2 Jive, LCX Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

28.1 Properties of the MCA8715 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 91

28.2 TVME200-MCA8715, Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

28.3 TVME200-MCA8715, Detail, MCA1-4, A16 Address: 0x7000, A24 Address:

0xd00000, S4 = 3 selecting 128 kB/IP . . . . . . . . . . . . . . . . . . . . . . . . 93

28.4 TVME200-MCA8715, Detail, MCA5-8, A16 Address: 0x7400, A24 Address:

0xd80000, S4 = 3 selecting 128 kB/IP . . . . . . . . . . . . . . . . . . . . . . . . 94

28.5 VIPC616-MCA8715, Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

28.6 VIPC616-MCA8715, Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

28.7 VIPC616-MCA8715, Another Detail . . . . . . . . . . . . . . . . . . . . . . . . . 96

28.8 Canberra 8715 ADC, Cables and Switches . . . . . . . . . . . . . . . . . . . . . . 97

29.1 MDGG8, Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

29.2 MDGG8, Address Selection: 0x100000 (A24), SN1 == 1, others == 0 . . . . . . . 99

29.3 MDGG8, IRQ Selection (not used) . . . . . . . . . . . . . . . . . . . . . . . . . . 99

32.1 Properties of a MulipleMotor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

35.1 OMS VME58 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

35.2 OMS VME58 Controller, MOT1 - MOT8, Base 0xf000 . . . . . . . . . . . . . . . 108

35.3 OMS VME58 Controller, MOT9 - MOT16, Base 0xe000 . . . . . . . . . . . . . . 108

35.4 OMS VME58 Controller, MOT17 - MOT24, Base 0xd000 . . . . . . . . . . . . . 109

35.5 OMS VME58 Controller, MOT25 - MOT32, Base 0xc000 . . . . . . . . . . . . . 109

35.6 OMS VME58 Controller, Limit Switch Polarity Selection for Experiments . . . . . 110

35.7 OMS VME58 Controller, Limit Switch Polarity Selection for Test Setup . . . . . . 110

36.1 OMS MAXV Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

36.2 OMS MAXV, J7 (Ditial I/O), J8 (Stepping mode) . . . . . . . . . . . . . . . . . . 113

36.3 OMS MAXV, MOT1 - MOT8, base: 0x1000000 . . . . . . . . . . . . . . . . . . . 114

36.4 OMS MAXV, MOT9 - MOT16, base: 0x2000000 . . . . . . . . . . . . . . . . . . 115

36.5 OMS MAXV, MOT17 - MOT24, base: 0x3000000 . . . . . . . . . . . . . . . . . 116

38.1 Jive, PerkinElmerCtrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

38.2 Jive, PerkinElmerDetector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

41.1 With wavegenerator, real move time minus calc. move time as a function of slew

rate, 2 - 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

41.2 Without wavegenerator, real move time minus calc. move time as a function of

slew rate, 2 - 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

41.3 The difference setPoint - actPos, with wavegenerator . . . . . . . . . . . . . . . . 133

41.4 With WG, real move time minus calc. move time as a function of slew rate, 0.5 - 20 134

41.5 With WG, real move time minus calc. move time as a function of slew rate, 20 - 1000134

41.6 Without WG, real move time minus calc. move time as a function of slew rate, 20

- 1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

43.1 Jive, Pilatus, Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

43.2 Jive, Pilatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

49.1 SIS3100, Connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

49.2 SIS3100, Disconnected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

50.1 Properties SIS3302Client server . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

50.2 Properties SIS3302 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

50.3 SIS3302: ADCgui Screen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158






52.1 SIS3610, Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

52.2 SIS3610, Base Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

53.1 SIS3820, Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

53.2 SIS3820, Base Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

53.3 SIS3820, Inhibit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

56.1 Spk create server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

56.2 Spk create server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

56.3 Properties of the PLC Server for the Spk, A1 . . . . . . . . . . . . . . . . . . . . 177

56.4 Properties of the Spk Server, A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

56.5 Slt/Spk create server, P02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

56.6 Ads: add class to Spk, P02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

56.7 Properties of the PLC Server for the Slt/Spk, P02 . . . . . . . . . . . . . . . . . . 182

56.8 Properties of the Slt/Spk Server, P02 . . . . . . . . . . . . . . . . . . . . . . . . . 183

56.9 Slt/Spk create server, P03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

56.10Ads: add class to Spk, P03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

56.11Properties of the PLC Server for the Slt/Spk, P03 . . . . . . . . . . . . . . . . . . 185

56.12Properties of the Slt/Spk Server, P03 . . . . . . . . . . . . . . . . . . . . . . . . . 186

56.13Properties of the PLC Server for the Slt, P07 . . . . . . . . . . . . . . . . . . . . . 192

56.14Properties of the Slt Server, P07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

56.15Spk create server, Ads, P09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

56.16Spk create server, Spk, P09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

56.17Spk server properties, Ads class, P09 . . . . . . . . . . . . . . . . . . . . . . . . . 197

56.18Spk server Properties, Spk class, P09 . . . . . . . . . . . . . . . . . . . . . . . . . 198

56.19Slt create server, P10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

56.20Ads: add class to Slt, P10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

56.21Properties of the PLC Server for the Slt, P10 . . . . . . . . . . . . . . . . . . . . . 202

56.22Properties of the Slt Server, P10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

59.1 Jive: The configuration of an AttributeMotor, P07 . . . . . . . . . . . . . . . . . . 215

62.1 Jive: BLEnergy Server Properties at P08 . . . . . . . . . . . . . . . . . . . . . . 219

63.1 Jive: TcpIpMotorP10 Server Properties at P10 . . . . . . . . . . . . . . . . . . . 221

64.1 TVME200 with TIP830 (ADC, right, slot A) and TIP551 (DAC, left, slot C) . . . . 223

64.2 TVME200 with TIP830 (ADC) and TIP551 (DAC), detail . . . . . . . . . . . . . 224

64.3 TIP830 (ADC) vs. TIP551 (DAC) . . . . . . . . . . . . . . . . . . . . . . . . . . 225

65.1 TVME200 with TIP830 (ADC, right, slot A) and TIP551 (DAC, left, slot C) . . . . 228

65.2 TVME200 with TIP830 (ADC) and TIP551 (DAC), detail . . . . . . . . . . . . . 229

66.1 TVME200 - TIP850, Total, Base: 0x800 . . . . . . . . . . . . . . . . . . . . . . . 231

66.2 TVME200 - TIP850, Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

67.1 Jive: Properties of the TwoThetaP07 server . . . . . . . . . . . . . . . . . . . . . 234

67.2 Jive: The attributes the TwoThetaP07 server . . . . . . . . . . . . . . . . . . . . . 235

68.1 Jive: Petra3Undulator properties using TINE path . . . . . . . . . . . . . . . . . . 238

68.2 Jive: Petra3Undulator properties using the direct Ads path . . . . . . . . . . . . . 239

68.3 Jive: PlcUndulator properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

68.4 Jive: PlcUndulator properties, Ads class . . . . . . . . . . . . . . . . . . . . . . . 241

68.5 Jive: TTTGW for the Undulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

68.6 Jive: TTTGW Undulator Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 242

68.7 Jive: AttributeMotor properties, undulator gap . . . . . . . . . . . . . . . . . . . 243

68.8 Undulator, instant TINE Client displays the connection status . . . . . . . . . . . . 243

68.9 Undulator, instant TINE Client displays CDI gap reading . . . . . . . . . . . . . . 244

76.1 VFCADC, total, base: 0x11000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

76.2 VFCADC, detail, base: 0x11000, the rightmost switch is most significant . . . . . 257

78.1 BLSC: VHSC005N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Chapter 1

Introduction

This manual describtes the configuration of the Online hardware.

10

Chapter 2

ATVME (AT-VME Interface)

Connects the ISA bus with the VME bus.

Jumpers on the ISA board: Address 0d I/O 0, J201 open, J111 connected, Interrupts: 15 jumper

right (ISA bus connector is pointing left), 12 and 11 no jumper, 10 jumper left. Don’t forget to

allocate IRQ 15 for this interface in the PC BIOS. J1, J2, J4, J5 open, J3 connected.

Jumpers on the VME board: RM open, SC connected, AM open, T64 connected, T32 and T16

open, connected jumper at IRQ 4 (compare ˜/atvme/driver/atvme.h), SCLK closed also

the unlabel jumper near SCLK, the pattern at BJ0-3: ---<nl>.-...<nl>.-...<nl>.-...

(the VME connectors point to the right, <nl> means: Next line of pins). All other pins are open.

11

Chapter 3

CAMAC (Kinetic Systems)

Connects the ISA bus with the CAMAC bus.

Jumper near R13 to DIS, DR7, DONE: IRQ15, RFS: R=D, switches to 000111 (1 means ON,

encoding 0x38).

12

Chapter 4

Andor Camera, Lima

This is how a Lima version for the Andor camera can be created:

$ git clone git://github.com/esrf-bliss/Lima.git

$ cd Lima

$ git submodule init third-party/Processlib third-party/Sps third-party/libconfig

$ git submodule init third-party/hdf5

$ git submodule init camera/andor

$ git submodule init applications

$ git submodule update

$ cp config.inc_default config.inc

$ emacs /home/user/tango-ds/Lima/config.inc

to set:

...

COMPILE_ANDOR=1

...

COMPILE_TIFF_SAVING=1

COMPILE_HDF5_SAVING=1

$ make config

# emacs /home/user/tango-ds/Lima/camera/andor/src/Makefile

change

-I/usr/local/include

to

-I/usr/include/andor

$ emacs /home/user/tango-ds/Lima/sip/andor/Makefile

change

-I/usr/local/include

to

-I/usr/include/andor

$ make config

$ make

$ make -C sip -j3

13

root> make install

The install dir is set in install.inc.

The server is started by:

#!/bin/bash

export PYTHONPATH=$PYTHONPATH:/home/user/tango-ds/Lima/install

export PYTHONPATH=$PYTHONPATH:/home/user/tango-ds/Lima/install/Lima/lib

export LD_LIBRARY_PATH=/home/user/tango-ds/Lima/install/Lima/lib:$LD_LIBRARY_PATH

printf "Seems that LimaCCD usually sets cooling to ON for Andor at startup\n"

printf "Thus, either Andor should be already in a vacuum environment or\n"

printf "cooling should be switched off via e.g. ATK panel after server startup\n"

printf "\n"

read -t 20 -n 1 -p "Do you want to continue <y/n>? " useranswer

if [ "$useranswer" == "y" ]

then

python /home/user/tango-ds/Lima/applications/tango/python/LimaCCDs.py PETRA-3

else

printf "\n Startup aborted (or incorrect input?) ...\n"

exit 1

fi

Chapter 5

Attribute Motor, Gap, Tango

An Attribute Motor can drive Tango attributes like a motor. In the following it is explained how the

undulator gap is made an attribute motor.

Figure 5.1: Attribute Motor, create the server

This is how an attribute motor is introduced to Online:

<device>

<name>gap</name>

<type>type_tango</type>

<module>motor_tango</module>

<device>p03/attributemotor/gap</device>

<control>tango</control>

<hostname>haspp03:10000</hostname>

</device>

15

Figure 5.2: Properties of an Attribute Motor

Chapter 6

Absorber Box (via Beckhoff), Tango

This is how an absorber box is introduced to Online:

<device>

<name>abs</name>

<type>stepping_motor</type>

<module>absbox</module>

<device>p08/absorber/01</device>


<hostname>hasp08:10000</hostname>

</device>

The following figures display how the Tango server has to be setup.

Figure 6.1: Jive: Absorber Box

17

Figure 6.2: Jive: Absorber Box PLC

The absorber box can be operated by a BLSC widget (6.3) which is generated by the following

lines which are part of /online dir/TkIrc.pl.

$Spc::res_h{ blsc} = "absbox";

$Spc::res_h{ absbox_title} = { text => "Absorber Box"};

$Spc::res_h{ absbox_m1} = { name => "ABS"};

Figure 6.3: BLSC: Absorber Box

Chapter 7

DC Motor

DC motors are a feature that has been implemented for B1. The following lines show how a

motor is defined that is controlled by a DAC (digital-analog-converter) and a ADC (analog-digital-

converter):

def mot41/dev=dc_motor/mod=dc_motor/input="-read_adc(adc1)" \

/output="sdv(dac1)="/before_output="wor(oreg34)=1"\

/after_output="wor(oreg34)=0"\

/limit_min="-5"/limit_max=5/tolerance=0.05/timeout=60

MOT41 can be moved or scanned like any other motor.

The qualifiers before output and after output specify commands that are executed before

amd after the motor is moved.

The qualifiers limit min and limit max specify the limits.

Online waits at most timeout seconds for the motor to reach a position which deviates at most

tolerance units from the setpoint.

19

Chapter 8

DGG, DGG2 (Dual Gate Generator, DESY,

Janz)

Dual gate generator: 2 channel NIM outputs (-0.8V, 50 Ohm), internal clock 1 MHz, 32 bit register,

external clock: TTL input, DGG2: 1 MHz TTL clock output (50 Ohm), can be divided, diver reset

by start timer() call.

VME: A16D16 (DGG)/ A24D16 (DGG2) 2K at 0x1000 (2k aligned). The rotary switches ( VME

connectors point downwards): 0010 (the coding 0x1000). The adress of the second device is

0x1800, the switches (s4, s3, s2, s1) = ( 0, 0, 1, 8).

The jumpers (DGG): J36 1, J34 1, J35 1, J42-39 0101, J24-33 100100, J5-5 11, J8-10 010, J1-3

100, J4 right.

The jumpers (DGG2): J36 1, J34 1, J35 1, J42-39 0101, J24-33 100100, J5-5 11, J8-10 000, J1-3

100, J4 left.

The DGG can be operated in the preset mode with wc(), rc(), wft() and resco()

(NOT resaco()). Spock: ’ascan exp dmy01 0 1 10 -0.123’ to selects 123000 monitor counts.

DGG2: After power-on the yellow LEDs should be active, indicating that the FPGA state is ok.

DGG2 power requirements: 5V.

A DGG2 board is introduced to Online by:

define/dev=timer/mod=dgg2/base=0x1000/vector=0/chan=0 t1

define/dev=timer/mod=dgg2/base=0x1000/vector=0/chan=1 t2

Tango (/online dir/online.xml):

<hw>

... other devices

<device>

<name>exp_t01</name>

<type>timer</type>

<module>dgg2</module>

<device>p09/timer/exp.01</device>


<hostname>haso107tk:10000</hostname>

</device>

<device>

<name>exp_t02</name>

<type>timer</type>

<module>dgg2</module>

<device>p09/timer/exp.02</device>

20



</device>

</hw>

A DGG2 can easily be tested with the SIS3820 counter. The procedure is described in 53.

The following figures show the configuration of the DGG2 VME board.

Figure 8.1: DGG2 V6, total

Figure 8.2: DGG2 V6, detail



Figure 8.5: DGG2, Total

Figure 8.6: DGG2, Detail

Figure 8.7: DGG2, Detail

Chapter 9

Diffractometer, Tango

A E4C diffractometer server is introduced to Online by the following entry on /online dir/online.xml:

</hw>

... other devices

<device>

<name>dffrctmtr</name>

<type>diffractometer</type>

<module>e4c</module>

<device>p09/e4c/diffrac</device>



</device>

</hw>

For E6C diffractometer server we need:

</hw>

... other devices

<device>

<name>dffrctmtr</name>

<type>diffractometer</type>

<module>e6c</module>

<device>p09/e6c/diffrac</device>



</device>

</hw>

Note that the device name dffrctmtr is fixed.

Note also that E6C has two subtypes. They are distinguished by the property DiffractometerType

which can have the values E6C or PETRA3 P09 EH2.

Details about settting up a diffractometer server and using it can be found in the “online -tki”

manual.

25

Chapter 10

FMB-Oxford DCM, PMAC, Tango

The FMB-Oxford monochromator is controlled by the FMBOxfDCMEnergy server.

Figure 10.1: FMB, create the Energy server

Figure 10.2: FMB, create Ctrl server

26

Figure 10.3: FMB, create ther Motor server

Figure 10.4: Properties of the FMB Energy Server

<device>

<name>mnchrmtr</name>

<type>type_ango</type>


<device>p10/dcmener/opt.01</device>



Figure 10.5: Properties of the FMB Ctrl Server

</device>

<device>

<name>dcm_bragg</name>



<device>p10/dcmmotor/opt.01</device>



</device>

<device>

<name>dcm_perp</name>






</device>

<device>

<name>dcm_parallel</name>






Figure 10.6: Properties of the FMB Motor server

</device>

The version property as to be choosen according the the following table:

0 -> old pmac software with old conversion factors

1 -> new pmac software with new conversion factors (haspp08, haspp01oh1,

2 -> new pmac software with old conversion factors (haspp10opt, haspp09)

10 -> DCM: not use pmac energy moves, conversion factors have to be written

11 -> SMB: not use pmac energy moves, conversion factors have to be written

Chapter 11

Galil DMC Controller, Tango

The GalilDMCMotor server has 3 classes:

GalilDMCCtrl Exports the TCP/IP socket connection of the device.

GalilDMCMotor Exports the axes: x, y, z, w. These devices have the attributes SlewRate

and Acceleration. The section 11.1 shows how they are introduced to Online where they can

be changed.

GalilDMCSlit Exports the slit movables: t, b, l, r, cx, cy, dx, dy. They are mapped to the raw

axes in the following way: (x, y, z, w) = ( t, b, l, r), ( cx, cy, dx, dy) = ( (l+r)/2, (t+b)/2, (l-r),

(t-b))

The GalilDMCMotor class has to be introduced first.

Figure 11.1: Jive: Galil-DMC Motor Server

Next the GalilDMCCtrl and GalilDMCSlit classes has to be ’added’.

Below you find the properties.

There is a script n the directory /home/experiment/sbin for creating the corresponding devices:

createGalilSlit.py -b beamline -g galilhost -i instance -l location [-f ]

For example:

30

Figure 11.2: Jive: Galil-DMC Ctrl Server

Figure 11.3: Jive: Galil-DMC Slit Server

createGalilSlit.py -b p03 -g haspgslit05 -i PETRA-3 -l slit4

the ’location’ is the last part of the Tango device name. The command

createGalilSlit.py -h

gives some help.

11.1 online.xml, from P03

The following xml entries demonstrate how the slit G1 is introduced to Online. Note that the Online

names G1X, G1Y, G1Z, G1W point to the motor devices, not the slit devices. They are introduced

because they have the SlewRate and Acceleration attributes which can be changed from Online

(MotorProperties).

Figure 11.4: Jive: Galil-DMC Ctrl Server Properties

<device>

<name>G1X</name>


<module>galil</module>

<device>p03/galildmcmotor/slit3.01</device>



</device>

<device>

<name>G1Y</name>






</device>

<device>

<name>G1Z</name>






Figure 11.5: Jive: Galil-DMC Motor Server Properties

</device>

<device>

<name>G1W</name>






</device>

<device>

<name>G1Top</name>



<device>p03/galildmcslit/slit3.01</device>



</device>

<device>

<name>G1Bottom</name>




Figure 11.6: Jive: Galil-DMC Slit Server Properties



</device>

<device>

<name>G1Left</name>






</device>

<device>

<name>G1Right</name>






</device>

<device>

<name>G1Cx</name>






</device>

<device>

<name>G1Cy</name>






</device>

<device>

<name>G1Dx</name>






</device>

<device>

<name>G1Dy</name>






</device>

11.2 Commands

Here are a few commands that can be used to test the controller. They can be entered in a telnet

session.

AC ?,?,?,? - display acceleration

BN,BP,BV - burn params (e.g.: KI), program, variables

DC ?,?,?,? - display decceleration

EO 0 - echo off

IA 131,169,66,173 - set IP address

KD 0,0,0,0

KI 1,1,1,1

KP 10,10,10,10 - PID parameters

PA ?,?,?,? - queries the commanded positions

PA 1,2,3,4;BG;AM - moves all 4 axes (BG: begin, AM: after move)

RS - power-on reset

SH - servo here

SP ?,?,?,? - display speed

ST - stop

TP X - tell actual x position (x,y,z,w)

The following lines display the log of a small session. The ipAdress and portNo can be found in

the properties of the Tango controller (GalilDMCCtrl class device server).

$ telnet ipAdress portNo

Trying NodeName

Connected to NodeName

Escape character is ’ˆ]’.

:PA ?,?,?,?

0, 0, 0, 0

:SP ?,?,?,?

5000, 5000, 5000, 5000

:PA 10000,10000,10000,10000;BG;AM

:PA ?,?,?,?

10000,10000,10000,10000

:ˆ]

11.3 Hardware reset

The following sequence turned out to be useful after a power-off-on to reset a controller that

couldn’t be operated by a Tango server:

$ telnet ipAdress portNo

Trying NodeName

Connected to NodeName

Escape character is ’ˆ]’.

:RS

:SH

:TE

:TP

:ˆ]

The ipAdress and portNo can be found in the properties of the Tango controller (GalilDMCCtrl

class device server).

11.4 Galil as virtual motor (haspp10e1)

The following script operates the right jaw, file name /online dir/vm1.pl.

#!/usr/bin/perl -w

use Spectra;

my ($method, $value_new) = @ARGV;

my $status = 1;

#

# (x, y, z, w) <-> (r, l, t, b)

#

my $axis = ’r’;

if( "$method" eq "set_position")

{

Spectra::set_dmc( $axis, $value_new);

}

elsif( "$method" eq "get_position")

{

$SYM{RETURN_VALUE} = Spectra::get_dmc( $axis);

}

elsif( "$method" eq "get_limit_min")

{

$SYM{RETURN_VALUE} = -220;

}

elsif( "$method" eq "get_limit_max")

{

$SYM{RETURN_VALUE} = 220;

}

$status;

vm1.pl uses functions that are defined in /online dir/TkIrc.pl:

package Spectra;

#

# open socket for dmc controller

#

my $flag_dmc_open = 0;

my $conv = 10000;

$Spectra::test_var = 1;

sub open_dmc

{

my ($iaddr, $paddr, $proto, $line);

my $remote = ’192.168.57.3’;

my $port = 10000;

$port = getservbyname( $port, ’tcp’) if( $port =˜ /\D/);

die " no port " unless $port;

$iaddr = Socket::inet_aton( $remote) or die "no host $remote";

$paddr = Socket::sockaddr_in( $port, $iaddr);

$proto = getprotobyname( ’tcp’);

socket( SOCKET_DMC, Socket::PF_INET, Socket::SOCK_STREAM, $proto) or

die "socket: $!";

connect( SOCKET_DMC, $paddr) or die "connect: $!";

my $flags = fcntl (SOCKET_DMC, Fcntl::F_GETFL(), 0);

$flags &= ˜Fcntl::O_NONBLOCK();

fcntl ( SOCKET_DMC, Fcntl::F_SETFL(), $flags);

$flag_dmc_open = 1;

}

#

#

#

sub recv_dmc

{

my $status = undef;

if( !$flag_dmc_open)

{

open_dmc();


{

# Util::log( "Failed to open socket for Dmc controller");

Spectra::error( "Failed to open socket for Dmc controller");

goto finish;

}

}

my $rin = my $win = my $ein = "";

vec( $rin, fileno( SOCKET_DMC), 1) = 1;

$ein = $rin | $win;

#

# do we have input, time-out: 0.1s

#

my $nfd = select( $rin, $win, $ein, 0.1);

my $buffer = "";

if( $nfd)

{

sysread( SOCKET_DMC, $buffer, 100, 0);

$status = $buffer;

}

finish:

# Util::display_text( "DMC" , "received $buffer");

return $status;

}

#

#

#

sub send_dmc

{

my ($buffer) = @_;

# Util::display_text( "DMC", "sending $buffer");

syswrite( SOCKET_DMC, $buffer, length($buffer), 0);

}

#

#

#

sub get_dmc

{

my ($axis) = @_;

my $status = undef;


{

open_dmc();


{



goto finish;

}

}

#

# x, y, z, w

#

if( $axis =˜ /ˆx$/i)

{

send_dmc( "TP X\015");

$status = recv_dmc();

$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;

$status = $status/$conv;

}

elsif( $axis =˜ /ˆy$/i)

{

send_dmc( "TP Y\015");


$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;


}

elsif( $axis =˜ /ˆz$/i)

{

send_dmc( "TP Z\015");


$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;


}

elsif( $axis =˜ /ˆw$/i)

{

send_dmc( "TP W\015");


$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;


}

#

# r, l, t, b

#

elsif( $axis =˜ /ˆt$/i)

{

send_dmc( "TP X\015");


$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;


}

elsif( $axis =˜ /ˆb$/i)

{

send_dmc( "TP Y\015");


$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;

$status = $status;


}

elsif( $axis =˜ /ˆl$/i)

{

send_dmc( "TP Z\015");


$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;

$status = $status;


}

elsif( $axis =˜ /ˆr$/i)

{

send_dmc( "TP W\015");


$status =˜ s/ˆ\s*(\S*)\s+:$/$1/;


}

#

# cx, cy, dx, dy

#

elsif( $axis =˜ /ˆcx$/i)

{

my $r = get_dmc( "r");

my $l = get_dmc( "l");

$status = ($r + $l )/2.;

}

elsif( $axis =˜ /ˆcy$/i)

{

my $t = get_dmc( "t");

my $b = get_dmc( "b");

$status = ($t + $b )/2.;

}

elsif( $axis =˜ /ˆdx$/i)

{

my $r = get_dmc( "r");

my $l = get_dmc( "l");

$status = ($l - $r);

}

elsif( $axis =˜ /ˆdy$/i)

{

my $t = get_dmc( "t");

my $b = get_dmc( "b");

$status = ($t - $b);

}

finish:

return $status;

}

sub set_dmc

{

my ($axis, $value_new) = @_;

my $status = 1;

my $buffer = "";

my $value_raw = $value_new*$conv;


{

open_dmc();


{

$status = 1;



goto finish;

}

}

$Spectra::SYM{ interrupt_scan} = 0;

#

# x, y, z, w

#

if( $axis =˜ /ˆx$/i)

{

$buffer = "PA ${value_raw},_PAY,_PAZ,_PAW;BG\015";

}

elsif( $axis =˜ /ˆy$/i)

{

$buffer = "PA _PAX,${value_raw},_PAZ,_PAW;BG\015";

}

elsif( $axis =˜ /ˆz$/i)

{

$buffer = "PA _PAX,_PAY,${value_raw},_PAW;BG\015";

}

elsif( $axis =˜ /ˆw$/i)

{

$buffer = "PA _PAX,_PAY,_PAZ,${value_raw};BG\015";

}

#

# r, l, t, b

#

elsif( $axis =˜ /ˆt$/i)

{

$buffer = "PA ${value_raw},_PAY,_PAZ,_PAW;BG\015";

}

elsif( $axis =˜ /ˆb$/i)

{

$buffer = "PA _PAX,${value_raw},_PAZ,_PAW;BG\015";

}

elsif( $axis =˜ /ˆl$/i)

{

$buffer = "PA _PAX,_PAY,${value_raw},_PAW;BG\015";

}

elsif( $axis =˜ /ˆr$/i)

{

$buffer = "PA _PAX,_PAY,_PAZ,${value_raw};BG\015";

}

#

# cx, cy, dx, dy

#

elsif( $axis =˜ /ˆcx$/i)

{

my $cx_old = get_dmc( "cx");

my $diff = $value_new - $cx_old;

set_dmc( "r", get_dmc( "r") + $diff);

set_dmc( "l", get_dmc( "l") + $diff);

goto finish;

}

elsif( $axis =˜ /ˆcy$/i)

{

my $cy_old = get_dmc( "cy");

my $diff = $value_new - $cy_old;

set_dmc( "t", get_dmc( "t") + $diff);

set_dmc( "b", get_dmc( "b") + $diff);

goto finish;

}

elsif( $axis =˜ /ˆdx$/i)

{

my $dx_old = get_dmc( "dx");

my $diff = $value_new - $dx_old;

set_dmc( "r", get_dmc( "r") - $diff/2.);

set_dmc( "l", get_dmc( "l") + $diff/2.);

goto finish;

}

elsif( $axis =˜ /ˆdy$/i)

{

my $dy_old = get_dmc( "dy");

my $diff = $value_new - $dy_old;

set_dmc( "t", get_dmc( "t") + $diff/2.);

set_dmc( "b", get_dmc( "b") - $diff/2.);

goto finish;

}

send_dmc( $buffer);

while( length( $buffer))

{

$buffer = recv_dmc();

}

my $time = 0;

$buffer = get_dmc( $axis);

while( abs( $buffer - $value_new) > 0.01)

{

if( defined( $Spc::h{ w_top}))

{

Util::refresh_motor_positions();

}

Spectra::wait( 0.5);

$time += 0.5;

last if( $time > 40);

#

# did the user press ’stop’?

#

if( $Spectra::SYM{ interrupt_scan})

{

Util::log( "TkIrc.pl::set_dmc: interrupted, stopping moves");

send_dmc( "ST\015");

while( length( $buffer))

{

$buffer = recv_dmc();

}

last;

}

$buffer = get_dmc( $axis);

}

finish:

return $status;

}

Chapter 12

Gpib, Tango

The following screen shot shows the properties of a GPIP device that has the adress 1.

Figure 12.1: Properties of a GPIB device

44

Chapter 13

I404, BPM, Tango

The I404 electrometer is used for the PETRA III beam position monitors (BPM). We operate the

device usually at a speed of 115200 bd (ASCII, Mode: 3).

The Tango server properties can be found below. In general this server is monitored and operated

from jddd panels. Depending on the beamline these panels are invoked by BPM, BPM1 or BPM2.

Figure 13.1: Properties of the I404 Server

For testing purposes one can connect to a I404 via telnet: telnet hasptsXX 10015. Here are some

commands that can be entered.

I404 Commands

*IDN?

PYRTECHCO,I404-REV0,0000001079,4.1F/14.0.8

45

*rst

reset

calib:gain

calib:gain?

calibrate/query gain for each channel

calib:source 1

set source to channel 1

calib:source 0

set source off

calib:source?

query source status

conf:cap?

conf:cap 0

100 pF capacitor

conf:cap 1

3300 pF capacitor

conf:int

conf:int?

set/query the number of integrations per reading

conf:mon 1

no position calculations

conf:mon 2

quadrant mode calculation

conf:mon 3

split mode calculation

conf:per?

query integration period

conf:range

conf:range?

set/query the full scale current range

conf:read

conf:read?

set/query the number of adc readings that to be taken in each

integration period, 0 - 15

conf:res

conf:res?

set/query the number of bits of effective resulution, 16 - 20

read:curr?

return the last measured current data

read:pos?

perform position calculation and return result, in conf. calc. mode

syst:comm:check 0

disables the appended checksum

13.1 USB Port Attributes

The USB port settings can be inspected by:

$ ls -al /dev/ttyUSB0

$ stty -F /dev/ttyUSB0

short information

$ stty -F /dev/ttyUSB0 -a

full information

$ stty -F /dev/ttyUSB0 -g

produces a string in stty-readable format, which can be used to set the attributes,

$ stty -F /dev/ttyUSB0 400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:

$ stty -F /dev/ttyUSB0 400:5:cbe:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0

Here is the current status of all I404 connected USB ports (3.11.2016):

--- host: haspp03 port: /dev/ttyUSB0

crw-rw-rw- 1 root dialout 188, 0 Nov 3 12:09 /dev/ttyUSB0

speed 115200 baud; line = 0;

-brkint -icrnl -imaxbel

-echo

speed 115200 baud; rows 0; columns 0; line = 0;

intr = ˆC; quit = ˆ\; erase = ˆ?; kill = Û; eof = ˆD; eol = <undef>;

eol2 = <undef>; swtch = <undef>; start = ˆQ; stop = ˆS; susp = ˆZ; rprnt =

werase = ˆW; lnext = ˆV; flush = Ô; min = 1; time = 0;

-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts

-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff

-iuclc -ixany -imaxbel -iutf8

opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0

isig icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt

echoctl echoke

400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

--- host: haspp03bpmhost port: /dev/ttyUSB0




-echo










echoctl echoke

400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

--- host: haspp06mc01 port: /dev/ttyUSB0




-echo










echoctl echoke

400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

--- host: haspp06mono port: /dev/ttyUSB0




-echo










echoctl echoke

400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

--- host: haspp08ohbpm port: /dev/ttyUSB0




-echo










echoctl echoke

400:5:cbe:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0





-echo










echoctl echoke

400:5:cbe:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0





-echo










echoctl echoke

400:5:cbe:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

--- host: haspp08gpib port: /dev/ttyUSB2




-echo










echoctl echoke

400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

--- host: haspp09 port: /dev/ttyUSB0




-echo










echoctl echoke

400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

--- host: haspp10e1 port: /dev/ttyUSB0




-echo










echoctl echoke

400:5:1cb2:8a33:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

13.1.1 i404USB.pl

The following Perl script sets the USB attributes. Before you execute it, make sure that it is talking

to the right device. Furthermore, the script allows you to send and receive messages from the

device. Say ’bye’ if you don’t want it.

#!/usr/bin/perl -w

use strict;

use POSIX qw(:termios_h);

use FileHandle;

# syst:pass 12345

# syst:comm:term 1

# syst:comm:check 0

sub ascii_format

{

my ($argin) = @_;

my $argout = "";

foreach my $i ( 0 .. (length($argin) - 1))

{

my $let = substr( $argin, $i, 1);

my $dec = unpack( "C", $let);

if( $dec < 32)

{

if( $dec == 10){ $argout .= "<LF>";}

elsif( $dec == 13){ $argout .= "<CR>";}

else { $argout .= "<$dec>";}

}

else

{

$argout .= $let;

}

}

return $argout;

}

my $buffer= " " x 200;

my ($nfd);

#

# root> chmod 666 /dev/ttyUSB1

#

sysopen( I404, "/dev/ttyUSB0", O_RDWR) or die ’Failed to open /dev/ttyUSB0’;

my $fd = fileno( I404);

my $term = POSIX::Termios->new;

$term->getattr( $fd);

#$term->setospeed( 4098); # B115200

#$term->setispeed( 4098);

$term->setospeed( &POSIX::B19200); # B19200

$term->setispeed( &POSIX::B19200);

my $lflag = $term->getlflag();

$lflag = $lflag & ˜(&POSIX::ECHO);

$lflag = $lflag | &POSIX::ISIG | &POSIX::ICANON | &POSIX::IEXTEN;

$term->setlflag( $lflag);

my $c_cflag = $term->getcflag();

$term->setcflag( $c_cflag | &POSIX::CS8);

$term->setcc( VMIN, 1);

my $iflag = $term->getiflag();

$iflag = $iflag & ˜(&POSIX::IXOFF);

$iflag = $iflag | &POSIX::ICRNL | &POSIX::IXON;

$term->setiflag( $iflag);

my $oflag = $term->getoflag();

$oflag = $oflag | &POSIX::OPOST;

$term->setoflag( $oflag);

$term->setattr( $fd, &POSIX::TCSANOW);

my $len;

my $argout = "";

print " enter ’bye’ to exit \n";

while()

{

print " Enter> ";

$buffer = <>;

$buffer =˜ s/ˆ\s*(.*?)\s*$/$1/;

goto finish if( $buffer =˜ /bye/i);

if( length( $buffer))

{

$buffer .= "\n";

$len = syswrite( I404, $buffer, length( $buffer), 0);

print " write $len bytes " . ascii_format( $buffer) . "\n";

}

$nfd = 1;

while( $nfd)

{

my $rin = my $win = my $ein = "";

vec( $rin, fileno( I404), 1) = 1;

$ein = $rin | $win;

$nfd = select( $rin, $win, $ein, 1.);

print " nfd $nfd \n";

if( $nfd)

{

$buffer = "";

$len = sysread( I404, $buffer, 100, 0);

print " --- len $len " . ascii_format( $buffer) . "\n";

if( $len)

{

$argout .= $buffer;

}

$buffer =˜ s/ˆ\s*(.*?)\s*$/$1/;

if( $len == 1)

{

last;

}

}

}

}

finish:

close I404;

13.2 USB: persistent naming for USB-Serial converters

In case a BPM is connected to an USB port via a converter, the USBPort property of the device

server has to be set. This can be done in three different ways:

• USBPort can be set to the serial number identifying the converter, e.g.: FTE30LRC

This is the recommended procedure. It is safe as long as a BPM is connected to the same

converter. The Tango server identifies the correct USB port by fetching the serial no. of the

converter connected to the port.

A serial number is determined by, e.g.:

udevadm info -a -n /dev/ttyUSB0 | grep {serial} | head -n 1

• USBPort can be set to a symbolic link pointing to the device file, e.g.: /dev/BPM4.

This method is also safe since it also depends on the serial no. of the converter. However, it

requires that udev rules have been defined that create the sym-links.

• USBPort can be set to the device file, e.g.: /dev/ttyUSB0.

Warning: the order of the USB devices is not predictable. After a converter has been con-

nected, the command dmesg tells you which device has been created. If the BPM has been

repowered or reconnected the USB port has to be checked again.

This is the current configuration of the BPMs which are connected via USB:

haspp03: I404/EXP, p03/i404/exp.01, USBPort: [’/dev/ttyUSB0’] FTE30LRC

haspp03bpmhost: I404/OH, p03/i404/mono.01, USBPort: [’/dev/ttyUSB0’] FTXYEBXN

haspp06mc01: I404/MICRO, p06/i404/micro.01, USBPort: [’/dev/ttyUSB0’] FTUJ0VI3

haspp06mono: I404/MONO, p06/i404/mono.01, USBPort: [’/dev/ttyUSB0’] FTU7MSFU

haspp08ohbpm: I404/BPM1, p08/i404/exp.01, USBPort: [’/dev/ttyUSB0’] FTYRYR61

haspp08ohbpm: I404/BPM2, p08/i404/exp.02, USBPort: [’/dev/ttyUSB1’] FTYRYSZW

haspp08ohbpm: I404/BPM3, p08/i404/exp.03, USBPort: [’/dev/ttyUSB2’] FTYRTDLD

haspp08gpib: I404/BPM4, p08/i404/exp.04, USBPort: [’/dev/ttyUSB1’] FTYRYSSJ

haspp09: I404/BPM-EH1, p09/i404/exp.01, USBPort: [’/dev/ttyUSB0’] FTUJ3YG2

haspp10e1: I404/P10E1, p10/i404/e1.01, USBPort: [’/dev/ttyUSB0’] FTXYEJXJ

Chapter 14

IK220 (Encoder, PCI, Heidenhain)

The IK220 PCI card of Heidenhain is introduced by:

def hhe1/module=ik220/base=0xffffff/vector=0/chan=0

def hhe2/module=ik220/base=0xffffff/vector=0/chan=1

The encoder() function operates the IK220 card:

* = encoder( hhe9, position)

* = encoder( hhe9) position

* = encoder( hhe9, StaPort) status register

* = encoder( hhe9, CancelRef) cancel ref. sequence

* = encoder( hhe9, DoRef) start reference sequence

* = encoder( hhe9, Init) init encoder

* = encoder( hhe9, offset, ival) set offset [counts]

* = encoder( hhe9, conversion, xval) set conversion factor

* = encoder( hhe9, offset) get offset

* = encoder( hhe9, conversion) get conversion

* = encoder( hhe9, p1) 0 increment

1 EnDat

2 SSI

* = encoder( hhe9, p2) 0 11 muApp

1 1Vpp

* = encoder( hhe9, p3) 0 linear axis

1 rotational axis

* = encoder( hhe9, p4) 0 positive

1 negative

The position is calculated by: pos = (encoder - offset)/conversion

A start sequence:

* = encoder( hhe9, p2, 0) sets the card to current mode

* = encoder( hhe9, init)

* = hex(encoder( hhe9, staport)) -> 0x20

* = encoder( hhe9)

54

A reference sequence:

!

! move near the reference mark

!

move mot1 0

* = encoder( hhe9, init)


* = encoder( hhe9, doref)


!

! move over the reference mark

!

move mot1 1

* = hex(encoder( hhe9, staport)) -> 0xffffc024

* = encoder( hhe9, position) -> some value

An encoder is calibrated in the following way (assume the encoder reads the monochromator rota-

tion axis):

• The monochromator is calibrated. This defines the stepping motor position of the rotational

axis. The calibration of the monochromator should be done the near energy that is later used

for the measurements.

• The encoder is initialized and its conversion factor is set to 1 and the offset is set to 0.

* = encoder( hhe1, conversion, 1)

* = encoder( hhe1, offset, 0)

This makes sense only if the encoder is used for the first time. Once the conversion factor is

determined, we don’t have to re-measure it.

• We scan the stepping motor and display the encoder reading.

• A linear fit to the data of the encoder reading gives the conversion factor and the offset. We

use these values for the encoder:

* = encoder( hhe1, conversion, conv)

* = encoder( hhe1, offset, offs)

Chapter 15

IK320 (Encoder, VME, Heidenhain)

Position encoders, 2 channels/board. 1. Board: HHE1, HHE2, 0xe04000. VME base A24D8 16k

at 0xe00000, VME group A16d8 4k at 0x4000, vector 65. Jumper J1 0001000 (IRQ4), J2 0001000

(IACK4), J3 open. RORA interrupter. Shift register S1 10000010, S2 00000001 (’1’ means ’off’

or downwards, if the VME connectors are pointing upwards). 2. Board: HHE7, HHE8, 0xdf6000,

S1 10000110, S2 00111110.

The module is initialized with:

ONLINE> * = gp( hhe1, 1)

This function call invokes a full screen menu.

A IK320 board can be introduced to Online by:

define/dev=hhe/mod=ik320/base=0xc04001/vector=65/chan=0 hhe1

define/dev=hhe/mod=ik320/base=0xc04001/vector=65/chan=1 hhe2

The hasvuvpgm configuration:

HHE1, HHE2:

Basis 0xc00000, Gruppenadr. 0x4000, Vector 65

SI = 0x41, SII = 0x0

12345678 12345678

S1 = duuuuudu, S2 = uuuuuuuu, J1 = 0001000, J2 = 0001000, J3 = 1???

u == up == on == oben (VME Stecker oben, S1 left, J1 oben)

HHE3, HHE4


SI = 0x42, SII = 0x4

S1 = uduuuudu, S2 = uuduuuuu

HHE5, HHE6


SI = 0x43, SII = 0x8

S1 = dduuuudu, S2 = uuuduuuu

HHE7, HHE8


SI = 0x44, SII = 0xc

S1 = uuduuudu, S2 = uudduuuu

define/dev=HHE/mod=IK320/base=0xc04001/vector=65/chan=0 HHE1


56







POST Interrupts, e.g. HHE7:

nach power-on

* = gp(hhe7)

vmeput:A24D16 2 B (7) to 0xc30100

vmeput:A16D8 1 B (0) to 0x4008

(0x40 0x29): [[y

IK320_INT_SERVICE: Default case 0x29

vmeput:A24D16 2 B (0) to 0xc30018

vmeget:A24D8 1 B (0) from 0xc30006

oder HHE1 (standard):

vmeput:A24D16 2 B (7) to 0xe00100

vmeput:A16D8 1 B (0) to 0x4002

vmeget:A24D16 2 B (700) from 0xe00018

Interrupt no. 6 vector 65 irq 4

(0x7 0x0): POST, ok

IK320_INT_SERVICE: POST reply

vmeput:A24D16 2 B (0) to 0xe00018

15.1 Examples from hasfpgm2

[vuvfuser@hasfpgm2:online$ more ref_mono_mirror.pl

#!/usr/local/bin perl -

#

# The encoders HHE5-8 watch MOT6.

# The reference point is somewhere between 16 and 17

# Operation: each axis is ’started’ and then moved

# over the reference point.

#

# Usage:

#

# ONLINE> perl ref_mono_mirror.pl

#

use strict;

use Spectra;

my $ret;

Move( mot6 => "17");

#

# POST (power-on self test) for both HH cards

#

$ret = Get_position( "hhe5", 6);


foreach my $enc (qw /hhe5 hhe6 hhe7 hhe8/)

{

#

# ’start’

#

$ret = Get_position( "$enc", 2);

#

# move over reference point

#

Move( mot6 => "16.0");

Move( mot6 => "17.0");

}

Cls();

print "\n\n\n";


{

print " $enc is at " . Get_position( "$enc") . "\n";

}

----------

[vuvfuser@hasfpgm2:online$ more ref_mono_grating.pl

#!/usr/local/bin perl -

#

# The encoders HHE5-8 watch MOT7.

# The reference point is somewhere between 47 and 48

# Operation: each axis is ’started’ and then moved

# over the reference point.

#

# Usage:

#

# ONLINE> perl ref_mono_grating.pl

#

use strict;

use Spectra;

my $ret;

Move( mot7 => "48");

#

# POST (power-on self test) for both HH cards

#




{

#

# ’start’

#

$ret = Get_position( "$enc", 2);

#

# move over reference point

#

Move( mot7 => "47.0");

Move( mot7 => "48.0");

}

Cls();

print "\n\n\n";


{

print " $enc is at " . Get_position( "$enc") . "\n";

}

Chapter 16

IP DIGI

Input Register: 24 bits. VME: A16D16, 64B at 0x6000, IREG33.

define/dev=input_register/mod=vdot32/base=0x6000/vector=0/chan=0 ireg33

60

Chapter 17

KETEK 4K MCA

The KETEK 4K MCA is connected via USB. It is defined in /online_dir/exp_ini.exp

by:

define/device=mca/module=ketek_4k/control=tango \

/hostname=hasbw1dif/devicename="bw4/exp/mca1" mca1

The KETEK 4K MCA is accessed via a Tango server. The following commands are implemented:

Clear Clears the MCA and the attributes for the total time and the dead time.

Start Creates a thread that continuously (0.1s) reads the MCA and writes the data into a buffer.

Stop Notifies the thread to exit.

Read Reads the MCA spectrum, 4096 channels, 16 bits each. The dead time and the total time are

calculated using the first 4 words:

attr_DeadTime += ((double)((0x3ff & spectrum[1]) << 16) + spectrum[0])/25000000.;

attr_TotalTime += ((double)((0x3ff & spectrum[3]) << 16) + spectrum[2])/25000000.;

attr_LiveTime = attr_TotalTime - attr_DeadTime;

The following attributes are implemented:

DAC0 Temperatur control, 0 - 0xff, n.a.

DAC1 LLD, unsigned short, 0 - 0xfff, 0 2.5V, 12b, def. 0x96, can be set with jive.

DAC2 ULD, unsigned short, 0 - 0xfff, 0 2.5V, 12b, def. 0xfff, can be set with jive.

DAC3 D T, unsigned short, 0 - 0xfff, 0 2.5V, 12b, def. LLD, can be set with jive.

DeadTime float

LiveTime float

TotalTime float

If this device is used by online -tki the total time and the dead time are stored in the parameter

block of the output file.

The USB interface needs the following configuration (kernel at least 2.6.xxx):

61

$ stty -F /dev/ttyUSB0 -a



eol2 = <undef>; start = ˆQ; stop = ˆS; susp = ˆZ; rprnt = ˆR; werase = ˆW;

lnext = ˆV; flush = Ô; min = 1; time = 0;

-parenb -parodd cs8 -hupcl -cstopb -cread clocal -crtscts

ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff

-iuclc -ixany -imaxbel


-isig -icanon -iexten -echo echoe -echok -echonl -noflsh -xcase -tostop

-echoprt -echoctl -echoke

Chapter 18

Kohzu, Tango

The P08 diffractometer is controlled by Kohzu motors via GPIB.

diff.01 Yt

diff.02 Zt1

diff.03 Zt2

diff.04 Zt3

diff.05 Xc

diff.06 Yc

diff.07 Zc

diff.08 PHIc

diff.09 OMh

diff.10 Tth

diff.11 OMa

diff.12 TTa

diff.13 OM

diff.14 TT

diff.15 CHI

diff.16 PHIS

diff.17 Xs

diff.18 Ys

diff.19 Zs

diff.20 CHIs

<device>

<name>diff1</name>


<module>kohzu</module>

<device>p08/motor/diff.01</device>



</device>

<device>

<name>diff2</name>






63

</device>

<device>

<name>diff3</name>






</device>

<device>

<name>diff4</name>






</device>

<device>

<name>diff5</name>






</device>

<device>

<name>diff6</name>






</device>

<device>

<name>diff7</name>






</device>

<device>

<name>diff8</name>






</device>

<device>

<name>diff9</name>






</device>

<device>

<name>diff10</name>






</device>

<device>

<name>diff11</name>






</device>

<device>

<name>diff12</name>






</device>

<device>

<name>diff13</name>






</device>

<device>

<name>diff14</name>






</device>

<device>

<name>diff15</name>






</device>

<device>

<name>diff16</name>






</device>

<device>

<name>diff17</name>






</device>

<device>

<name>diff18</name>






</device>

<device>

<name>diff19</name>






</device>

<device>

<name>diff20</name>






</device>

18.1 Kohzu Test Script

The following script can be used to test the Kohzu server:

#!/bin/env perl

#

# test program for Kohzu motors, haspp08

#

use Spectra;

while(1)

{

if( !Spectra::move( phic => 0,

xc => 0,

yc => 0,

zc => 0))

{

goto finish;

}

if( !Spectra::move( phic => 1,

xc => 1,

yc => 1,

zc => 1))

{

goto finish;

}

#

# spacebar terminates the loop

#

if( Spectra::key() == 32)

{

goto finish;

}

}

finish:

;

Chapter 19

Lambda, X-Spectrum

A Lambda detector appears in online.xml like this:

<device>

<name>lmbd</name>

<type>DETECTOR</type>

<module>lambda</module>

<device>petra3/lambda/01</device>


<hostname>haslambda01:10000</hostname>

</device>

Note: This hostname, haslambda01, referes to one of the loan pool detectors.

Note: The detector name, lmbd, avoids any conflict with the wavelength.

19.1 Start the Tango Server

The Tango server runs on the Lambda detector PC:

• Login to the detector PC using a beamline account:

ssh pXXuser@haslambda01

• As a fallback, there is the user lambda:

ssh lambda@haslambda01

• The Tango server is started from a script:

startlambda.sh

This script can be found in /usr/local/bin

68

19.2 Tango Server Configuration

Sardana: in order to store files using our default path conventions, the attributes FileStartNum,

SaveFilePath and FilePrefix should be set by a pre scan hook. See the Spock manual for an example

( Scans-Hooks-GeneralHooks-ExampleForA...).

Important Tango server attributes:

• ShutterTime: time per image in msecs, 1000

• FrameNumbers: no. of images to take, 1

• EnergyThreshold, unit: eV, half the beam energy

• SaveFilePath: the directory where the data are stored, set by the pre scan hook.

• FilePrefix: set by the pre scan hook.

• SaveAllImages: True to enable image saving

• OperatingMode:

– ContinuousReadWrite: 12 bit counter depth, no time gap between images

– TwentyFourBit: 24 bit counter depth, 1ms delay between images

• TriggerMode

– 0: no trigger

– 1: trigger starts image series

– 2: trigger starts a single image

19.3 Image Viewer

To view the Lambda images:

taurusimage haslambda01:10000/petra3/lambda/01/LiveLastImageData

Chapter 20

LeCroy DSOs

The digital sampling oszilloscopes are introduced to Online by:

define/dev=dso/mod=lc424/host=hasvuvosz2m/port=1861 dso1

define/dev=dso/mod=lc584/gpib=7 dso2

70

Chapter 21

Large Offset Monochromator, Lom (DESY),

Tango

21.1 P03

The large offset monochromator at P03 is controlled by the Lom500Energy server. This section

shows only those settings that differ from P08. Inspect the P08 section 21.2 for a more complete

description.

Figure 21.1: Lom500, create the PLC server

After the server has been configured properly, the devices are introduced to Online (/online dir/online.xml).



71

Figure 21.2: Lom500, create ther Lom server

Figure 21.3: Properties of the PLC Server for the Lom500, P03

<device>

<name>lom1pitch</name>


<module>lom</module>

<device>p03/lom/exp.01</device>


Figure 21.4: Properties of the Lom500 Server, P03


</device>

<device>

<name>lom1roll</name>






</device>

<device>







</device>

<device>

<name>lom2lat</name>






</device>

<device>

<name>lom2hub</name>






</device>

<device>

<name>lom1hub</name>






</device>

<device>

<name>lom2lin</name>






</device>

<device>

<name>lomscrn</name>






</device>

21.2 P08

The large offset monochromator at P08 is controlled by the Lom server which consists of three

classes: Ads, Lom and LomEnergy. The Ads class connects to the PLC. The Lom class represents

single axes and speaks to Ads. The LomEnergy class talks to the Lom class. The axes names are

hard-coded in the LomEnergy class.

After the server has been configured properly, the devices are introduced to Online (/online dir/online.xml).

<device>

<name>energylom</name>





Figure 21.5: Lom, create the PLC server

Figure 21.6: Lom, create the LomEnergyserver


</device>

<device>







</device>

<device>




Figure 21.7: Lom, create ther Lom server

Figure 21.8: Properties of the PLC Server for the Lom, P08




</device>

<device>


Figure 21.9: Properties of the Lom Server, P08






</device>

<device>







</device>

<device>







</device>

<device>


Figure 21.10: Properties of the LomEnergy Server, P08






</device>

<device>

<name>lomfoil</name>






</device>

<device>

<name>lomrtclhgt</name>






</device>

<device>

<name>lomrtcllat</name>






</device>

<device>

<name>lom1tblhght</name>






</device>

<device>

<name>lom1tblrll</name>






</device>

<device>

<name>lom1tblpitch</name>






</device>

<device>

<name>lom2tblhght</name>






</device>

<device>

<name>lom2tblrll</name>






</device>

<device>

<name>lom2tblpitch</name>






</device>

Chapter 22

LCX Camera, P10

The Tango Server for the LCX Camera connects via socket interface to a perl Server talking to the

camera. Steps before starting the Tango Server:

• Start a sesion in the windows PC connected to the camera (haso052lcx) for the user lcxuser.

Using rdesktop:

rdesktop -a 16 -g 90% haso052lcx

• Start the windows program talking to the camera:

C:\Program Files\PI Acton\WinView\Winview.exe

• Start the perl server (in a terminal with the perl prompt):

Directory D:\Perl

perl> perl lcx_xpcs_server.pl

• Start the Tango Server in the Linux computer where it has been installed.

A LCX camera is introduced to Online by the following entry in /online dir/online.xml:

<hw>

...

<device>

<name>lcx</name>


<module>module_tango</module>

<device>p10/pscamera/e2.01</device>


<hostname>haspp10e2:10000</hostname>

</device>

...

</hw>

Here is the Tango configuration of the controller and the camera.

Note that the online -tki manual shows how parameters of this camera can be set by a beamline-

specific-code widget.

The camera can be operated as a virtual counter:

81

Figure 22.1: Jive, LCX, Controller

if( $method =˜ /reset/i)

{

return Spectra::lcxStart( "lcx", $Spectra::SYM{ scan_name},

$Spectra::SYM{ sample_time},

$Spectra::SYM{ sindex});

}

if( $method =˜ /read/i)

{

while( Spectra::tng_state( "lcx"))

{

Util::log( "waiting for the LCX camera");


}

return 1;

}

Figure 22.2: Jive, LCX Camera

Chapter 23

M663 (Piezo Motor, PI)

If the M663 motors are connected via an USB adaptor, we define:

define /device=piezo_motor/module=m663/ifc="/dev/ttyUSB7"/chan=1 mot41



If a M663 is connected via TCP/IP, we say:

define /device=piezo_motor/module=m663/host=hasbw4piezo/port=8105 mot60




A M663 motor is operated as follows:

• The conversion factor can be set to +1 or -1. If it is set, Online ensures that the motor direction

matches the sign of the conversion factor.

• If the motor is accessed for the first time in an Online session, it is ensured that the direction

reflects the sign of the conversion factor.

• If the conversion factor is set, the motor does a reference move which ends at 0. At this point

the calibration can be resetted: ’cali/unit=0 mot60’.

• A calibrate command defines an offset: motor position = encpos + cal offset. ’encpos’ is the

encoder position.

• The limits cannot be changed.

84

Chapter 24

M665 (Piezo Motor, PI)

If the M665 motors are connected via an USB adaptor, we define:




85

Chapter 25

MARCCD

The MAR CCD can be operated as a virtual counter (online -tki). The contributions of Martin Dom-

mach (Perl, client programming) and Edgar Weckert (implementing the state history) are aknowl-

edged.


{

Spectra::marccd_abort();

return 0 if( !Spectra::marccd_start());

return Spectra::marccd_open_shutter();

}


{

return 0 if( !Spectra::marccd_close_shutter());

return 0 if( !Spectra::marccd_readout());

return 0 if( !Spectra::marccd_correct());

my $fname = $Spectra::SYM{ scan_name} . "_" . $Spectra::SYM{ sindex};

return Spectra::marccd_writefile( $fname);

}

Online decodes the symbol MARCCD_HOST when it opens the connection on port 2002. Imme-

diately after the open Online sends the string abort\012 to ensure that the CCD is in a known

state.

To operate the MarCCD the server has to be started:

/home/marccd/bin/linux/marccd

It is important to take a background image first. Otherwise the correct() function causes a program

crash. The remote control is enabled by ’Acquire’ - ’Remote’ - ’Start’.

Note that the chapter ’Beamline specific code’ in Online -Tki manual contains an example that

demonstrates how the MAR-CCD can be operated by a widget.

Here is a list of available functions:

Spectra::marccd_abort()

sends "abort\012"

Spectra::marccd_get_state()

86

sends "get_state\012"

returns (depending on the version):

IDLE 0

ACQUIRE 1

READOUT 2

CORRECT 3

WRITING 4

ABORTING 5

UNAVAILABLE 6

ERROR 7

BUSY 8

Spectra::marccd_wait_for_state()

waits for a specified state,

e.g. marccd_wait_for_state( "40") means state was WRITING, now IDLE

Spectra::marccd_start()

sends "Start\012" and waits for state "81"

Spectra::marccd_readout()

sends "readout,0\012", sleeps 2s and waits for state "20"

Spectra::marccd_readout_bg()


Spectra::marccd_readout_mr()


Spectra::marccd_correct()

sends "correct\012" and waits for state "30"

Spectra::marccd_writefile( "fname")

sends "writefile,${fname},1\012" and waits for state "40"

Chapter 26

MAR Image Plate Scanner

The Online manual explains how to operate a MAR image plate scanner.

88

Chapter 27

Maxipix51 (ESRF)

A Maxipix51 detector is introduced to Online by the following entry in /online dir/online.xml:

<hw>

...



<device>

<name>max51ccd</name>



<device>desy/limaccd/mpx1</device>


<hostname>mpxdesy1:20000</hostname>

</device>

<device>

<name>max51dev</name>



<device>desy/limampx/mpx1</device>


<hostname>mpxdesy1:20000</hostname>

</device>



...

</hw>

The first implementation of the device was done at P10. It can be operated as a virtual counter and

via a BLSC widget. The code is still very preliminary. It can be found in haspp10e2:/online dir/TkIrc.pl.

89

Chapter 28

MCA 8701, MCA 8715 (DESY, VIPC616,

TVME200)

The MCA 8715 is a histogramming module for the 8715/8701 ADCs of Canberra. It has been

developed at Desy (FEA). Each card has 2 memory banks. Up to 4 cards can be mounted on a

carrier board. At Hasylab the TVME200 card of Janz and the VIPC616 of Greenspring are used.

TVME200-10 configuration for MCA1-4, see figures 28 and 28:

S1 = 7, S2 = 0 (A16 base: 0x7000), S2 can be 0, 4, 8, C only, S4: S4 = 0 - disables A24/A32

memory, S4 = 1 - selects 128 kB of A24 memory, 32 kB/IP, S4 = 2 - selects 256 kB of A24

memory, 64 kB/IP, S4 = 3 - selects 512 kB of A24 memory, 128 kB/IP, S4 = 4 - selects 1 MB kB of

A24 memory, 256 kB/IP, we select S4 = 3, S5, S6: A24/A32 base address, def: 0xd00000 (A24),

0x00000000 (A32), S5: A[23:20], S6: A[19:16] for A24, S5: A[31:28], S6: A[27:24] for A32,

memory must be boundary aligned with S4.

A second card (MCA5-MCA8) has A16 base: 0x7400 and A24 base 0xd80000 ( figure: 28).

The TVME200 power requirements are: 300mA at 5V, 1 mA at +12V, 1mA at -12V.

VIPC616, see figures 28, 28, 28: A16D16 1k at 0x7000 base (every piggy back uses 256B), VME

A24D16 base2 0xd00000. Jumpers: E3.7-E7.7 1000111 (from left to right, VME connectors point

downwards), A24, E20.8-E21.8 00101110 (A23-A17,NC), the other jumpers remain in the default

position.

VIPC616 power requirements: 0 mA at 12V, 0 mA at -12V, 610 mA at 5V.

The second MCA board (MCA5 - MCA8) has these settings (base 0x7400, base2 0xd80000): E3.7-

E7.7 1000101 (from left to right, VME connectors point downwards), A24, E20.8-E21.8 00100110

(A23-A17,NC).

Figures 28 and the following show the jumper settings for a VIPC616 board carrying a MCA8715

card.

Canberra 8715 ADC operation: The timer (V462 or DGG2) signal is converted to TTL (N89), then

plugged into the gate input of the ADC together with a 50 Ohm resistor. The switch settings of the

ADC can be found in figure 28.8. Be sure to use 8192 also in the software.

MCAs are introduced to Online by:

define/dev=mca/mod=mca_8701/base=0x7000/base2=0xd00000/vector=0/chan=0 mca1








90


<hw>

... other devices

<device>

<name>exp_mca01</name>

<type>mca</type>

<module>mca_8701</module>

<device>p09/mca/exp.01</device>



</device>

</hw>

Figure 28.1: Properties of the MCA8715 Server

Figure 28.2: TVME200-MCA8715, Total

Figure 28.3: TVME200-MCA8715, Detail, MCA1-4, A16 Address: 0x7000, A24 Address: 0xd00000, S4 =

3 selecting 128 kB/IP

Figure 28.4: TVME200-MCA8715, Detail, MCA5-8, A16 Address: 0x7400, A24 Address: 0xd80000, S4 =

3 selecting 128 kB/IP

Figure 28.5: VIPC616-MCA8715, Total

Figure 28.6: VIPC616-MCA8715, Detail

Figure 28.7: VIPC616-MCA8715, Another Detail

Figure 28.8: Canberra 8715 ADC, Cables and Switches

Chapter 29

MDGG8, VME, Wiener

The MDGG8 VME module is a multi-purpose device which we operate as a 2-channel gate gen-

erator in timing and preset mode. O8 delivers NIM pulses with a frequency of 1 MHz, after the

Tango server has started.

The gates are delivered on O1 and O2 (NIM). Preset counts have to be fed into I1 and I2 (NIM).

VME: A24D32, base adress is 0x100000 (as shipped), Tango Property Base: 1048576), address

encoding (A23-SN4, A22-SN3, ..., A19 - SN0, A18 == 0, A17 == 0, A16 == 0). An inserted

jumper selects 1.

Figure 29.1: MDGG8, Overview

98

Figure 29.2: MDGG8, Address Selection: 0x100000 (A24), SN1 == 1, others == 0

Figure 29.3: MDGG8, IRQ Selection (not used)

Chapter 30

Micro-Zugvorrichtung, BW4

The interface to the Micro-Zugvorrichtung (IPF Dresden) is implemented by 6 virtual motors, vm8

- vm13. These motors use functions that are defined in /online dir/TkIrc.pl. A beamline-specific-

code widget can be found under ’Misc’. It displays the motor positions and allows some debugging

(send commands to the MZV and receive the response).

100

Chapter 31

Monochromator, Tango

Online uses the device mnchrmtr to get/set the energy. Here is an example from P02 (/online dir/online.xml):

<device>




<device>p02/dcmener/oh.01</device>


<hostname>haspp02oh1:10000</hostname>

</device>

101

Chapter 32

MultipleMotor

The MultipleMotor is a Tango class that moves several motors in parallel. Here is an example from

P10. Each of girderx and girdery move 2 motors:

Figure 32.1: Properties of a MulipleMotor

Here are the lines from /online dir/online.xml which introduce the motors to Online:

<hw>

...

<device>

<name>girderx</name>



<device>p10/multiplemotors/opt.02</device>

102


<hostname>haspp10opt:10000</hostname>

</device>

<device>

<name>girdery</name>



<device>p10/multiplemotors/opt.03</device>



</device>

...

</hw>

Chapter 33

Mythen

A Mythen detector is introduced to Online by the following entry in /online dir/online.xml:

<hw>

...

<device>

<name>mythen</name>



<device>pXX/mythen/exp.01</device>


<hostname>hasppXX:10000</hostname>

</device>

...

</hw>

It can be operated as a virtual counter:


{

Spectra::mythen_start( "mythen", $Spectra::SYM{ scan_name}, $Spectra::SYM{

return 1;

}


{

while( Spectra::tng_state( "mythen"))

{

Util::log( "waiting for Mythen");


}

return 1

}

Note that the online -tki manual shows how parameters of this detector can be set by a beamline-


104

Chapter 34

NIGPIB (PCI-GPIB Interface, National

Instruments)

Jumper at DRQ5, DACK5, IRQ14, SW1: 10110 (’OFF’ -¿ 1, 0x2c0, default), jumper at W3.

105

Chapter 35

OMS58, OMS58S (Oregon Micro Systems

VME58)

VME motor controller: 8 motors per module. OMS58 selects the stepping motor, OMS58S the

servo motor. VME: A16D16/A16D8 4k at 0xf000, 0xe000, . . . . The step position ranges from

-33500000 to 33500000. Jumpers (VME connectors point downwards): J61 00000110 (A15-A12,

AM0, AM1, AM4,AM5), J71 00001000, J52 101101, J73 010, J15 00000000 (limit polarity, test

mode 11111111), J16 11111111, J26 110, J58 101101, J21 ..11.. (’..’ means that the jumper

connects the upper pins of adjacent pin pairs), J41 ..11.., J57 1111. The leftmost 4 pin pairs of J61

select the base address. Open jumpers mean ’1’. The board is delivered with 0000 (no jumpers set)

which translates to 0xf000. This is used by MOT1 - MOT8. The configuration 0001 ( jumper no. 4

set) translates to 0xe000, 0010 to 0xd000, etc.

Figure 35.1 shows an OMS VME58 board configured for MOT1 - MOT8 (base 0xf000). The fol-

lowing figures (35.2, 35.3, 35.4, 35.5) show the base address selection for (MOT1-MOT8), (MOT9-

MOT16), (MOT17-MOT24), (MOT25-MOT32).

Figures 35.6 and 35.7 show the limit switch polarity selection for the exeperiment and the test setup.

Power requirements: 1.75 A at 5V.

Stepping motors are introduced to Online by:

define/dev=stepping_motor/mod=oms58/base=0xf000/vec=0x0/chan=0 mot1








define/dev=stepping_motor/mod=oms58/base=0xe000/vec=0x0/chan=0 mot9

...

define/dev=stepping_motor/mod=oms58/base=0xd000/vec=0x0/chan=0 mot17

...

define/dev=stepping_motor/mod=oms58/base=0xc000/vec=0x0/chan=0 mot25

...

define/dev=stepping_motor/mod=oms58/base=0xb000/vec=0x0/chan=0 mot33

...

define/dev=stepping_motor/mod=oms58/base=0xa000/vec=0x0/chan=0 mot41

...

define/dev=stepping_motor/mod=oms58/base=0x9000/vec=0x0/chan=0 mot49

...

106


...


...

Servo motors are introduced by:

define/dev=stepping_motor/mod=oms58s/base=0xf000/vec=0x0/chan=0 mot1

define/dev=stepping_motor/mod=oms58s/base=0xf000/vec=0x0/chan=1 mot2

Figure 35.1: OMS VME58 Controller

35.1 Check-motor-registers, cmr

Section 36.2 contains some details about what happens, if the internal and controller registers do

not agree.

Figure 35.2: OMS VME58 Controller, MOT1 - MOT8, Base 0xf000

Figure 35.3: OMS VME58 Controller, MOT9 - MOT16, Base 0xe000

Figure 35.4: OMS VME58 Controller, MOT17 - MOT24, Base 0xd000

Figure 35.5: OMS VME58 Controller, MOT25 - MOT32, Base 0xc000

Figure 35.6: OMS VME58 Controller, Limit Switch Polarity Selection for Experiments

Figure 35.7: OMS VME58 Controller, Limit Switch Polarity Selection for Test Setup

Chapter 36

OMSMAXV (Pro-Dex, Oregon Micro

Systems)

VME motor controller: 8 motors per module. The module type OMSMAXV selects the stepping

motor mode.

VME: A32D16/A32D8, 4k at 0x01000000, 0x02000000, . . . .

Jumpers (VME connectors point right): J12 100010 (’1’ means jumper set), J13 01111111011011

(for base address 0x01000000), J14 always 00000000, J8 all jumpers up, selecting stepper mode,

J7 all jumpers low, selection digital I/O.

J12: The 3 leftmost jumpers select A32, A24 aund A16 mode. The A32 jumper is left. The other 3

jumpers select the IRQ which is not used.

J13: The 8 leftmost jumpers specify the base address. The least significant bit is left. An open

jumper selects 1. The other 6 jumpers encode the address modifier.

The maximum slew rate is 4000000 steps per second, the maximum acceleration is 8000000 steps

per second2. The step position ranges from ±231.

Assignment of the limit switches: the cw limit is hit with increasing steps.

Figure 36.1 shows an OMS MAXV board configured for MOT1 - MOT8 (base 0x1000000). The

following figures show some details: 36.2 show the default settings of the J7 and J8 jumpers,

36.3, 36.4, 36.5 show the base address selection for (MOT1-MOT8), (MOT9-MOT16), (MOT17-

MOT24).

Stepping motors are introduced to Online by:

define/dev=stepper/mod=omsmaxv/base=0x01000000/vec=0x0/chan=0 mot1









...

If Tango servers are used, we need entries in /online dir/online.xml, e.g.:

<?xml version="1.0"?>

<hw>



<device>

<name>exp_mot01</name>


<module>oms58</module>

<device>p09/motor/exp.01</device>



</device>

</hw>

Figure 36.1: OMS MAXV Controller

36.1 OMSMAXV with Encoder, NON-Tango

Stepping motors with encoders are introduced to Online by:

define/dev=stepper/mod=omsmaxv/base=0x01000000/vec=0x0/chan=0/encoder=1 mot1

Online provides the following functions to operate the encoders:

SET_MOTOR_CONVERSION_ENCODER(id) smce()

GET_MOTOR_ENCODER_RAW(id) gmeraw()

SET_MOTOR_HOME_POSITION(id) smhp()

GET_MOTOR_UNIT_POSITION_ENCODER(id) gmupe()

GET_MOTOR_CONVERSION_ENCODER(id) gmce()

Figure 36.2: OMS MAXV, J7 (Ditial I/O), J8 (Stepping mode)

GET_MOTOR_HOME_POSITION(id) gmhp()

GET_MOTOR_FLAG_ENCODER(id) gmfe()

GET_MOTOR_FLAG_ENCODER_CD(id) gmfecd() encoder conversion defined

GET_MOTOR_FLAG_ENCODER_HD(id) gmfehd() encoder home position defined

GET_MOTOR_FLAG_ENCODER_HOMED(id) gmfeh() encoder homed defined

move/home id

This is a typical sequence:

set_motor_unit_backlash( mot65) = 0.1

smce(mot65) = -2000

smhp(mot65) = 50

move/home mot65

* = gmupe(mot65)

The function get motor unit position encoder() works only after a motor has been homed. If this

is not possible, the function get motor encoder raw() provides a relative measurement. A virtual

counter that uses the raw encoder reading may look like this:


{

return 1;

}


Figure 36.3: OMS MAXV, MOT1 - MOT8, base: 0x1000000

{

return Spectra::get_motor_encoder_raw( "mot25")/Spectra::get_motor_conversion_encoder(

}

36.2 Check-motor-registers, cmr

At various places the OmsVme58 Tango server ensures the validity of the step position by compar-

ing the internal (software) values and the controller registers. If the internal and controller registers

deviate, the following sequence of conditions are tested:

• If the controller is 0 and within the step limits, the controller is loaded with the internal value,

assuming that there was a power cycle.

• If the controller is non-zero but deviates from the internal value by shift-right-by-3bits, the

internal value is loaded to the controller. This is a workaround for the hardware bug that the

position registers are changed by the first homing after re-powering VME.

• If the controller is non-zero and inside limits, the internal value is overwritten by the con-

troller value. We trust the controllers because they should keep track of the motor position.

• Otherwise the disagreement is not resolved automatically.

We arrive here because the controller register and the internal value disagree and the con-

troller register is outside the limits. How can this happen? Maybe beause of electronical

noise or some other application operated the motor independent of Tango.


– If the motor position is somehow known, write it down. You are safe. After you resolved

the register discrepancies, see below, you can calibrate the motor, if necessary.

If the position is not known, you may inspect the files in the directory /online dir/MotorLogs.

You may also inspect the versions of /online dir/ipython log.py (or /online dir/motor positions.bck,

online.log)

– Write down the attributes StepPositionController and StepPositionInternal.

– Inspect the Tango server log file: /var/tmp/ds.log/OmsVme58_<instance>.log,

e.g. by:

$ tail -100 /var/tmp/ds.log/OmsVme58_<instance>.log

or use Astor to inspect the stderr of the OmvVme58 server.

Search for the last entry of this kind:

OmsVme58::check_motor_register: Mon Sep 4 12:28:13 2017

OmsVme58::check_motor_register: p99/motor/d1.65, controller -100001

OmsVme58::check_motor_register: p99/motor/d1.65, controller -100001,

OmsVme58::check_motor_register: p99/motor/d1.65, the controller-is-right

OmsVme58::check_motor_register: p99/motor/d1.65, the internal-is-right

OmsVme58::check_motor_register: p99/motor/d1.65, see HW manual

– Depending on your decision, whether the controller or the internal value is correct, you

have to set the StepPositionController or StepPositionInternal attribute.

– Check the limits. If you trusted the controller, you have to change the limits.


36.3 Homing, OMSMAXV with Encoder, Tango

Warning: The homing of a motor involves the risk that the motor moves all the way to the limit

switches. Software limits are ignored during the homing procedure. Make sure that the limit

switches are correctly cabled.

The homing procedure should be started from Online -tki. In the following it is explained step by

step, starting from scratch.

• make sure that the FlagEncoder property (Tango server) is set and that it has the value 1. If

you have to create this property and change its value, the Tango server has to be restarted.

• open the Move widget

• open the Encoder widget from the Move widget (Options)

• move the motor a little bit forth and back to check that the encoder reading changes.

• set the correct encoder conversion factor. This is a possible procedure:

– move the motor to position 0 (Move widget).

– set the home position to 0 (Encoder widget).

– clear the motor step register (MotorProperties widget).

– clear the encoder position by clicking on Cali Enc. (Encoder widget).

– set the encoder conversion factor to 1 (Encoder widget).

– move the motor to 1 units (Move widget).

– the encoder raw position gives the encoder conversion factor (Encoder widget). There

may be tiny deviations between the actual value and the true value due to hardware

imperfections, e.g. if the encoder raw position is 19988 the true conversion factor is

most likely 20000.

– set the encoder conversion factor (Encoder widget).

– If the encoder conversion factor and the conversion factor have different signs, set the

FlagInvertEncoderDir to 1 and change the sign of the encoder conversion factor. This

fixes the bug that the encoderRatio must not be negative.

• move back to 0. Check whether the encoder position is 0 and the encoder raw position is 0.

• suppose the backlash is greater than 0: move the motor to a position below the home position.

If you have no idea where the home position is, search it while standing in front of the axis.

The encoder LED changes its colour when moving over the home position. If you have no

clear indication where the home position is, ask an expert.

• make sure that the backlash is sufficiently large. It is a frequent error that the backlash is too

small.

• start the motor homing sequence (Encoder widget). While the motor is homed, software

limits are ignored. The motor moves until it senses home (reference mark) or hits a limit

switch. If a limit switch is hit, the direction of the motion is reversed to search for home. If

the second limit switch is hit, the sequence is terminated.

• if the homing procedure was not successfull but the motor stopped near the home position,

this is most likely because the backlash was too small.

• the motor is homed now but the encoder position is meaningless, since the correct home

position has not been set yet. You have to determine the current motor position somehow and

set the home position accordingly.

• set the correct motor unit limits. In general the homing procedure changes them. That is

because the step register is cleared when the motor moves over the reference position. How-

ever, the limit re-adjustment needs to be done only once after the first homing procedure of a

motor.

The function get motor unit position encoder() works only after a motor has been homed. If this

is not possible, the function get motor encoder raw() provides a relative measurement. A virtual

counter that uses the raw encoder reading may look like this:


{

return 1;

}


{

return Spectra::get_motor_encoder_raw( "mot25")/Spectra::get_motor_conversion_encoder(

}

36.4 Closed loop, OMSMAXV with Encoder, Tango

The actions described in this section are supported by the EncoderAttribute widget of the Sar-

danaMotorMenu.py.

Warning: Exit the closed loop mode before disconnecting the encoder cables.

During closed loop operation the motor controller card minimizes the difference between encoder

reading and step position.

• The encs and the steps have to have identical offsets, in other words: the Home position and

the UnitCalibration have to be the same.

• EncoderRatio=Conversion/ConversionEncoder takes into account the different magnitudes

of the conversion factors.

• FlagInvertEncoderDirection: the Oms closed loop algorithm does not like negative Encoder-

Ratios. To avoid this, you may have to set this flag to 1 and change the sign of the encoder

conversion factor.

• The loop can be closed, if the position and positionEncoder are close to each other and the

registers are consistent, meaning that Enc*ER has to be close to the StepPositionController

The closed loop procedure has the following steps:

• If the homing procedure can be executed: if possible, execute the homing procedure as

described in Help-Homing.

Note: The home flag is cleared when the Tango server is re-started.

• If the homing procedure cannot be executed:

– Press the ’Set FlagEncoderHomed’. This is possible without loosing accuracy, as long

as the VME stayed powered after the last homing procedure.

– Press ’Cali Enc.’ to calibrate the encoder position to the motor position.

– Press ’AlignRegAndEncs’ to make the step position consistent with the encoder read-

ing. Generally this changes the UnitCalibration. It does not change the position.

SardanaMotorMenu.py: The widget displays a quantity Enc*ER=. The value should be

close to the step register. ’Close’ means within DeadBand*EncoderRatio.

Warning: a calibration (which can only be done in open-loop mode) changes the UnitCali-

bration of the motor creating a difference to the home position of the encoder. In this case the

user has to CaliEnc and AlignWithEnc again. The same applies to reset-motor-step-position

commands.

• set the value of CorrectionGain [1,32000], e.g.: 100 (Encoder widget)

OmsMaxV manual (HG - stepper hold gain): ”The parameter should be set experimentally

by increasing it until the system is unstable then reducing it slightly below the threshold of

stability. Factory default: 1”

”Stability” can be sensed by listening to the motor or by watching the motor position. If the

position keeps jumping forth and back, although the target position has been reached, the

motor is unstable.

If the value is too low, the motor needs a long time to reach the target position.

• set the DeadBand, e.g.: 2

OmsMaxV manual on HD (stepper hold deadband): ”If the encoder count is within this

distance of target, it is considered in position and no further correction will be made.”

• set SlewRateCorrection, must be non-zero, the maximum is the motor slew rate

The maximum velocity to be used during position correction.

• move the motor to ensure that the encoder position and the motor postion are more or less

identical.

• set SlipTolerance. In closed loop mode movements have to terminate, if the axis slips. Oth-

erwise the motor moves into the limit switch, if it looses the encoder signal. In case SlitTo-

larance is too low, every movement is interrupted by the slip condition. If it is much too low,

esp. below the DeadBand, the slip condition is detected also when the motor stands still. The

SlitTolerance is written to the hardware when the loop is closed. Typical values 100 (but also

1000).

• if the encoder counts and the steps have the same direction, you may close the loop now.

Whether or not the steps and the encoder counts have the same direction can be checked by

moving the motor. Compare StepPositionController and Encoder PositionEncoderRaw.

• if steps and encoder counts have the opposite direction:

– set the FlagInvertEncoderDirection to 1.

– change the sign of the encoder conversion.

– move the motor to ensure that the position and the encoder position are more or less

identical.

– close the loop.

• the closed loop is active after the next move.

• closed loop operation needs to be enabled after the server was re-started

36.5 Variable Velocity Contouring Feature

The first demo script shows the basic usage of the VVC feature. The second produces graphics

output showing the motor position as a function of time.

36.5.1 demoVVC.py

The following script demonstrates how to continuously move a motor through 3 regions with dif-

ferent speeds. The maximum numer of regions supported is 100, can be extended.

#!/usr/bin/env python

’’’

demo for variable velocity contouring feature

’’’

import sys, argparse, time

import PyTango

import HasyUtils

MOTOR_NAME = "p99/motor/d1.65"

proxy = None

def pos( dest):

’’’

move to a unit position

’’’

print "--- pos to", dest, "slew", proxy.slewRate

proxy.position = float(dest)

while proxy.state() is PyTango.DevState.MOVING:

print "pos", proxy.state(), proxy.position

time.sleep(0.5)

if HasyUtils.inkey() == 32:

proxy.command_inout( "StopMove")

return False


return True

def demo():

’’’

move through 3 regions with different speeds

’’’

#

# start the test at 0

#

if not pos( 0): return

lst = [ "slew: 20000, position: 0.1",

"slew: 30000, position: 0.3",

"slew: 40000, position: 0.5"]

proxy.command_inout( "movevvc", lst)


print proxy.state(), proxy.position

time.sleep(0.5)

if HasyUtils.inkey() == 32: # space bar interrupts move


print "DONE", proxy.state(), proxy.position

#

# go back to 0

#

pos( 0)

return

def main():

global proxy

parser = argparse.ArgumentParser(

formatter_class = argparse.RawDescriptionHelpFormatter,

description="Variable Velocity Contouring Demo")

parser.add_argument(’-x’, dest="tst", action="store_true", help=’execute

args = parser.parse_args()

try:

proxy = PyTango.DeviceProxy( MOTOR_NAME)

except PyTango.DevFailed, e:

PyTango.Except.print_exception(e)

sys.exit()

proxy.FlagClosedLoop = 0

if args.tst:

return demo()

parser.print_help()

if __name__ == "__main__":

main()

36.5.2 demoVVCwithGraphic.py

#!/usr/bin/env python

’’’

demo for variable velocity contouring feature

’’’

import sys, argparse, time

import PyTango

import HasyUtils

import Spectra

MOTOR_NAME = "p99/motor/d1.65"

proxy = None

def pos( dest):

’’’

move to a unit position

’’’

print "--- pos to", dest, "slew", proxy.slewRate

proxy.position = float(dest)



time.sleep(0.5)

if HasyUtils.inkey() == 32:


return False


return True

def demo():

’’’

move through 3 regions with different speeds

’’’

#

# start the test at 0

#

if not pos( 0): return

Spectra.gra_command( "reset/nocon")

posGQE = Spectra.SCAN( name = "Pos", start = 0, stop = 1, np = 500, at

colour = 2,

comment = "Position %s as function of time" % proxy.name(),

xlabel = ’time’, ylabel=’Pos’, date = True)

lst = [ "slew: 10000, position: 0.1",

"slew: 20000, position: 0.5",

"slew: 40000, position: 0.9"]

proxy.command_inout( "movevvc", lst)

i = 0

startTime = time.time()


print proxy.state(), proxy.position

time.sleep(0.1)

if HasyUtils.inkey() == 32: # space bar interrupts move


posGQE.setX( i, time.time() - startTime)

posGQE.setY( i, proxy.position)

i += 1

Spectra.gra_command( "autoscale")

Spectra.gra_display()

print "DONE", proxy.state(), proxy.position

#

# go back to 0

#

pos( 0)

return

def main():

global proxy

parser = argparse.ArgumentParser(

formatter_class = argparse.RawDescriptionHelpFormatter,

description="Variable Velocity Contouring Demo")

parser.add_argument(’-x’, dest="tst", action="store_true", help=’execute

args = parser.parse_args()

try:

proxy = PyTango.DeviceProxy( MOTOR_NAME)

except PyTango.DevFailed, e:

PyTango.Except.print_exception(e)

sys.exit()

proxy.FlagClosedLoop = 0

if args.tst:

return demo()

parser.print_help()

if __name__ == "__main__":

main()

36.6 Error: message sempahore remains 0

So far, this error message appeared for 2 reasons:

• VME was power cycled without restarting the server. User action: restart the server.

• OmsMaxV card broken.

Chapter 37

PCO4000 Camera

A PCO4000 Camera is introduced to Online by the following entry in /online dir/online.xml:

<hw>

...

<device>

<name>pco4000</name>



<device>p06/ccd/pco4000</device>



</device>

...

</hw>

The PCO can be implemented as a virtual counter:


{

return Spectra::pco4000_start( "pco4000", $Spectra::SYM{ scan_name} . "_",



}


{

while( Spectra::tng_state( "pco4000"))

{

Util::log( "waiting for pcocamera");


}

return 1;

}

Notice that the online -tki manual contains an example of how to create a beamline specific code

widget for the PCO4000.

124

Chapter 38

Perkin Elmer Detector

A Perkin Elmer detector is introduced to Online by the following entry in /online dir/online.xml:

<hw>

...

<device>

<name>pe</name>



<device>p02/pedetector/xrd.01</device>


<hostname>haspp02XXX:10000</hostname>

</device>

...

</hw>

Here is the virtual counter code for a Perkin Elmer:


{

return Spectra::perkinElmer_startSubtracted( "pe_detector",

$Spectra::SYM{ scan_name} .



}


{

while( Spectra::tng_state( "pe_detector"))

{

Util::log( "waiting for pe_detector");


}

return 1;

}

The following example shows how a single shot can be taken from a .gra file:

!

125

Figure 38.1: Jive, PerkinElmerCtrl

! ˜/prog/perkinElmerSubtracted.gra

!

fname_pe = arg(1)

st_pe = arg(2)

no_pe = arg(3)

eval [Spectra::perkinElmer_singleShotSubtracted( "pe_detector", "fname_pe",

st_pe =

fname_pe =

no_pe =

The file exp ini.exp contains a symbol assignment:

!

! /online_dir/exp_ini.exp

!

pe_subtracted = "run prog:perkinElmerSubtracted.gra"

The user can invoke the .gra file from the command line:

ONLINE> pe_subtracted someFileName 2 1

Note that the online -tki manual contains the description of a beamline-specific-code widget for the

Perkin Elmer detector.

Figure 38.2: Jive, PerkinElmerDetector

Chapter 39

Photonic Science Camera, P03

A Photonic Science Camera is introduced to Online by the following entry in /online dir/online.xml:

<hw>

...

<device>

<name>pscamera</name>



<device>p03/pscamera/nano.01</device>


<hostname>haspp03nano:10000</hostname>

</device>

...

</hw>

Note that the online -tki manual shows how parameters of this camera can be set by a beamline-


The camera can be operated as a virtual counter:


{

return Spectra::photonicScienceStart( "pscamera", $Spectra::SYM{ scan_name}



}


{

while( Spectra::tng_state( "pscamera"))

{

Util::log( "waiting for pscamera");


}

return 1;

}

128

Chapter 40

PIDPC (PI Digital Piezo Controller)

If the PIDPC motors are connected via an USB adaptor we define:

define /device=piezo_motor/module=pidpc/ifc="/dev/ttyUSB7"/chan=1 mot31



129

Chapter 41

PIE710, PIE712 (PI Digital Piezo Controller,

Tango)

These motors are introduced to Online by adding the following lines to /online dir/online.xml:

<device>

<name>mi_pi1</name>


<module>pie712</module>

<device>p23/piezopi/exp.01</device>



</device>

<device>

<name>na_pi1</name>


<module>pie710</module>

<device>p23/piezopie710/exp.01</device>



</device>

41.1 PIE710

If the attribute FlagMoveByMwaveGenerator is set to 1, moves can be executed using the waveform

generator. This way the move time should be calculable. Figures 41.1 and 41.1 show the difference,

actual move time - calculated move time, as a function of slew rate. The difference was measured

over a distance of 10 units.

Figure 41.1 shows difference, setPoint - actPos.

41.2 PIE712

If the attribute FlagMoveByMwaveGenerator is set to 1, moves can be executed using the waveform

generator. This way the move time should be calculable. Figures 41.2 and 41.2 show the difference,

actual move time - calculated move time, as a function of slew rate.

Here are some details about the move by WF generator:

130

Figure 41.1: With wavegenerator, real move time minus calc. move time as a function of slew rate, 2 - 50

• The current position is determined by ”WOS?” (offset of the waveform genrator)

• The attribute WaveOutputCycles has to be 1.

• The WaveTableRate has to be in the range [1,100], the value of 20 seems to be a good choice.

• The moveTime is calculated using the amplitude (target - currPos) and the slew rate.

• TimePerPoint is updateRate (20 musecs) * WaveTableRate

• NoOfPoints is moveTime/timePerPoint

• NoOfPoints has to be in the range [10, 62464]

• SpeedUpPoints is 10 for NoOfPoints ¡ 1000, 20 otherwise.

Example-1: move from 0 to 100 with slew = 1000 and WaveTableRate= 20.

...

PiezoPiCtrl::write_read_socket: sending ’WOS? 1<LF>’

PiezoPiCtrl::write_read_socket: received ’1=4.240417e-001’

PiezoPiCtrl::write_read_socket: sending ’SPA? 1 0x0E000200<LF>’

PiezoPiCtrl::write_read_socket: received ’1 0xe000200=2.000000e-005’

get parameter from volatile memory, here updateRate

PiezoPiCtrl::write_socket: sent ’WSL 1 1<LF>’

connect wave generator 1 to wave table 1

PiezoPiCtrl::write_read_socket: sending ’err?<LF>’

PiezoPiCtrl::write_read_socket: received ’0’

Figure 41.2: Without wavegenerator, real move time minus calc. move time as a function of slew rate, 2 - 50

PiezoPiCtrl::write_socket: sent ’WAV 1 X LIN 239 9 0 219 0 10<LF>’

Linear move:

SegmentLength 239

Amplitude 99

Offset 0

Wavelength 219

StartPoint 0

SpeedUpDown 10

PiezoPiCtrl::write_socket: sent ’WGO 1 0x101<LF>’

start output of wave generator 1 with "start at the endpoint of the last

...

Example-2: move from 0 to 10 with slew = 10 and WaveTableRate= 20.

...

PiezoPiCtrl::write_read_socket: sending ’WOS? 1<LF>’

PiezoPiCtrl::write_read_socket: received ’1=4.206543e-001’

PiezoPiCtrl::write_read_socket: sending ’SPA? 1 0x0E000200<LF>’

PiezoPiCtrl::write_read_socket: received ’1 0xe000200=2.000000e-005’

PiezoPiCtrl::write_socket: sent ’WSL 1 1<LF>’

PiezoPiCtrl::write_read_socket: sending ’err?<LF>’

PiezoPiCtrl::write_read_socket: received ’0’

PiezoPiCtrl::write_socket: sent ’WAV 1 X LIN 2395 9 0 2355 0 20<LF>’

PiezoPiCtrl::write_socket: sent ’WGO 1 0x101<LF>’

...

Figure 41.3: The difference setPoint - actPos, with wavegenerator

The figures 41.2 and 41.2 display the difference of the real and estimated move time as a function

of the slew rate for the PiezoE712. The first figure gives the results for low slew rates (0.5 - 20)

measured with a move distance of 5 units, the second for higher slew rates ( 20 - 1000) with a move

distance of 100 units. Figure 41.2 displays the result for moves without wave generator.

Figure 41.4: With WG, real move time minus calc. move time as a function of slew rate, 0.5 - 20

Figure 41.5: With WG, real move time minus calc. move time as a function of slew rate, 20 - 1000

Figure 41.6: Without WG, real move time minus calc. move time as a function of slew rate, 20 - 1000

Chapter 42

Quadpack, Sixpack (Trinamic)

Canbus stepper controller/driver: 4/6 motors per module. Identfifier: 11 bit, the least significant 3

bits are fixed (0). An identfifier must not be 0. Example:

ONLINE> def/dev=stepper/mod=quadpack/base=8/vec=0/chan=0 motqp1

ONLINE> def/dev=stepper/mod=quadpack/base=8/vec=0/chan=3 motqp4

ONLINE> def/dev=stepper/mod=sixpack/base=8/vec=0/chan=0 motsp1

The currents are selected by the symbol MOTQP current id chan, e.g.:

MOTQP_WERT_8_0 = 0 (0 .. 255, def. 0, Imax)

MOTQP_I0_8_0 = 8 (0 .. 8, def. 8, power-down, 0%)

MOTQP_I1_8_0 = 2 (0 .. 8, def. 2, standing, 50%)

MOTQP_I2_8_0 = 1 (0 .. 8, def. 1, slew, 75%)

MOTQP_I3_8_0 = 0 (0 .. 8, def. 0, acceleration, 100%)

These symbols are evaluated once per session - during the startup. The parameter Imax effects two

motors: ’0’ for (0,1) and ’2’ for (2,3).

The currents can be changed afterwards by:

can(8) = ( 0x10, Chan, Wert, 0, 0, 0, 0, 0)

can(8) = ( 0x11, Chan, i0, i1, i2, i3, p5, p6)

e.g.:

can(8) = ( 0x10, 0, 255, 0, 0, 0, 0, 0)

can(8) = ( 0x11, 0, 8, 2, 1, 0, 0, 2)

The idea is that one should use the low level CanBus calls to find the currents and add the coore-

sponding symbols in exp ini.exp.

The parameters P5 and P6 specify the power-down delay time [2 msec], P6 is the MSB, P5 must

be even. The default is 0x0200 (x 0.002 s) = 1.024 s.

Note: Spectra uses 500 kB as default CanBus speed.

136

Chapter 43

Pilatus100k, 300k, Tango

The following lines show how a Pilatus100k or Pilatus300k detector is introduced to Online, file

name: /online dir/online.xml


<hw>

#

#

#

<device>

<name>pilatus</name>

<type>detector</type>

<module>pilatus100k</module>

<device>bw4/pilatus/300k</device>


<hostname>hasb1:10000</hostname>

</device>

</hw>

The module name, pilatus100k, is the same for both device types.

The Tango server can be started only, if the camserver is running:

$ ssh -X det@SomePilatusPc

cd /home/det/p2_det

./runtvx

camserver stays alive

kill the client (the window that contains ’disconnect’)

Notice that the state of the Tango server has to be sensed before a StartStandardAcq command is

issued. Otherwise the camserver may enter a faulty state. In the case it is not possible to take

sequences of frames.

The Perl-Spectra manual describes the Pilatus functions and gives an example of a virtual counter

that uses these functions to operate the Pilatus.

The Pilatus detector can be operated as a virtual counter:


{

Util::log( "VC5: scan_name $Spectra::SYM{ scan_name}");

Spectra::tng_attrLongWrt( "pilatus", "NbFrames", 1);

137

Figure 43.1: Jive, Pilatus, Socket

Spectra::pilatus_start( "pilatus", $Spectra::SYM{ scan_name},


$Spectra::SYM{ sindex},

".tif");

return 1;

}


{

while( Spectra::tng_state( "pilatus")

{

Util::log( "waiting for Pilatus, state " . Spectra::tng_state( "pilatus"));


if( $Spectra::SYM{ interrupt_scan})

{

Util::log( "wait-for-pilatus aborted");

last;

}

}

Util::log( "pilatus state " . Spectra::tng_state( "pilatus");

return 1;

}

At haspp03nano the configuration of the Pilatus detector is done using a script:

Figure 43.2: Jive, Pilatus

#!/bin/env perl

#

# pilatus

#

use Spectra;

my ( $keyword, $value) = @ARGV;

if( !defined( $keyword) )

{

print "\n\n Usage: \n";

print " picfg keyword [value] \n\n";

print " keywords: \n";

print " FileDir \n";

print " FilePrefix \n";

print " DelayTime \n";

print " ExposureTime \n";

print " FileStartNum \n";

print "\n\n";

goto finish;

}

#

# read the attributes

#

if( !defined( $value))

{

if( $keyword =˜ /FileDir/i)

{

$result = Spectra::tng_attrStringRd( "pilatus", $keyword);

}

elsif( $keyword =˜ /FilePrefix/i)

{

$result = Spectra::tng_attrStringRd( "pilatus", $keyword);

}

elsif( $keyword =˜ /FileStartNum/i)

{

$result = Spectra::tng_attrLongRd( "pilatus", $keyword);

}

elsif( $keyword =˜ /DelayTime/i)

{

$result = Spectra::tng_attrDoubleRd( "pilatus", $keyword);

}

elsif( $keyword =˜ /ExposureTime/i)

{

$result = Spectra::tng_attrDoubleRd( "pilatus", $keyword);

}

print "\n $result \n\n";

}

#

# set the attributes

#

else

{

if( $keyword =˜ /FileDir/i)

{

Spectra::tng_attrStringWrt( "pilatus", $keyword, $value);

}

elsif( $keyword =˜ /FilePrefix/i)

{

Spectra::tng_attrStringWrt( "pilatus", $keyword, $value);

}

elsif( $keyword =˜ /FileStartNum/i)

{

Spectra::tng_attrLongWrt( "pilatus", $keyword, $value);

}

elsif( $keyword =˜ /DelayTime/i)

{

Spectra::tng_attrDoubleWrt( "pilatus", $keyword, $value);

}

elsif( $keyword =˜ /ExposureTime/i)

{

Spectra::tng_attrDoubleWrt( "pilatus", $keyword, $value);

}

}

finish:

1;

There is another script for the acquisition:

#!/bin/env perl

#

# Pilatus -> VC2

#

use Spectra;

my $status = 1;

my ( $sample_time, $np) = @ARGV;

if( !defined( $sample_time) ||

!defined( $np))

{

print "\n\n Usage: \n\n";

print " piacq sampleTime Np \n";

print "\n\n";

goto finish;

}

if( !defined( $Spectra::SYM{ generic_scan_name}))

{

$Spectra::SYM{ generic_scan_name} = "hasylab";

}

if( $np < 1)

{

Spectra::error("piacq: np < 1");

goto finish;

}

if( $np == 1)

{

$status = Spectra::scan( device => "dummy",

np => $np,

st => $sample_time,

title => "A Pilatus Test Scan",

profile =>

{ timer => [ qw(t01)],

counter => [ qw( p03nano_c01 vc2 ipetra)],

flags => [ qw( write_to_disk 1

display_deadtime 1

bell_on_scan_end 1)],

});

}

else

{

$status = Spectra::scan( device => "dummy",

start => 0,

stop => ($np - 1),

delta => 1,

st => $sample_time,

title => "A Pilatus Test Scan",

profile =>

{ timer => [ qw(t01)],

counter => [ qw( p03nano_c01 vc2 ipetra)],

flags => [ qw( write_to_disk 1

display_deadtime 1

bell_on_scan_end 1)],

});

}

finish:

$status;

The file exp ini.exp contains symbol assignments that allow the use to invoke the scripts from the

command line:

!

! exp_ini.exp

!

piacq = "run [˜.prog]piacq.pl"

picfg = "run [˜.prog]picfg.pl"

Chapter 44

Prosilica Camera

A Prosilica Camera is introduced to Online by the following entry in /online dir/online.xml:

<hw>

...

<device>

<name>prosilica</name>



<device>p04/pscamera/nano.01</device>


<hostname>haspp04someNode:10000</hostname>

</device>

...

</hw>

The Prosilical camera can be operated as a virtual counter:


{

return Spectra::prosilicaStart( "prosilica", $Spectra::SYM{ scan_name}



}


{

while( Spectra::tng_state( "prosilica"))

{

Util::log( "waiting for prosilica");


}

return 1;

}

143

Chapter 45

RGH25F (Encoder, TCP/IP, Renishaw)

A Renishaw encoder module of type RGH25F is defined in the following way:

define/dev=encoder/mod=rgh25f/host="131.169.39.63" enc1

Notice that the host is specified using the dot notation.

The RGH25F is part of a Beckhoff/ADS system. It is operated by the following functions:

* = encoder( enc1, position)

* = encoder( enc1, status)

1 after ’init’

10 after ’doref’

* = encoder( enc1, doref)

Activates the zero mode, e.g.:

move mot12 55.0

* = encoder( enc1, doref)


-> 10

move mot12 54.5


-> 1

* = encoder( enc1, init)

* = encoder( enc1, offset)

* = encoder( enc1, offset, intVal)

* = encoder( enc1, conversion)

* = encoder( enc1, conversion, floatVal)

* = encoder( enc1, calibrate, floatVal)

changes the encoder offset to produce floatVal at the

current position, e.g.:

* = encoder( enc1, calibrate, gmup( mot12))

* = get_position( enc1)

The position is calculated by: pos = (encoder - offset)/conversion

144

Chapter 46

Roper Scientific Quadro

The following description was written by Michael Sprung, P10:

file name: roper_installation_instructions.txt

This file tries to describe how to incorporate the Quadro CCD

from Roper Scientific into Online.

1) Install the TANGO Server for the Camera (CCDPVCAM)

2) Update the ’online.xml’ file to introduce the new device:





<device>

<name>roper</name>



<device>p10/xxx/yyy</device>



</device>





3) Create an Online widget for the roper camera by adding the code included

in the file ’Roper_online_tkirc_code.txt’ to your TkIrc.pl file

(in the /online_dir/)

4) Update the ’exp_ini.exp’ file to activate the camera macros:

! ==========================================================

! --- Roper Scientific ’Quadro’ macros

! ==========================================================

roperoff = "run <beamline.macros.ccdmacros.roseker>roperoff.gra"

roperon = "run <beamline.macros.ccdmacros.roseker>roperon.gra"

ropersetup = "run <beamline.macros.ccdmacros.roseker>ropersetup_p10.pl"

roperseries = "run <beamline.macros.ccdmacros.roseker>roperseries_p10.pl"

ropertake = "run <beamline.macros.ccdmacros.roseker>ropertake_p10.pl"

roperascan = "run <beamline.macros.ccdmacros.roseker>roperascan_p10.pl"

145

roperdscan = "run <beamline.macros.ccdmacros.roseker>roperdscan_p10.pl"

roperamesh = "run <beamline.macros.ccdmacros.roseker>roperamesh_p10.pl"

5) Edit the ascan, dscan, amesh and dmesh files and update the path to the

6) The macros depend on 2 additionally activated Gra Scripts (’roperon’ &

’roperoff’)

7) Use the ’SCAN’ BNC output of the camera to operate your shutter system

The directory haspp10e2:/beamline/macros/ccdmacros/roseker contains the instructions and the

utility scripts.

Chapter 47

SDD7

The SDD7 detector is defined in /online dir/exp ini.exp by:

define/dev=MCA/mod=SDD7/host=fecpxi2/port=33345/chan=0 MCA11







Make sure that these definitions are made after the device list has been loaded (load/nocon) because

’load/nocon’ works only with an empty device list.

The following functions operate the SDD7:

* = START_MCA( MCA11, 0)

The number 0 serves as a bank number for other MCAs. The

SDD7 has no banks. It is supplied because the function

expects 2 arguments.

* = STOP_MCA( MCA11, 0)

* = READ_MCA( MCA11, 0, scan_name, 4096)

The SDD7 server sends data for all channels only. Online

buffers the data in order to minimize I/O. The procedure

is as follows. There is one buffer for each channel. Each

buffer has a flag that indicates whether it contains valid

data. This flag is set to valid when new data from the SDD7

arrive. The flag is cleared when the data is read by a

read_mca(). If read_mca() refers to a channel that has

valid buffered data, the data are copied from the buffer

to scan_name without communicating to the SDD7 and the

corresponding buffer is marked invalid. If read_mca()

refers to an invalid buffer, data is read from the SDD7.

Btw.: the total count rate is always 1 MHz.

* = CLEAR_MCA( MCA11, 0)

147

Clears the SDD7 and marks the Online buffers invalid.

* = CONTROL_MCA( MCA11, OFF)

* = CONTROL_MCA( MCA11, WARM_ON)

* = CONTROL_MCA( MCA11, COLD_ON)

Both commands take 2 minutes, automatically preceded by an OFF

* = CONTROL_MCA( id, START_IO)

* = CONTROL_MCA( id, INIT_AD)

Send START_IO and INIT_AD after each restart of the server. Online

sends START_IO and INIT_AD after it opened the socket.

* = STATUS_MCA( MCA11, all)

Displays the complete status list and waits for a keystroke.

OFF:

SDD_M_6 TEMP_W VAC_E_OFF DEWP_E_OFF TC_GOOD_OFF

VOLTC_E_OFF HV_ON_OFF HV_ERROR_OFF;

WARM_ON:

SDD_M_6 TEMP_W VAC_E_OFF DEWP_E_OFF TC_GOOD_ON

VOLTC_E_OFF HV_ON_ON HV_ERROR_OFF;

* = STATUS_MCA( id, keyword)

returns 1, if the keyword is in the status list, 0 otherwise

The server is started by:

ssh -l sdduser fecpxi2

> cd /home/sdduser/DAQ/PXI/Work/BIN

> ../nserver-111208

Chapter 48

SF7210 (GPIB)

IEC (GPIB, IEEE-488) module: VME A16D8, 256B at 0x300. Rotary switches: 3000 (VME con-

nectors point upwards, marked corner bottom-right). Jumper J1 0, J2 0010000, J3 1, J4 01100000.

149

Chapter 49

SIS1100/3100 PCI - VME Adaptor

Figure 49.2 shows the LED status of the SIS3100, if it is connected, the following, if it is not.

Figure 49.1: SIS3100, Connected

150

Figure 49.2: SIS3100, Disconnected

Chapter 50

SIS3302 (FADC,MCA)

Update: if the module needs to be gated. The GateExternalEnabled attributes should be true. The

new server is able to save and load configuration files. Below is an example configuration file of a

4-channel module at P09.

0;Clock;7

0;MCAmode;1

0;LemoInputMode;3

0;LEMOINPUT1ENABLE;1



0;LemoOutputMode;2

0;MCAScanNofHistogramsPreset;0

0;MCAScanLNESetup;0

0;MCAScanPrescalerFactor;0

0;MCAControlScanHistogramAutoclearDisable;0

0;MCAControlStartScanOnBank2;0

0;MCAMultiScanNofScansPreset;8

0;MCAMultiscanBusy;0

0;MCAScanBusy;0

1;ADCxInputInvert;0

1;TriggerInternalEnabled;1

1;TriggerExternalEnabled;0

1;TriggerADCNminus1NextNeighborEnabled;0

1;attr_TriggerADCNplus1NextNeighborEnabled_read;0

1;Trigger50kHzEnabled;0

1;GateInternalEnabled;0

1;GateExternalEnabled;0

1;GateADCNminus1NextNeighborEnabled;0

1;GateADCNplus1NextNeighborEnabled;0

1;TriggerPeakingTime;15

1;TriggerSumGTime;16

1;InternalTriggerPulseLength;3

1;InternalGateLength;15

1;InternalTriggerDelay;4

1;PretriggerDelay;17

1;TriggerGateLength;132

1;TriggerThresholdValue;13

1;TriggerOutEnabled;1

152

1;TriggerModeGTEnabled;1

1;EnergyPeakingTime;40

1;EnergyGapTime;10

1;EnergyTauFactor;0

1;EnergyGateLength;140

1;TriggerDecimationMode;0

1;EnergyDecimationMode;0

1;EnergySampleStartIndex1;1



1;EnergySampleLength;130

1;RawDataSampleLength;108

1;RawDataSampleStartIndex;0

1;EndAddressThreshold;0

1;HistogramSize;0

1;PileupEnabled;1

1;MemoryWriteTestMode;0

1;RawDataHistogrammingEnabled;0

1;EnergyMultiplier;128

1;EnergySubtractOffset;0

1;Energy2NDivider;2

1;DACOffset;10000

2;ADCxInputInvert;0











2;TriggerSumGTime;0




2;PretriggerDelay;17






2;EnergyGapTime;10

2;EnergyTauFactor;0











2;HistogramSize;0

2;PileupEnabled;1





2;Energy2NDivider;0

2;DACOffset;10000

3;ADCxInputInvert;0











3;TriggerSumGTime;0




3;PretriggerDelay;0






3;EnergyGapTime;0

3;EnergyTauFactor;0











3;HistogramSize;0

3;PileupEnabled;0





3;Energy2NDivider;0

3;DACOffset;10000

4;ADCxInputInvert;0











4;TriggerSumGTime;0




4;PretriggerDelay;0






4;EnergyGapTime;0

4;EnergyTauFactor;0











4;HistogramSize;0

4;PileupEnabled;0





4;Energy2NDivider;0

4;DACOffset;10000

The module needs a NIM gate, 3rd input control line. Load-next-event feature via 1st input control

line.

Attributes to be set:

Internal trigger enable 1 (IntTrig)

Interal gate enable 0 (IntGate)

External gate enable 0 (ExtGate)

trapezoidal threshold value 6

Data Length 1024 (DataLength)(4 digit multiple of base 2)

Two servers are involved to operate the SIS3302 FADC:

Figure 50.1: Properties SIS3302Client server

The base address 805306368 corresponds to 0x30000000.

Online can use the SIS3302 like any other MCA, if the following entry appears in /online dir/online.xml:


<hw>

...

<device>

<name>SIS3302</name>

<type>mca</type>

<module>mca_sis3302</module>

<device>p03/SIS3302Client/exp.02</device>


<hostname>haspp03nano:10000</hostname>

</device>

...

</hw>

The SIS3302 has lots of parameters that need to be configured properly for an optimal operation.

Martin Tolkiehn wrote an application, ADCgui, to support the configuration. ADCgui is indepen-

dent of Tango. It is started by:

Figure 50.2: Properties SIS3302 server

haspp03nano:˜/prog/ADCgui> ./ADCgui /tmp/sis1100_012remote

or

haspp09:˜/prog/ADCgui> ./ADCgui /tmp/sis1100_012remote

The command line parameter specifies the VME device. It might be necessay to try several devices

before a free device is found.

The incoming data is monitored, MCA mode is enabled in the General settings tab and MCA/Raw

Data checkbos is enables in the Control frame (lower right part of the widget).

In general the ADCgui application is used to load a configuration file and write the parameters

to the hardware. The Tango server reads the configuration from the SIS3302 ADC. In case of an

emergency a possible repair procedure can be: start the Tango server, then start ADCgui and load a

configuration, then start Online.

The histgramm size is changed in Online and by ADCGui: go to MCA settings and change the

Histogramm size.

In the following you find some ADCgui screen shots from P09.

Figure 50.3: SIS3302: ADCgui Screen 1






Chapter 51

SIS3600 (Input Register)

Input register: 32 TTL inputs. VME A24D32 2k at 0x010000. Jumper: J500 111, EN-A24, J A11

1, J520 1, all other pin pairs are open. Rotary switches 00010 (left to right, VME connectors are

right).

Power requirements: < 17.5 W, < 3.5 A at +5V.

Reading this input register returns a 32-bit word.

The SIS3600 is defined by:

define/dev=input_register/module=sis3600/base=0x10000/chan=0 latch1

The following piece of code shows how the value of a particular bit can be the return value of a

virtual counter:


{

return 1;

}


{

#

# 0 is the number of the first input channel (down-left)

#

my $bitno = 0;

return ((Spectra::rir( "latch1") >> $bitno) & 1);

}

51.1 Tango

The SIS3600 is operated by the SIS3610 Tango server. The property TypeSIS3600 is used to select

this module, see below. Here is an example for entries in /online dir/online.xml:

<device>

<name>ireg1</name>

<type>input_register</type>

<module>sis3600</module>

<device>flash/register/pgm1.in01</device>


164

<hostname>hasfpgm99:10000</hostname>

</device>

<device>

<name>ireg2</name>



<device>flash/register/pgm1.in02</device>


<hostname>hasfpgm99:10000</hostname>

</device>

...

Notice that the bit-shifting as described in the non-Tango part is no longer necessary because this

is done by the Tango server using the channel property.

SIS3610

PGM1

SIS3610

flash/register/in.01

Base: 69632 (== 0x11000)

Channel: 0

FlagInputOutput: 0

SimulationMode: 0

TypeSIS3600: 1

flash/register/in.02

Base: 69632 (== 0x11000)

Channel: 1

FlagInputOutput: 0

SimulationMode: 0

TypeSIS3600: 1

...

Chapter 52

SIS3610 (I/O Register)

The module has 16 input register and 16 outputs, TTL, Lemo, 50 Ohm. The outputs are the lower

16 connectors.

VME address space: 2 kB (0x7ff), default address mode: A24D32, default base address: 0x010000.

The configuration can is displayed in figures 52.1 and 52.2: SW A32U 0, SW A32L 0, SW A24U

0, SW A24L 1, SW A16U 0, J A11 closed. Jumper: EN A32 open, EN A24 closed, EN A16

open, J500 (boot file selection) shipped with closed, closed, open, J520 (SYSRESET behaviour)

closed: ’reset’ upon SYSRESET, shipped.

Jumpers J101, J102, J103, J104 set the impedance of the first four control input lines to 50 Ohm,

meaningless, if the SIS3610 is operated as an I/O register only. J105 - J108 have no meaning.

The module can be tested with these commands:

Read module ID:

* = hex(vme(a24d32, 0x10000, 0x4))

-> 0x36102000

Test: connect output-1 with input-1

vme(a24d32, 0x10000, 0xc) = 1

* = vme(a24d16, 0x10000, 0x10)

-> 1

vme(a24d32, 0x10000, 0xc) = 0x10000

* = vme(a24d16, 0x10000, 0x10)

-> 0

The devices are defined by:

define/dev=output_register/module=sis3610/base=0x10000/chan=0 oreg1

define/dev=output_register/module=sis3610/base=0x10000/chan=1 oreg2

...

define/dev=input_register/module=sis3610/base=0x10000/chan=0 ireg1

define/dev=input_register/module=sis3610/base=0x10000/chan=1 ireg2

...


<hw>

... other devices

<device>

<name>exp_in01</name>

166



<device>p09/register/exp.in01</device>



</device>

<device>

<name>exp_out01</name>

<type>output_register</type>


<device>p09/register/exp.out01</device>



</device>

</hw>

Figure 52.1: SIS3610, Total

Figure 52.2: SIS3610, Base Address

Chapter 53

SIS3820 (Multi Channel Scaler)

SIS3820 scaler, 64 MB SDRAM, 32 inputs, TTL (50 Ohm), 100 MHz max. count rate, 4 control

outputs, 4 control inputs.

The figures 53.1 and 53.2 show the configuration of the board: A32D32 at 0x38000000, rotary

switches 3800 (VME connectors point right), VME adr. space 16 MB, 8 MB page, J 1 1000, J90

0101, JP 570 up. A second SIS3820 card has the adress 0x39000000.

The INHIBIT signal (50 Ohm, TTL) is fed into input 3 (control line 3), see figure 53.3.

Power requirements: 5V.

A SIS3820 board is introduced to Online by:

define/dev=counter/mod=sis3820/base=0x38000000/vector=0/chan=0 c1

....

define/dev=counter/mod=sis3820/base=0x38000000/vector=0/chan=31 c32

SIS3820/DGG2 test: Connect the 1 MHz clock output of a DGG2 (’CLK OUT’) to input no. 1 of

the SIS3820. Convert the NIM gate of the DGG2 to TTL and thereby invert the signal. Connect

the NIM-TTL output with the control line 3 of the SIS3820.

If the board is used in a memory-mapped mode, using the mcs(), function, it has to be defined as

a single device.

define/dev=mcs/mod=sis3820/base=0x38000000/vector=0/chan=0 mcs1


<hw>

... other devices

<device>

<name>exp_c01</name>

<type>counter</type>


<device>p09/counter/exp.01</device>



</device>

<device>






169


</device>

<device>







</device>

</hw>

Figure 53.1: SIS3820, Total

Figure 53.2: SIS3820, Base Address

Figure 53.3: SIS3820, Inhibit

Chapter 54

Slits

Slits are introduced by the following assignments. They are part of /online dir/exp ini.exp

SLT1_BOTTOM = E2_MOT17

SLT1_TOP = E2_MOT18

SLT1_RIGHT = E2_MOT19

SLT1_LEFT = E2_MOT20

SLT2_BOTTOM = E2_MOT21

SLT2_TOP = E2_MOT22

SLT2_RIGHT = E2_MOT23

SLT2_LEFT = E2_MOT24

SLIT_NAMES = "SLT1, SLT2"

The coordinate system: z points in the direction of the photons, y points upwards, x completes the

right-handed coordinate system. ’right’ points in the x-direction, like in school.

173

Chapter 55

SMCHYDRA ( Tango)

These motors are introduced to Online by adding the following lines to /online dir/online.xml:

<device>

<name>mi_hyd_1</name>


<module>smchydra</module>

<device>p23/hydramotor/exp.01</device>



</device>

174

Chapter 56

Slt/Spk PLC, Beckhoff, Tango

Slt/Spk units control up to 4 axes by Beckhoff PLCs. The system was created by Jan Tolkiehn. It

is operated using Tango servers.

56.1 Spk, A1 (incl. screen shots)

The configuration at A1:

hasa1

a1/ads/sps1 131.169.225.48 hasa1mirr1.desy.de

a1/ads/sps2 131.169.225.49 hasa1mirr2.desy.de

a1/slt/mirr1xr a1/ads/sps1 chan 0

a1/slt/mirr1xt a1/ads/sps1 chan 1

a1/slt/mirr1yr a1/ads/sps1 chan 2

a1/slt/mirr1yt a1/ads/sps1 chan 3

a1/slt/mirr2xr a1/ads/sps2 chan 0

a1/slt/mirr2xt a1/ads/sps2 chan 1

a1/slt/mirr2yr a1/ads/sps2 chan 2

Here is the procedure how to create the Tango devices. Two PLCs are involved, one for mirr1 the

other for mirr2:

In the next step we create the Spk devices:

Note that the Spk server contains the Ads and the Spk classes.

Here are screen shots that show the properties of the PLC and SPK server at A1.

175

Figure 56.1: Spk create server

Figure 56.2: Spk create server

Figure 56.3: Properties of the PLC Server for the Spk, A1

Note that the PlcServer property of the Spk device selects the PLC.

After the server has been configured properly, the devices are introduced to Online (/online dir/online.xml):

<device>

<name>spk1xr</name>


<module>spk</module>

<device>a1/spk/mirr1xr</device>


<hostname>hasa1:10000</hostname>

</device>

<device>

<name>spk1xt</name>



<device>a1/spk/mirr1xt</device>



</device>

<device>

<name>spk1yr</name>



<device>a1/spk/mirr1yr</device>


Figure 56.4: Properties of the Spk Server, A1


</device>

<device>

<name>spk1yt</name>



<device>a1/spk/mirr1yt</device>



</device>

<device>

<name>spk2xr</name>



<device>a1/spk/mirr2xr</device>



</device>

<device>

<name>spk2xt</name>



<device>a1/spk/mirr2xt</device>



</device>

<device>

<name>spk2yt</name>



<device>a1/spk/mirr2yt</device>



</device>

56.2 Slt, P01

The configuration at P01:

haspp01eh1

p01/ads/sps1 192.168.34.151 haspp01sltv.desy.de

p01/ads/sps2 192.168.34.152 haspp01sltvh.desy.de

p01/slt/exp.01 p01/ads/sps1 chan 0 slt1vgap

p01/slt/exp.02 p01/ads/sps1 chan 1 slt1voffs

p01/slt/exp.03 p01/ads/sps2 chan 0 slt2hleft

p01/slt/exp.04 p01/ads/sps2 chan 1 slt2right



The entries in /online dir/online.xml:

<device>

<name>slt1vgap</name>



<device>p01/slt/exp.01</device>



</device>

<device>

<name>slt1voffs</name>






</device>

<device>

<name>slt2hleft</name>






</device>

<device>

<name>slt2hright</name>






</device>

<device>







</device>

<device>







</device>

56.3 Slt, P02 (incl. screen shots)


haspp02oh1:






p02/slt/exp.04 p02/ads/sps2 chan 1 slt2hright



p02/slt/exp.07 p02/ads/sps1 chan 2 slt1vgap (used by P03)

p02/slt/exp.08 p02/ads/sps1 chan 3 slt1voffs (used by P03)

Slit 1 of beamlines P02/P03 is controlled by the same PLC. The server for the PLC runs on

haspp02oh1.

The first four screen shots show how the servers are created. haspp02oh1 runs two PLC server,

p02/ads/sps1 and /p02/ads/sps2. Sps1 talks to the PLC that is used by both beamlines.

Figure 56.5: Slt/Spk create server, P02

Figure 56.6: Ads: add class to Spk, P02

The next screen shots show the server properties. The detailed property values can be found further

down in this section.

/online dir/online.xml on haspp02ch1a:

<device>







</device>

<device>




Figure 56.7: Properties of the PLC Server for the Slt/Spk, P02




</device>

<device>

<name>slt2left</name>






</device>

<device>

<name>slt2right</name>






</device>

<device>




Figure 56.8: Properties of the Slt/Spk Server, P02




</device>

<device>

<name>slt2offs</name>






</device>

56.4 Slt/Spk, P03 (incl. screen shots)


haspp03


p03/ads/sps4 192.168.51.125 haspp03mirr12.desy.de





p03/spk/exp.07 p03/ads/sps3 chan 0 m1pitch

p03/spk/exp.08 p03/ads/sps3 chan 1 m1transx

p03/spk/exp.09 p03/ads/sps3 chan 2 m1transy




Slit 1 of beamlines P02/P03 is controlled by the same PLC. The server for the PLC runs on haspp02.

Figure 56.9: Slt/Spk create server, P03

Figure 56.10: Ads: add class to Spk, P03

The next screen shots show the server properties. The detailed property values can be found further

down in this section.

/online dir/online.xml on haspp03, notice that 2 axes are imported from P02:

<device>

Figure 56.11: Properties of the PLC Server for the Slt/Spk, P03







</device>

<device>







</device>

<device>







</device>

<device>

Figure 56.12: Properties of the Slt/Spk Server, P03







</device>

<device>







</device>

<device>







</device>

<device>

<name>m1pitch</name>



<device>p03/spk/exp.07</device>



</device>

<device>

<name>m1transx</name>






</device>

<device>

<name>m1table</name>






</device>

<device>







</device>

<device>

<name>m2transx</name>






</device>

<device>

<name>m2table</name>






</device>

56.5 Spk, P04


haspp04exp2











p04/spk/exp.01 p04/ads/sps3 chan 0 m1trans

p04/spk/exp.02 p04/ads/sps3 chan 1 m1rot

p04/spk/exp.03 p04/ads/sps3 chan 2 m2trans

p04/spk/exp.04 p04/ads/sps3 chan 3 m2rot


p04/spk/exp.06 p04/ads/sps4 chan 1 m3roty


56.6 Slt, P05, P06

The configuration at P05, P06:

hasgksspp05t01:

p05/ads/sps1 192.168.34.159 haspp05sltvh.desy.de.





haspp06mono












p06/spk/exp.01 p06/ads/sps3 chan 0 Schlitten 1

p06/spk/exp.02 p06/ads/sps3 chan 1 Schlitten 2

p06/spk/exp.03 p06/ads/sps3 chan 2 Rotation 1

p06/spk/exp.04 p06/ads/sps3 chan 3 Rotation 2

p06/spk/exp.05 p06/ads/sps3 chan 4 Hubtisch

Slit 1 of beamlines P05/P06 is controlled by the same PLC. The server for the PLC runs on

haspp06mono.

/online dir/online.xml on haspp06ctrl:

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>

/online dir/online.xml on hasgksspp05t01:


<hw>

<device>






<hostname>hasgksspp05t01:10000</hostname>

</device>

<device>







</device>

<device>

<name>slt2gap</name>






</device>

<device>

<name>slt2offset</name>






</device>

<device>

<name>slt1gap</name>





<hostname>haspp06mono:10000</hostname>

</device>

<device>

<name>slt1offset</name>





<hostname>haspp06mono:10000</hostname>

</device>

</hw>

56.7 Slt, P07 (incl. screen shots)

This is the configuration at P07:

hasgksspp07eh3:









slt1vgap, etc. are logical names which are used in Spectra, see below.


<device>






<hostname>hasgksspp07eh3:10000</hostname>

</device>

<device>







</device>

Figure 56.13: Properties of the PLC Server for the Slt, P07

<device>







</device>

<device>







</device>

<device>







</device>

Figure 56.14: Properties of the Slt Server, P07

<device>







</device>

56.8 Slt, P08


haspp08:






haspp09:



At P08 and P09 we have the situation that the 192.168.34.163 PLC controls 4 axes which move 2

slits of different beamlines. The way how we deal with it is to define all 4 channels of 192.168.34.163

on haspp09 and refer to p09/slt/exp.07 and p09/slt/exp.08 in haspp08:/online dir/online.xml. Like-

wise the file haspp09:/online dir/online.xml ignores p09/slt/exp.07 and p09/slt/exp.08.

Here is the interesting part of haspp08:/online dir/online.xml. Notice how slt1vgap and slt1voffs

are to device servers that run on haspp09.

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>



haspp09














p09/spk/exp.02 p09/ads/sps3 chan 1 m1x

p09/spk/exp.03 p09/ads/sps3 chan 2 m1yaw

p09/spk/exp.04 p09/ads/sps3 chan 3 m1y


p09/spk/exp.06 p09/ads/sps4 chan 1 m2x

p09/spk/exp.07 p09/ads/sps4 chan 2 m2yaw

p09/spk/exp.08 p09/ads/sps4 chan 3 m2y

p09/spk/exp.08 p09/ads/sps4 chan 4 m2bender

At P08 and P09 we have the situation that the 192.168.34.163 PLC controls 4 axes which move 2

slits of different beamlines. The way how we deal with it is to define all 4 channels of 192.168.34.163

on haspp09 and refer to p09/slt/exp.07 and p09/slt/exp.08 in haspp08:/online dir/online.xml. Like-

wise the file haspp09:/online dir/online.xml ignores p09/slt/exp.07 and p09/slt/exp.08.

We add a class to the server:

We instruct the Ads class where to connect:

We assign the axes to PLCs and channels:

Here is the interesting part of haspp09:/online dir/online.xml.

<device>

Figure 56.15: Spk create server, Ads, P09

Figure 56.16: Spk create server, Spk, P09







</device>

<device>







</device>

Figure 56.17: Spk server properties, Ads class, P09

<device>







</device>

<device>







</device>

<device>







Figure 56.18: Spk server Properties, Spk class, P09

</device>

<device>







</device>

<device>







</device>

<device>

<name>m1x</name>






</device>

<device>

<name>m1yaw</name>






</device>

<device>

<name>m1y</name>






</device>

<device>







</device>

<device>

<name>m2x</name>






</device>

<device>

<name>m2yaw</name>






</device>

<device>

<name>m2y</name>






</device>

<device>

<name>m2bender</name>






</device>


Here is the configuration at P10:

haspp10e2

p10/ads/sps4 192.168.51.128 haspp10girder.desy.de

p10/spk/exp.07 p10/ads/sps4 chan 0 transx1

p10/spk/exp.08 p10/ads/sps4 chan 1 transx2

p10/spk/exp.09 p10/ads/sps4 chan 2 transy1

p10/spk/exp.10 p10/ads/sps4 chan 3 transy2

constraint: x1, x2 and y1, y2 should have the same position

the multiple motors devices:

p10/multiplemotors/opt.02 moves x1 and x2

p10/multiplemotors/opt.03 moves y1 and y2






p10/spk/exp.05 p10/ads/sps3 chan 4 mtransy

haspp10opt









P10 has slits and a mirror that are controlled by the Slt (aka Spk) server. The following screen shots

refer to the Slt configuration. The Spk configuration is very much the same.

Figure 56.19: Slt create server, P10

Figure 56.20: Ads: add class to Slt, P10

Figure 56.21: Properties of the PLC Server for the Slt, P10



<device>







</device>

<device>







</device>

<device>







Figure 56.22: Properties of the Slt Server, P10

</device>

<device>







</device>

<device>







</device>

<device>







</device>

56.11 Slt, P11


haspp11oh:











<device>






<hostname>haspp11oh:10000</hostname>

</device>

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>

<device>







</device>

Chapter 57

T95 Linkam Temperature Controller,

hasbw5, hasgksspp07eh2a

This is an implementation of an interface to the T95 temperature controller. The communica-

tion functions and the assignments that create the beamline-specific code widget are part of /on-

line dir/TkIrc.pl.

It is also demonstrated how the T95 functionality is made available from the Online command line,

see below.

#

#

#

package T95;

use strict;

use IO::Socket::INET;

use IO::Select;

use Spectra;

# bw5 hastXX.desy.de 4504

# test hasptXX 10032

our $node = "hasptsXX.desy.de";

our $port = 10032;

sub openT95

{

my $status = 1;

$Util::res_h{ sockT95} = IO::Socket::INET->new(PeerAddr => $node,

PeerPort => $port,

Proto => ’tcp’,

Type => SOCK_STREAM);

if( !$Util::res_h{ sockT95})

{

$status = Spectra::error( "openT95: failed to connect to $node port

goto finish;

}

finish:

return $status;

206

}

sub sendT95

{

my ( $argin) = @_;

my $status = 1;

if( !defined( $Util::res_h{ sockT95}))

{

if( !openT95())

{

$status = Spectra::error( "sendT95: openT95 returned error");

goto finish;

}

}

$argin =˜ s/ˆ\s*(.*?)\s*$/$1/;

# print "sendT95: $argin \n";

$argin .= "\015";

$status = $Util::res_h{ sockT95}->send( $argin);

finish:

return $status;

}

sub recvT95

{

my $argout;

my $status = 1;

if( !defined( $Util::res_h{ sockT95}))

{

if( !openT95())

{

$status = Spectra::error( "recvT95: openT95 returned error");

goto finish;

}

}

my $s = new IO::Select();

$s->add( $Util::resh_h{ sockT95});

$argout = "";

my $buffer; ˜/Spectra/src/

while( !length( $argout) || $s->can_read(0.1))

{

$Util::res_h{ sockT95}->recv( $buffer, 100);

$argout .= $buffer;

$buffer = "";

}

my $temp = $argout;

$temp =˜ s/ˆ\s*(.*?)\s*$/$1/;

# print "recvT95: $temp \n";

return $argout;

}

sub closeT95

{

close($Util::res_h{ sockT95});

delete $Util::res_h{ sockT95};

}

sub getT95status

{

sendT95( "T");

my $res = recvT95();

my @list = unpack( "C*", $res);

return $list[0];

}

sub getT95error

{

sendT95( "T");



return $list[1];

}

sub getT95pumpStatus

{

sendT95( "T");



return $list[2];

}

sub getT95genStatus

{

sendT95( "T");



return $list[3];

}

#

# map [0xf858, 0x3a98] to [-196, 1500]

#

#

sub getT95temperature

{

sendT95( "T");


my $temp = "0x" . substr( $res, 6, 4);

$temp = hex($temp);

if( $temp & 0x8000)

{

$temp -= 65536;

}

return $temp*0.1;

}

#

# the commands

#

sub cmdT95

{

my ($keyword, $value) = @_;

my $status;

#

# rate: R1

#

if( $keyword =˜ /rate/i && length( $value))

{

$value = int( 100*$value + 0.5);

sendT95( "R1${value}");

}

#

# limit: L1

#

elsif( $keyword =˜ /limit/i && length( $value))

{

$value = int( 10*$value + 0.5);

sendT95( "L1${value}");

}

#

# start: S

#

elsif( $keyword =˜ /start/i)

{

sendT95( "S");

}

#

# stop: E

#

elsif( $keyword =˜ /stop/i)

{

sendT95( "E");

}

#

# hold: O

#

elsif( $keyword =˜ /hold/i)

{

sendT95( "O");

}

#

# heat: H

#

elsif( $keyword =˜ /heat/i)

{

sendT95( "H");

}

#

# cool: C

#

elsif( $keyword =˜ /cool/i)

{

sendT95( "C");

}

#

# automatic mode: Pa

#

elsif( $keyword =˜ /auto/i)

{

sendT95( "Pa");

}

#

# manual mode: Pm

#

elsif( $keyword =˜ /manual/i)

{

sendT95( "Pm");

}

#

# speed: P0 - PN

#

elsif( $keyword =˜ /speed/i)

{

if( $value < 0 || $value > 30)

{

print " speed: value out of range $value \n";

$status = 0;

goto finish;

}

my $let = pack( "C", $value + 48);

sendT95( "P${let}");

}

finish:

return $status;

}

$Spc::res_h{ t95_title } = { text => "T95 Temperature Controller"};

$Spc::res_h{ t95_help} = sub

{

Util::display_text( "Help T95",

’

Speed: 0 - 30

’

)};

$Spc::res_h{ t95_io1 } = { label => { name => "Temperature",

get => sub { T95::getT95temperature();}}};

$Spc::res_h{ t95_io2 } = { label => { name => "Status",

get => sub { T95::getT95status();}}};

$Spc::res_h{ t95_io3 } = { label => { name => "Error",

get => sub { T95::getT95error();}}};

$Spc::res_h{ t95_io4 } = { label => { name => "Gen. Status",

get => sub { T95::getT95genStatus();}}};

$Spc::res_h{ t95_io5 } = { label => { name => "Rate",},

entry => { set => sub {T95::cmdT95( "rate", $_[0]);}}};

$Spc::res_h{ t95_io6 } = { label => { name => "Limit",},

entry => { set => sub {T95::cmdT95( "limit", $_[0]);}}};

$Spc::res_h{ t95_io7 } = { label => { name => "Speed",

get => sub { T95::getT95pumpStatus()

entry => { set => sub { T95::cmdT95( "speed", $_[0]);}}};

$Spc::res_h{ t95_b1} = { name => "Start",

command => sub { T95::cmdT95( "start")}};

$Spc::res_h{ t95_b2} = { name => "Stop",

command => sub { T95::cmdT95( "stop")}};

$Spc::res_h{ t95_b3} = { name => "Hold",

command => sub { T95::cmdT95( "hold")}};

$Spc::res_h{ t95_b4} = { name => "Heat",

command => sub { T95::cmdT95( "heat")}};

$Spc::res_h{ t95_b5} = { name => "Cool",

command => sub { T95::cmdT95( "cool")}};

$Spc::res_h{ t95_b6} = { name => "Auto",

command => sub { T95::cmdT95( "auto")}};

$Spc::res_h{ t95_b7} = { name => "Manual",

command => sub { T95::cmdT95( "manual")}};

The temperature controller can also be operated from the Online command line. The syntax is, e.g.,

”t95 start”. The string t95 is a symbol which is defined in /online dir/exp ini.exp. It points to a Perl

script:

#!/bin/env perl

#

# file: ˜/prog/t95.pl

#

# needs this symbol assignment in exp_ini.exp

#

# t95 = "perl <˜.prog>t95.pl"

#

use Spectra;

my ( $keyword, $value) = @ARGV;

my $status = 1;

sub print_usage

{

print "\n\n Usage: \n";

print " t95 cool \n";

print " t95 heat \n";

print " t95 start \n";

print " t95 stop \n";

print " t95 limit 60 \n";

print " t95 rate [1,120] [C/min] \n";

print " t95 speed [0,30] \n";

print "\n\n\n";

}

if( !defined( $keyword))

{

$status = 0;

print_usage();

goto finish;

}

if( $keyword =˜ /gettemperature/i)

{

$Spectra::SYM{ t95_temperature} = T95::getT95temperature();

goto finish;

}

if( $keyword =˜ /cool/i)

{

T95::cmdT95( "cool");

goto finish;

}

if( $keyword =˜ /heat/i)

{

T95::cmdT95( "heat");

goto finish;

}

if( $keyword =˜ /start/i)

{

T95::cmdT95( "start");

goto finish;

}

if( $keyword =˜ /stop/i)

{

T95::cmdT95( "stop");

goto finish;

}

if( $keyword =˜ /limit/i)

{


{

$status = 0;

print_usage();

goto finish;

}

T95::cmdT95( "limit", $value);

goto finish;

}

if( $keyword =˜ /rate/i)

{


{

$status = 0;

print_usage();

goto finish;

}

if( $value < 0 || $value > 120)

{

$status = 0;

print_usage();

goto finish;

}

T95::cmdT95( "rate", $value);

goto finish;

}

if( $keyword =˜ /speed/i)

{


{

$status = 0;

print_usage();

goto finish;

}

if( $value < 0 || $value > 30)

{

$status = 0;

print_usage();

goto finish;

}

T95::cmdT95( "speed", $value);

goto finish;

}

print "\n\n T95.pl: failed to identify $keyword $value \n\n\n";

finish:

$status;

Chapter 58

Tango, Sardana, Attribute as a Counter

An attribute can be made available as a counter by adding an entry to /online dir/online.xml:

<device>

<name>double_scalar</name>


<module>tangoattributectctrl</module>

<device>sys/tg_test/1/double_scalar</device>


<hostname>hasXXX:10000</hostname>

</device>

The device double scalar will be created by the next SardanaAIO.py -x.

214

Chapter 59

Tango, AttributeMotor

There is the class AttributeMotor that allows us to treat an arbitrary attribute as a motor. Here is an

example for a configuration:

Figure 59.1: Jive: The configuration of an AttributeMotor, P07

This motor is introduced to Online by these lines (/online dir/online.xml).

<name>gap</name>





<hostname>hasgksspp07eh2a:10000</hostname>

</device>

215

Chapter 60

Tango, Generic Device

The following lines introduce a generic Tango device:

<hw>

<device>

<name>dac2</name>



<device>hires/exp/dac2</device>



</device>

</hw>

These lines are part of /online dir/online.xml, the Tango configuration file for Online. It is loaded

by the statement:

Spectra::load_configuration();

This statement is usually the last command of /online dir/TkIrc.pl.

The generic Tango device type has been invented for debugging and testing. After it has been

defined, the Tango attribute and command functions can be used to operate it. Here is an example:

tng_attrDoubleWrt( "dac2", "VoltageMax") = 8

tng_attrDoubleWrt( "dac2", "Voltage") = 1

* = tng_attrDoubleRd( "dac2", "Voltage")

Note: This example is just for demonstration. A DAC can be operated by other function, e.g.:

set dac voltage().

216

Chapter 61

Tango, Generic Motor

There are various servers that export ’movables’. If they implement the motor tango interface, they

can be introduced to Online by using motor tango as a module specification, like in the following

example (/online dir/online.xml):

<device>







</device>

As in this example, monochromators are good candidates for being operated as motor tango mod-

ules. It is important to use mnchrmtr as the alias because Online uses this name in the monochro-

mator functions.

Details about this interface can be found in our Tango manual.

217

Chapter 62

Tango, Monochromator, BLEnergy

The online functions that operate the monochromator use the name mnchrmtr to refer to the mono-

chomator server. Here is an example (/online dir/online.xml):

<device>




<device>p08/blenergy/exp.01</device>



</device>

A mnchrmtr server has to export:

Attributes

Position

PositionSim

ResultSim

UnitLimitMin

UnitLimitMax

Commands

Calibrate

StopMove

There are beamlines which need several servers to control the energy, e.g. FMB-DCM, Lom, Un-

dulator. For these cases the BLEnergy class has been implemented. It exports the above mentioned

interface and it has properties (MasterDevice, SlaveDevices) which allow the specification of sev-

eral servers. Each of these servers exports the same interface. Below you find an example for a

property list.

218

Figure 62.1: Jive: BLEnergy Server Properties at P08

Chapter 63

TcpIpMotorP10

The TcpIpMotorP10 is a special implementation of the generic TangoMotor interface. The Tango

server communicates via TCP/IP with some other motor server using a simple protocol. This is the

syntax:

calibrate <position>

answer: DONE / ERROR

position <position>


position?

answer: <position>

unitLimitMin <position>


unitLimitMin?

answer: <position>

unitLimitMax <position>


unitLimitMax?

answer: <position>

state?

returns a number which is interpreted as a bit mask.

The meaning of the bits is:

Bit 0: 0 = idle, 1 = moving

Bit 1: 0 = no error, 1 = error

Bit 2: 1 = lower limit reached (ccw)

Bit 3: 1 = upper limit reached (cw)

e.g.:

0 -> IDLE, no error, no limit

1 -> MOVING, no error, no limit

4 -> IDLE, ccw limit

stopMove

220


The first external server was written by Andreas Malecki (IMETUM, Uni-Munich) for a Newport

motor.

A TcpIpMotorP10 device can be introduced to Online by (/online dir/online.xml):

<device>

<name>newport01</name>



<device>p10/tcpipmotorp10/exp.01</device>


<hostname>hasppXX:10000</hostname>

</device>

Figure 63.1: Jive: TcpIpMotorP10 Server Properties at P10

Chapter 64

TIP551-10 (DAC, 16 Bit, 4 Channel, TEWS)

Digital-analog converter: 4 DA channel, 16 bit, range: [0,10V] or [-10, 10], conversion time 10

microsec, output current ± 4 mA.

Note: the noise level of the output may be reduced considerably by adding a capacitor, e.g. 20

microFarad has been used at P3P10.

Carrier TVME200-10: S1 = 0, S2 = 8 (0x0800), S2 can be 0, 4, 8, C only, S4: A24/A32 memory

enable and size, S4 = 0 - A24/A32 memory disabled, S4 = 1 - A24, 128 kB, 32 bK/IP, S4 = 2 - A24,

256 kB, 64 kB/IP, S5, S6: A24/A32 base address, def: 0xd00000 (A24), 0x00000000 (A32), S5:

A[23:20], S6: A[19:16] for A24, S5: A[31:28], S6: A[27:24] for A32, memory must be boundary

aligned with S4, power requirements: 300mA at 5V, 1 mA at +12V, 1mA at -12V (figures 64.1 and

64.2).

Mode selection: The TIP551 can be operated in the modes [0V, 10V] and [-10V, 10V]. The selec-

tion is done by jumper J1 which is on the IP board. J1 is accessible only, if the IP board is removed

from the carrier board. J1: 1-2: [0, 10V] (factory set), 2-3: [ -10V, 10V]. Pin ’3’ is nearer to the

edge than ’1’. Depending on the selected mode, the corresponding range has to be specified in

Online:

Tango: the properties RangeMin and RangeMax are by default 0 and 10 and they need not be

defined in the default hardware configuration. They have been implement to reflect the jumper

setting.

Range: 0 to 10 V

sdvli(dac1) = 0

sdvla(dac1) = 10

Tango: Set the properties RangeMin to 0 and RangeMax to 10.

Range: -10 to 10 V

sdvli(dac1) = -10

sdvla(dac1) = 10

Tango: Set the properties RangeMin to -10 and RangeMax to 10.

It is important to note that, that the DAC voltage limits have two meanings:

• the output voltage is limited

• the spread of the output signal is adjusted: if J1 selects the [-10V,10V] range, the lower limit

has to be less that 0. If J1 selects the [0,10V] range, the lower limit has to be greater-equal 0.

The ’1’ of the ribbon cable is at the bottom of the TVME-200 connectors, at the left of the patch

board connectors.

222

Figure 64.1: TVME200 with TIP830 (ADC, right, slot A) and TIP551 (DAC, left, slot C)

Carrier: VIPC616, A16D16 1k at 0x800 base (every piggy back uses 256B), base2 0x0. Jumpers:

E3.7-E7.7 1111011 (from left to right, VME connectors point downwards), A24, E20.8-E21.8

11101111 (A23-A17, 0x10 00 00, parking position, avoids collisions with V260 I/Os), the other

jumpers remain in the default position. VIPC616 power requirements: 0 mA at 12V, 0 mA at -12V,

610 mA at 5V.

Power requirements: 430 mA at 5V.

!

! ’0xa00’ corresponds to position ’C’

!

def dac1/module=tip551/dev=dac/base=0xa00/chan=0





<hw>

... other devices

<device>

<name>exp_dac01</name>

<type>dac</type>

<module>tip551</module>

<device>p09/dac/exp.01</device>


Figure 64.2: TVME200 with TIP830 (ADC) and TIP551 (DAC), detail


</device>

<device>


<type>dac</type>





</device>

<device>


<type>dac</type>





</device>

<device>


<type>dac</type>





</device>

Figure 64.3 shows the combined resolution of the TIP551 (DAC) and TIP830-20 (ADC) as a func-

tion of voltage.

1 3 5 7 9−0.4

−0.3

−0.2

−0.1

0.0

0.1

0.2

0.3

0.4VC1 (TIP830 x TIP551)dU/U [%]

Figure 64.3: TIP830 (ADC) vs. TIP551 (DAC)

Chapter 65

TIP830-20 (ADC, 16 Bit, 8 Channel, TEWS)

Analog-digital converter: 8 channel, 16 bit, 305 muV, range: [-10V,10V], impedance 45 kOhm,

INL 40k sample per second, power requirements: 130 mA at 5V, 18 mA at 12V, external trigger:

TTL, open collector.

Carrier TVME200-10: S1 = 0, S2 = 8 (0x0800), S2 can be 0, 4, 8, C only, S4: A24/A32 memory

enable and size, S4 = 0 - A24/A32 memory disabled, S4 = 1 - A24, 128 kB, 32 bK/IP, S4 = 2 - A24,

256 kB, 64 kB/IP, S5, S6: A24/A32 base address, def: 0xd00000 (A24), 0x00000000 (A32), S5:

A[23:20], S6: A[19:16] for A24, S5: A[31:28], S6: A[27:24] for A32, memory must be boundary

aligned with S4, power requirements: 300mA at 5V, 1 mA at +12V, 1mA at -12V (figures 65.1 and

65.2).

Carrier: VIPC616, A16D16 1k at 0x800 base (every piggy back uses 256B), base2 0x0. Jumpers:

E3.7-E7.7 1111011 (from left to right, VME connectors point downwards), A24, E20.8-E21.8

11101111 (A23-A17, 0x10 00 00, parking position, avoids collisions with V260 I/Os), the other

jumpers remain in the default position. VIPC616 power requirements: 0 mA at 12V, 0 mA at -12V,

610 mA at 5V.

The ’1’ of the ribbon cable is at the bottom of the TVME-200 connectors, at the left of the patch

board connectors.

!

! ’0x800’ corresponds to position ’A’

!

def adc1/module=tip830/dev=adc/base=0x800/chan=0









<hw>

... other devices

<device>

<name>exp_adc01</name>

<type>adc</type>


<device>p09/adc/exp.01</device>

226



</device>

<device>


<type>adc</type>





</device>

<device>


<type>adc</type>





</device>

<device>


<type>adc</type>





</device>

<device>


<type>adc</type>





</device>

<device>


<type>adc</type>





</device>

<device>


<type>adc</type>





</device>

<device>


<type>adc</type>





</device>

</hw>

Figure 64.3 shows the combined resolution of the TIP551 (ADC) and TIP830-20 (ADC) as a func-

tion of voltage.

Figure 65.1: TVME200 with TIP830 (ADC, right, slot A) and TIP551 (DAC, left, slot C)

Figure 65.2: TVME200 with TIP830 (ADC) and TIP551 (DAC), detail

Chapter 66

TIP850-10 (ADC/DAC, 12 Bit, TEWS)

Analog-digital digital-analog converter: 8 differential AD channel, 4 DA channel, 12b.

TVME200-10, see figures 66.1 and 66.2: S1 = 0, S2 = 8 (0x0800), S2 can be 0, 4, 8, C only, S4:

A24/A32 memory enable and size, S4 = 0 - A24/A32 memory disabled, S4 = 1 - A24, 128 kB,

32 bK/IP, S4 = 2 - A24, 256 kB, 64 kB/IP, S5, S6: A24/A32 base address, def: 0xd00000 (A24),

0x00000000 (A32), S5: A[23:20], S6: A[19:16] for A24, S5: A[31:28], S6: A[27:24] for A32,

memory must be boundary aligned with S4,

The TIP850/TVME200 power requirements: 300mA at 5V, 1 mA at +12V, 1mA at -12V.

VIPC616, A16D16 1k at 0x800 base (every piggy back uses 256B), base2 0x0. Jumpers: E3.7-

E7.7 1111011 (from left to right, VME connectors point downwards), A24, E20.8-E21.8 11101111

(A23-A17, 0x10 00 00, parking position, avoids collisions with V260 I/Os), the other jumpers

remain in the default position. VIPC616 power requirements: 0 mA at 12V, 0 mA at -12V, 610 mA

at 5V.

The TIP850/VIPC616 power requirements: 250 mA at 5V, 70 mA at 12V, 35 mA at -12V

A TIP850-10 with differential inputs is introduced to Online by:

define/dev=adc/mod=tip850/base=0x800/vector=0/chan=0 adc1








define/dev=dac/mod=tip850/base=0x800/vector=0/chan=0 dac1




For the single-ended operation the following definitions are used:

define/dev=adc/mod=tip850/base=0x800/vector=0/chan=0 adcs1








230













Figure 66.1: TVME200 - TIP850, Total, Base: 0x800

66.1 TIP850, Tango

The TIP850u10 server has the classes TIP850ADC and TIP850DAC.

TIP850u10

DIAG99

TIP850ADC

p99/tip850adc/exp.01

Base: 2048

Channel: 0

Figure 66.2: TVME200 - TIP850, Detail

DeviceSpecial: 0 (differential inputs)

p99/tip850adc/exp.02

Base: 2048

Channel: 1

DeviceSpecial: 0

p99/tip850adcs/exp.01

Base: 2304

Channel: 0

DeviceSpecial: 1 (single ended inputs)

TIP850DAC

p99/tip850dac/exp.01

Base: 2048

Channel: 0

DeviceSpecial: 0

...

TIP850DAC


Base: 2304

Channel: 0

DeviceSpecial: 0

...

TIP850DAC


Base: 2560

Channel: 0

DeviceSpecial: 0

Here is an example for entries in /online dir/online.xml:

<device>


<type>adc</type>

<module>tip850adc</module>

<device>p99/tip850adc/exp.01</device>


<hostname>hasep99:10000</hostname>

</device>

...

<device>


<type>dac</type>

<module>tip850dac</module>

<device>p99/tip850dac/exp.01</device>


<hostname>hasep99:10000</hostname>

</device>

...

Chapter 67

TwoThetaP07

At P07 the two-theta angle corresponds to a translation and 3 rotations. A special Tango server has

been created to server this purpose.

<device>

<name>tth</name>



<device>p07/twotheta/eh2a.01</device>


<hostname>hasgksspp07eh2a:10000</hostname>

</device>

Figure 67.1: Jive: Properties of the TwoThetaP07 server

234

Figure 67.2: Jive: The attributes the TwoThetaP07 server

Here is the list of the attributes:

We have the following relations for a requested tth value at a specific energy:

#define LAMBDA_TO_E 12398.424

#define RAD_TO_DEGREE 57.295780

xdt AxisTranslationDetector

rdt AxisRotationDetector

rcoll AxisRotationCollimator

oman AxisRotationAnalyzer

l AxisDistanceSampleDetector

--- setting a new tth

theta_ana = RAD_TO_DEGREE* asin( 12398.424/E/2/d)

E [eV]

d [Angstr.]

if FlagUseAnalyzer

rdt = tth + 2*theta_ana

rcoll = -2*theta_ana

oman = theta_ana

xdt = -l*tan( tth/RAD_TO_DEGREE)

else

rdt = tth

rcoll = 0

oman = 0

xdt = -l*tan( tth/RAD_TO_DEGREE)

--- reading tth

tth = RAD_TO_DEGREE * atan( -xdt/l);

Note that there is a beamline-specific-code widget for the device which is described in the Online

-tki manual.

Chapter 68

Undulator, Tango

68.1 Petra3Undulator server

The undulator server is introduced to Online by the following lines in /online dir/online.xml:

<device>

<name>undulator</name>



<device>p09/undulator/1</device>



</device>

The position attribute of the undulator device corresponds to the energy. If this attribute is changed,

the server calculates a gap for the requested energy and moves the device.

It is also possible to access the undulator gap directly. The section 68.2 explains how this is done

with an attribute motor.

The following figures display the properties of the Petra3Undulator server. The first figure shows

the TINE path, the second the direct Ads path.

The PlcUndulator server is configured this way:

If the Petra3Undulator server uses the TINE path, we need an instance of the Tine-To-Tango gate-

way:

The gap is one of the attributes:

Section 68.3 shows how to use the TINE instant client to read the undulator gap positions.

68.2 Petra3Undulator gap, attribute motor

The undulator gap is introduced to Online as an attribute motor.

<device>

<name>gap</name>






</device>

The following figure displays the properties.

237

Figure 68.1: Jive: Petra3Undulator properties using TINE path

68.3 Instant TINE Client access to the undulator

The following image displays the TINE Instant client display for the connection status.

The following image displays the TINE Instant client display for the undulator CDI.

68.4 A virtual motor to move the gap, obsolete

If the gap of the undulator has to be moved/scanned, a virtual motors needs to be installed:

#!/usr/bin/perl -w

#

my ($method, $value_new) = @ARGV;

my $status = 1;

if( $method eq "set_position")

{

$status = Spectra::tng_attrFloatWrt( "Undulator", "Gap", $value_new);

#

# takes some time for the undulator to change state to MOVING (6)

#

sleep(2);

my $startTime = Spectra::Secnds();

while( Spectra::tng_state( "Undulator") == 6)

Figure 68.2: Jive: Petra3Undulator properties using the direct Ads path

{


#

# refresh motor positions and sense ’Stop’ clicks

#

Util::refresh();

if( (Spectra::secnds() - $startTime) > 20)

{

$status = Spectra::error( "vm1: move didn’t finish within 20s");

goto finish;

}

}

}

elsif( $method eq "get_position")

{

$SYM{RETURN_VALUE} = Spectra::tng_attrFloatRd( "Undulator", "Gap");

}

elsif( $method eq "get_limit_min")

{

$SYM{RETURN_VALUE} = 11.1;

}

elsif( $method eq "get_limit_max")

{

$SYM{RETURN_VALUE} = 220.

}

Figure 68.3: Jive: PlcUndulator properties

elsif( $method eq "exec_stop")

{

$status = Spectra::tng_inout( "Undulator", "StopMove");

}

finish:

$status;

Figure 68.4: Jive: PlcUndulator properties, Ads class

Figure 68.5: Jive: TTTGW for the Undulator

Figure 68.6: Jive: TTTGW Undulator Attributes

Figure 68.7: Jive: AttributeMotor properties, undulator gap

Figure 68.8: Undulator, instant TINE Client displays the connection status

Figure 68.9: Undulator, instant TINE Client displays CDI gap reading

Chapter 69

V260 (Scaler, CAEN)

Counter module: 16 TTL counter inputs (50 Ohm), 24 bits each, NIM inhibit input (-0.8V, 50

Ohm). VME A24D16, 256B at 0x100. Rotary switches: 0001 (VME connectors point upwards,

marked corner up-right). Changeover switches (24 bit mode): dudududu, four groups, (d - down, u

- up, VME connectors pointing rightwards). SW1-3 select the VME interrupt level (net needed).

The V260T power requirements are: 1.8A at 5V.

The counter is operated as follows: The NIM gate signal of a V462 or a DGG is inverted (N454)

then fed into the INHIBIT input of the counter (still NIM). The counter inputs are TTL signals.

48 bit operation: channels may be configured to count the carry bit of the preceeding channel. This

is done with the changeover switches. In the case of 48 bit per channel, they are configured in the

following way: duuuduuu for each of the four groups.

A V260 board is introduced to Online by:

define/dev=counter/mod=v260/base=0x100/vector=0/chan=0 c1
















Here is an example for a Tango configuration:



245

<device>

<name>exp_v01</name>

<tags>expert,user</tags>


<module>v260</module>

<device>p09/v260/exp.01</device>


<hostname>haso107klx:10000</hostname>

</device>

Chapter 70

V462 (Gate Generator, CAEN)

Timer module: 100 nsec ≤ gate < 10 sec, 2 channels, NIM outputs for gate, begin marker and end

marker (-0.8V, 50 Ohm). VME: A24D16, 256B at 0x0.

If this device is used for general scans, the sample time may exceed 10 seconds. The software

restarts the timer, if needed.

This timer cannot be stopped.

If this module is used with the V260 counter the gate output has to be inverted, e.g. by a N454.


define/dev=timer/mod=v462/base=0x0/vector=0/chan=0 t1

define/dev=timer/mod=v462/base=0x0/vector=0/chan=1 t2

247

Chapter 71

V513 (CAEN)

I/O register: 8 channels input, 8 channels output, Lemo, NIM level (-0.8V, 50 Ohm), requires

V430 crate. VME: A24D16, 256B at 0x200, RORA interupter. Rotary switches: 2000 00 (VME

connectors point upwards, marked corner is bottom-left).


define/dev=input_register/mod=v513/base=0x200/vector=0/chan=0 ireg1








define/dev=output_register/mod=v513/base=0x200/vector=0/chan=8 oreg1








248

Chapter 72

VcExecutor (Tango)

Virtual counters can be implemented as Tango devices. How this is done is explained in our Tango

manual.

249

Chapter 73

VDIN96 (Janz)

Input Register: 96 TTL channels. VME: A16D16, 64B at 0xa00, IREG17 - IREG22 (0xa40,

IREG23 - IREG28), (S1,S2,S3) = (0,a,0) ((4,a,0)). Jumper at J13. J13 - J15 select the interrupt

level.

Power requirements: 1.3A at 5V.

250

Chapter 74

VDOT32 (Janz)

Input/output Register: 32 channels (4 x 8), output 12-34V, input ¡ 34V, VME: A16D16, 12B at

0xa80, (S1,S2,S3) = (8,a,0), standard device names: ireg29 - 32, oreg29 - 32,

A VDOT32 board can be introduced to Online by, e.g.:

define/dev=output_register/mod=vdot32/base=0xa80/vector=0/chan=0 oreg29

define/dev=input_register/mod=vdot32/base=0xa80/vector=0/chan=1 ireg30



74.1 VDOT32 Tango

This is how the VDOT32 looks in /online dir/online.xml:

<device>

<name>exp_ireg01</name>


<module>vdot32in</module>

<device>p99/vdot32/exp.in01</device>



</device>

<device>







</device>

<device>







</device>

251

<device>

<name>exp_oreg01</name>

<type>output_register</type>

<module>vdot32out</module>

<device>p99/vdot32/exp.out01</device>



</device>

The properties:

VDOT32

PETRA-3

VDOT32

p99/vdot32/exp.in01

Properties:

Base: 2688

Channel: 1

isInput: True

SimulationMode: 0

p99/vdot32/exp.in02

Properties:

Base: 2688

Channel: 2

isInput: True

SimulationMode: 0

p99/vdot32/exp.in03

Properties:

Base: 2688

Channel: 3

isInput: True

SimulationMode: 0

p99/vdot32/exp.out03

Properties:

Base: 2688

Channel: 0

isInput: False

SimulationMode: 0

This is the typical configuration: channel 0: output, channel 1-3 input.

Chapter 75

VDOT96 (Janz)

Output Register: 96 channels (12 x 8), output 12V, 24V VME: A16D8, 32 byte at 0xa80, (S1,S2,S3)

= (8, a, 0) standard device names: oreg33 - oreg44,

A VDOT32 board can be introduced to Online by, e.g.:


...


253

Chapter 76

VFCADC (DESY, H. Zink)

ADC module: 8 analog inputs, NIM gate input, VME A24D16, 80B at 0x011000 (default). Rotary

switches: 0110 (The most significant switch is right, if the VME connectors are pointing down-

wards). The figures 76.1 and 76.2 show the board with the default base address. A second device

can be installed with 0x12000 (left ’1’ to ’2’).

The power requirements are: 2A at 5V, 250 mA at 12V, 250 mA at -12V.

The device is operated as follows: The NIM gate signal of a DGG2 (or so) is fed into GATE input

of the module.

Tango: A VFCADC board is introduced to Online by (/online dir/online.xml):

<hw>

... other devices

<device>

<name>exp_vfc01</name>

<type>adc</type>

<module>vfcadc</module>

<device>p09/vfc/exp.01</device>



</device>

...

<name>exp_vfc08</name>

<type>adc</type>

<module>vfcadc</module>

<device>p09/vfc/exp.08</device>



</device>

</hw>

For newly created devices make sure that the follwoing attributes are set to default values:

gain == 1

offset == 0

polarity == 1

The command

/usr/lib/tango/fsectools/setVFCADCAttr.py -s

254

sets gain, offset and polarity for all devices to the default values.

For NON-TANGO:

define/dev=adc/mod=vfcadc/base=0x011000/vector=0/chan=0 vfc1








The module has adjustable gain, offset and polarity:

!

! gain, aliases: gag() and sag()

!

* = get_adc_gain(vfc1)

set_adc_gain(vfc1) = 2

!

! offset, aliases: gao() and sao()

!

* = get_adc_offset(vfc1)

set_adc_offset( vfc1) = 2

!

! polarity, can be +1 or -1

!

* = get_adc_polarity(vfc1)

set_adc_polarity( vfc1) = 1

Make sure that gain, offset and polarity are set correctly. Otherwise the module may produce

unexpected results.

The module measures the external gate length with an internal MHz clock to do the gain and offset

corrections. The VFCADC is operated using the following functions:

* = reset_counter( vfc1)

* = reset_all_counters()

* = read_counter( vfc1)

* = read_adc( vfc1)

The function read adc() returns a true voltage value. Gain and offset are corrected and also the

sample time.

The function read counter() returns a count rate. Gain and offset are corrected but the count rate is

proportional to the sample time. Here is an example:

!

! set a DAC which is connected to channel 1 to 5 volts

!

sdv(dac1) = 5

!

! reset the channel

!


!

! start-and-wait-for-timer: 0.1s

!

sawft(t1) = 0.1

* = read_adc(vfc1)

! -> 4.994349

* = read_counter(vfc1)

! -> 49941


!

! start-and-wait-for-timer: 1s

!

sawft(t1) = 1

* = read_adc(vfc1)

! -> 4.994427

* = read_counter(vfc1)

! -> 499431

We have two measurements, the first uses a sample time of 0.1 s, the second of 1s. Notice that in

both cases read adc() returns the value of about 5V, independent of the sample time. In contrast,

read counter() returns a value that is proportional to the sample time. This behaviour has been

implemented to make this module compatibel with counters.

Figure 76.1: VFCADC, total, base: 0x11000

Figure 76.2: VFCADC, detail, base: 0x11000, the rightmost switch is most significant

Chapter 77

VHQ205L

A HV power supply.

define/dev=HV_PS/mod=VHQ205L/base=0x300/vector=0/chan=0 HV1

define/dev=HV_PS/mod=VHQ205L/base=0x300/vector=0/chan=1 HV2

The functions that operate the device are explained in the Online manual.

258

Chapter 78

VHSC005N

A HV power supply of ISEG, 12 channels, U: 0 to -500V.

define/dev=HV_PS/mod=VHSC005N/base=0x4000/vector=0/chan=0 HV1












Default base address: 0x4000 (factory default or when started with Adr jumper set).

The functions that operate the device are explained in the Online manual.

78.1 BLSC for VHSC005 (online -tki)

You may find it convenient to operate the VHSC005N from a BLSC widget (78.1) which is gener-

ated by the following lines which are part of /online dir/TkIrc.pl.

#

# from /online_dir/TkIrc.pl

#

$Spc::res_h{ blsc} = "vhsc005n, otherItems";

#

#

#

$Spc::res_h{ vhsc005n_title} = { text => "VHSC005N"};

$Spc::res_h{ vhsc005n_help} = sub

{

Util::display_text( "Help VHSC005N",

’

Ramp

259

A parameter that applies to all channels of a module. The unit

is per cent of -500 per second. The maximum is 20.

Exec

Starts the ramp

Stop

Changes the setpoint to the actual value.

’

)};

my @list = split ’ ’, Spectra::get_devices( "HV_PS");

my $i = 1;

for my $hv ( @list)

{

$Spc::res_h{ "VHSC005N_io$i"} = {

label => { name => "${hv} [V]",

get => sub { sprintf "%g", Spectra::vhsc005n( $hv, "VoltageMeasure");}},

entry => { set => sub { Spectra::vhsc005n( $hv, "VoltageSet", $_[0]);}}};

$i++;

}

$Spc::res_h{ "VHSC005N_io$i"} = {

label => { name => "Ramp [1-20]",

get => sub { sprintf "%g", Spectra::vhsc005n( $list[0], "VoltageRampSpeed");}},

entry => { set => sub { Spectra::vhsc005n( $list[0], "VoltageRampSpeed",

}}};

Figure 78.1: BLSC: VHSC005N

Chapter 79

VmExecutor (Tango)

Virtual motors can be implemented as Tango devices. How this is done is explained in our Tango

manual.

262

Chapter 80

VPAP (ESRF)

Stepper controller, 8 motors, 14925 Hz maximum, VME: A16D8.

Orientation of the VPAP card:

<- Front panel, VME connector ->

Jumpers (CSR base):

F800: J00000JJJJ

F700: J0000J000J

F600: J0000J00JJ

F500: J0000J0J0J

F400: J0000J0JJJ

F900: J00000JJ0J

A800: J0J0J0JJJJ

B800: J0J000JJJJ

Dip switches M1-M8 (limit switch polarity):

11101110 (test mode)

00101110 (motors connected)

263

Chapter 81

XIA, DXP-XMAP, Tango

The XIA DXP-XMAP is a multi-channel MCA that is operated from a windows computer, e.g.:

haspxiproto. Linux users can login to this PC by:

rdesktop -a 16 -g 90% -r disk:linux=${HOME} haspxiproto &

or

rdesktop -a 16 -g 1280x1024 -r disk:linux=${HOME} haspp06xmap &

The server can be started from Astor.

The server uses the following ini file:

C:\Program Files\XIA\xManager 0.10.5\xmap_tango.ini

There is an application, xManager (provided by XIA), can be used to configure the system. It

should also use the file xmap tango.ini to store the changes. After the xManager saved the

changes, the Tango server has to be re-started.

In general the XIA is operated on a gated mode. Be sure to terminate the TTL line with 50 Ohm

near the XIA input.

Most of the XIA parameters are accessible via Tango attributes. They are explained in the document

”Tango at Hasylab” which can be found on the Hasylab Computing pages.

The following lines show how two MCA are introduced to Online, file name: /online dir/online.xml


<hw>

#

#

#

<device>

<name>mca10</name>

<type>mca</type>

<module>mca_xia</module>

<device>pxi/exp/mca1</device>


<hostname>haspxiproto:20000</hostname>

</device>

<device>

<name>mca11</name>

264

<type>mca</type>

<module>mca_xia</module>

<device>pxi/exp/mca2</device>


<hostname>haspxiproto:20000</hostname>

</device>

</hw>

81.1 ’Live Time’ to FIO Files

Here is an example of how to write a Tango attribute, like liveTime, to the comment section of FIO

files:

1. You have to use ’online -tki’

2. The function Spectra::fio_comments has to be added to the file /online_dir/TkIrc.pl.

An example for this function can be found below.

3. The flag “Additional FIO comments” has to be enabled. This is done in the scan menu

(Flags).

#

# somewhere in /online_dir/TkIrc.pl

#

sub Spectra::fio_comments

{

my $line = "";

if( search_device( "mca10"))

{

$line .= "MCA10 live " .

Spectra::tng_attrDoubleRd( "MCA10", "livetime");

}

return $line;

}

Index

AbsorberBox, 17

ADS, 144

Andor, 13

Attribute Motor, 15

ATVME, 11

Beckhoff, 144, 175

BPM, 45

CAMAC, 12

check-motor-registers, 114

DC motor, 19

DGG, 20

DGG2, 20

Diffractometer, 25

DSO, 70

DXP-XMAP, 264

E4C, 25

E6C, 25

encoder, 54, 56, 144

FMB-Oxford, 26

Galil, 30

Gap, 15, 237

Gpib, 44

I404, 45

IK220, 54

IK320, 56

KETEK 4K, 61

Kohzu, 63

LeCroy, 70

Lima

Andor, 13

Lom, 71

Lom500, 71

M663, 84

M665, 85

MAR

CCD, 86

Image plate scaner, 88

Maxipix, 89

MCA 8701, 90

MCS, 169

Monochromator, 26, 71

NIGPIB, 105

OMS58, 106

OMS58S, 106

OMSMAXV, 111

operation

ADC-8715, 90

V260, 245

VFCADC, 254

PIDPC, 129

PIE710, 130

PIE712, 130

Pilatus, 137

PMAC, 26

position encoder, 54, 56, 144

preset mode, 20

Quadpack, 136

Renishaw, 144

RGH25F, 144

RoperScientific, 145

SDD7, 147

SetStepPosition, 114

SetStepRegister, 114

SF7210, 149

SIS1100/3100, 150

SIS3600, 164

SIS3610, 166

SIS3820, 169

Sixpack, 136

SMCHYDRA, 174

Spk, 175

Tango

attributeMotor, 215

BLEnergy, 218

266

generic device, 216

Monochromator, 218

Motor Tango, 217

TcpIpMotorP10, P01, P10, 220

TwoThetaP07, 234

TIP551, 222

TIP830, 226

TIP850, 230

TVME200-10, 230

Undulator, 237

V260, 245

V462, 247

V513, 248

VDIN96, 60, 250

VDOT32, 251

VDOT96, 253

VFCADC, 254

VHQ205L, 258

VHSC005N, 259

VPAP, 263

XIA, 264

Documents

hardware - DESYhasyweb.desy.de/services/computing/hardware/hardware.pdf · 2020. 2. 4. · 11 Galil DMC Controller, Tango 30 ... 30 Micro-Zugvorrichtung, BW4 100 31 Monochromator,