- Email: [email protected]
Control system with a software simulator for JAERI-FEL
Nuclear Instruments and Methods in Physics Research A 331 (1993) 340-345 North-Holland
NUCLEAR INSTRUMENTS & METHODS IN PHYSICS RESEARCH Section A
Control system with a software simulator for JAERI-FEL Masayoshi Sugimoto Free Electron Laser Laboratory, Japan Atomic Energy Research Institute, Tokai, Ibaraki 319-11, Japan
The control system for the JAERI-FEL consists of the hardware control process and the software simulator process. The design concept is based on the hierarchical structure to separate the machine dependent parts. The system is implemented on the LAN of MS-DOS machines. The user interface employs the windows system basically; Smalltalk which has a good graphical user interface is used as a primary language at the top layer of the hierarchy. The control system includes several support tools such as a beam optics code, a data base manager, and a guidance system. Using such a control system, the development/maintenance/update tasks become easy and advanced control can be attainable.
1. Introduction The Free Electron Laser (FEL) facility driven by the superconducting linac has been constructed at JAERI, Tokai [1]. It is a relatively small size machine, with a 20 MeV electron linear accelerator and associated apparatus. The main purpose of this facility is to accumulate the expertise on laser oscillation technology using the superconducting accelerator, which may be operated in a cw mode in the future and which can produce a very high power laser. Therefore, the control system of the J A E R I - F E L is designed to have the capability to accumulate such knowledge during test operations [2]. The control system consists of the usual hardware control process and the virtual software simulator for checking the theory or the accumulated knowledge. The design concept is based on the hierarchical structure to abstract the hardware dependent parts. At the top of such layers, the operators tasks are arranged on the window system and Smalltalk [3] is used as the primary programming language to produce the user interface of the operating console. The design architecture is described in section 2. The actual control system is implemented on the Local Area Network (LAN) of the MS-DOS machines (NEC-PC98 series 32 bit personal computers). The computation power of such system is fairly restrictive, however, the hardware cost is the lowest. The control system can be transported to the other machine by reconstructing the lowest layer of the hierarchical structure. This topics is discussed in section 3. The control system includes several supporting tools to facilitate the purposes described above, i.e. a beam optics program, a data base manager, and a guidance system. Users can create their own operator console using the top level language (Smalltalk) and the sup-
porting tools. A typical example is shown in section 4. By using the control system, the tedious tasks of the development, the maintenance, and the update become easier. Moreover the advanced controls can be attainable in a short path. The perspectives of this item and a summary are presented in section 5.
2. Design architecture The general considerations for the control system of the J A E R I - F E L are summarized in order of priority as:
(1) Flexibility for future refinement~upgrade. Our machine is constructed for the R & D study, so the frequent change will be inevitable during its lifetime. The changes would cover the individual devices, the control methods, and the control system hardware. (2) Realtimeness to obtain a good response. The control speed is not necessary to be very fast for our purpose, but it should be done in a reasonable response time ( < several tenth of second). (3) Good user interface for various styles of control information. The operators of this machine are the experimenters of the accelerator and the laser fields, too. They need to control and monitor many types of equipment at the same time, so the information is offered in an organized way with the appropriate form for each item. These representation styles may be different and they are easily replaced by each other. (4) Reliability of the system. The primary objective of the project is to confirm the technology of the stable laser oscillation, so the control system is necessary to be reliable enough, too. From these requirements, we employ the strategies for the hardware and the software of the control system design.
0168-9002/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved
M. Sugimoto / Control system for JAERI-FEL
ITEMS t"
MODELS
I VIRTUAL HOST I
D CONSOLE
PANEL
DATABASE MANAGER
I VIRTUAL CONTROLLER I
SETI-ING
I._l..C
341
READING
SWITCH
1 1
LOCAL CPU#l CAMAC.#I
O "E~'T'o" O ,CELLSO., .KREFR,O., TEMP#I
LEVEL#1
[ VIRTUAL DEVICE]
_/"x_
/VWV~
~r--q
.ELLO ESeA .L-S~
m
~K-REF.,~J
I PHYSICAL MODEL PARAMS I LOGICAL NAMES I
D y 2 ; ~ : E 7R:ES
.."
Fig. 1. A schematic view of the logical hardware. A) The hardware employs the commercially available (well tested) standards where possible. The design is carried out for virtual hardware. B) The software with a hierarchical structure is designed for the levels of the physical dependence.
vice), ii) the controller for a set of the devices or a series of actions (virtual controller), and iii) the host computer used as the console and the data analysis machine (virtual host) (see fig. 1). The virtual device is the abstraction of the actual hardware components and it is essentially the data base of the parameters of each component, which include the physical model parameters, the logical names, the interface types, etc. It is controlled by a
2.1. Logical hardware The hardware is logically considered for three levels of control system: i) the individual device (virtual de-
HIERARCHY
SIMULATOR
LIOATION DEPENDENT LAYER t ,~
o BJECTIVES(STARTUPI'ACTIVATION
/
~aDWAREsVSTE. L
J
/
/oo 2E2"o272222 [ /
HJHARDW'AREDEVICE Lm
/ OE,,,CE O*VF
,,LOW
,~
/
Fig. 2. A schematic view of the hierarchical software structure. VII. ACCELERATORS
M. Sugimoto / Control system for JAERI-FEL
342
hardware device level control in the machine dependent layer of the software, as described below. The virtual controller is the abstraction of the controller which carries out specific actions, such as parameter setting or reading. It is another data base of the links (or relations) between the virtual devices, which are controlled in a single virtual controller. The controlling actions are sent to the corresponding virtual controller from the virtual host by an operator command. The virtual host is the abstraction of the host computer of the control system, however, it may not be fixed to the central host machine and the actual console may be migrated to the other machine for backup or local tests in the case of the distributed control system.
2) Hardware system dependent layer This handles the abstracted hardware system (virtual controller) that carries out the functions according to their specifications. Usually each hardware device is categorized by the types, such as the beam transport elements, the vacuum system, the refrigerator system, etc. The hardware system level controls a set of instruments in such a system and the hardware system simulator can emulate these functions according to the theoretical model stored in the knowledge base. 3) Application dependent layer. It is the highest level of the hierarchy and handles all processes except the hardware dependent part. The application means the operator console task and the related sub tasks invoked by the operating system (virtual c~S). The virtual host is a machine that executes the operator console task currently. The simulator at this level is just a performance analyzer of the multitasking, multi-CPU system through the network.
2.2. Hierarchical software structure The software is developed in a hierarchical structure to facilitate the separation of the physical dependence and the future upgrade of the individual devices and the control methods. There are three layers in the software hierarchy as shown in fig. 2. 1) Machine dependent layer It is the lowest level and handles the hardware (virtual device) directly. The kernel of the task control is also included here. The device simulator is implemented in this layer for checking the individual device.
3. Implementation 3.1. Hardware We employ the networked personal computers (NEC-PC98 series, 32 bit CPU i80386) as the host machine and CAMAC [4] and GPIB [5] standards are used as the device interfaces. Fig. 3 shows the block
COTROL ROOM
ACCELERATOR ROOM LOCAL UNITS
OPERA FOR C O N S O E
VACUUM R~REFRIG. BEAMTRANSPORT
-"-
CRT 21"
eRT""
IL =
KEYBOARD
~--
/
MOUSE
MOUSE ----
"-'-
CAMAC lie
TOUCH PNAEL SCSI IIF
E,'BOARD CRT 14"
L
SCSI IIF " ' 7
FLOPPY DRIVE
FLOPPY DRIVE
GPIB IIF
GPIB I/F ~
,
=
ETHERNETF
----"
RSZ320 I/F-----]
,
PRINTER llFl'll
"--"
ETHEP;.NET IIF RS::'32C I/F ~ I.-----] PRINTER IIF /
MAGNETIC DISK DRIVE + MAGNETO-OPTICAL DISK DRIVE
......
rlo_EN
GPIB I I F - ~-
ETHERNET IIF
. . . . . . . . . . .
PERIPHEP.JkL I SHAR]NG PRINTER+PLOTTER
Fig. 3. Block diagram of the JAERI-FEL control system. The upper half shows the main console at the control room and the lower half represents the triple local control units. The Ethernet LAN connects these computers. Each hardware device is controlled by a CAMAC module or a GPIB controller in the control unit.
M. Sugimoto / Control system for JAERI-FEL
343
LAYOUT
O 77SA fOR CPOEN O LE
GROUND FLOOR
CF'U~ 1Orn
i
[]
Fig. 4. The layout of the control units and other major components of the JAERI-FEL The three local units (CPUIL, CPU2L, and CPU3L) are placed in the target room and the main console (CPU1 and CPU2) in the control room. The distance between the local units and the console is about 30 m, and these are connected by the 10BASE2 ethernet LAN.
diagram of the hardware components in the control system, which will be completed at the end of F Y 1992. T h e r e are two C P U s for the main console and three local CPUs to drive the actual devices. They are connected by the thin-wire (10BASE2) E t h e r n e t L A N [6] as shown in the fig. 4, that represents the locations of the other major components of the J A E R I - F E L facility.
CONTROL
I 5CELL-SCA
#
3.2. Software As the primary programming language for the application dependent layer, we choose Smalltalk, which is an interpreter with a good Graphical U s e r Interface based on the windowing system. It is also an object-oriented language that can perform the abstractions described in section 2 easily.
STATUS
PANEL
1]
BLOCK DIAG RAM [5 CE LL-S C.A/RFsyst e rn] 4~Acontrol
[_.
RFinpo, ] I" TRIG,npo, I
DISPLAY
R
F
Zrns/2wAmp 100w 50kw
i
n
cavity
~
•
[0
aFoutput
Io ALARM
I ]
REFRIG.TEMP.
cavity
4kehield
08,,0v9212:0o:o0 ~ 08Jl]l/9211:PS:00 nnJnl/q~ 11-Pn-nn
1 ~
DIAGRAMTIC DISPLAY
( L__L~
[ /
1 ~
HVGP
shifter
1 [
t J
I I
[BEAM LINE]
Solenoid SHB Solenoid
~
40kshld 80knhld
(
Solenoid
uuuuuu Buncher
1CelISCA
Fig. 5. An example of the CRT displays shows the typical control operation. The left hand side display is the control panel for the accelerator and the right hand side display shows the various status of other components. VII. ACCELERATORS
344
M. Sugimoto / Control system for JAERI-FEL
The operating system is based on MS-DOS, which is a single task c~S, and some extensions are necessary to match the design specifications. The lowest level code (machine dependent layer) is written in C and Assembly to gain the maximum speed, while some parts of the code or its prototype (hardware system dependent layer and application dependent layer) are developed in Pascal and Prolog, too. At the very early stage, Forth is also considered as the primary language [7], but at present it is replaced with Smalltalk.
4. Application The application includes the operator console task, and the supporting tools, such as the beam optics program, the data base manager, and the operators guidance system. The user interface is based upon Smalltalk's environment, and several windows are used to control every part of the facility. Each supporting tool is invoked in another window. The two CRT displays connected to the individual CPUs can be used in the main console, so one of them is dedicated to data entry through mouse a n d / o r touch panel, and the other is used to display the status and the analyzed informations. Fig. 5 shows an example of such a display usage for controlling and monitoring. In the local units the one CRT display is available but the console task on it is mainly used for local debugging or offqine tests. The most characteristic feature of this control system may be that the simulators are considered for all layers of the software structure. It gives the image of
the system performance before the completion of the hardware installments and the effect of a new device or a new algorithm of control method can be predicted. The switching to the simulator from the actual device or hardware system is controlled through the data base of the system definition. Fig. 6 illustrates an example of such a simulation task.
5. Summary Before proceeding to the summary, some perspectives are given first. 1) It can perform self diagnosis of the device and the controller. This makes the long-term operation stable by detecting the malfunctions which may cause the critical flaws. 2) After enough experience on the operations is accumulated, it can start up by a programmed mode and the tuning process has to be done in a scheduled manner. 3) The experiments are directly compared with the simulations, which can be deduced from theoretical study of the accelerator and FEL physics. The results of the comparison may be fed back to test the validity of the theoretical assumptions or the calculation algorithms. As a conclusion, the flexible control system is designed and implemented for the JAERI-FEL facility. It has a new user interface comprising several styles of the representation and the simulator to facilitate the performance check and the accumulation of the experiences through actual operations.
GUIDANCE S Y S T E M
BEAM OPTICS S I M U L A T O R
dd
~8
~x
[L3 x-xJ/{M] ph-E(30)/ER3 y-yJ (D
i
{L3 x-xJ/[M3 ph-E(30)/[R] g-gJ <0)
"/-TROUBLESHOOT selectthe item - BEAM DISAPPEAR chocking beam locations._ [some directions about beam monitor controls and beam positions] analyzing beam profile... possible solutions and reasons: 1. Reduce SHB field and balance the solenoid fields. Lengtudinal focuss is too strong.
Horiz
NL= 3594. £;3mrn(83, 4MHz)
'
Uert
LENGTH=12350, 00nln
First order
Fig. 6. An example of activated simulation task in a control operation.
LENSTH=213SI
M. Sugimoto / Control system for JAERI-FEL
Acknowledgements T h e a u t h o r would like to t h a n k Drs. N. Shikazono a n d M. Ishii for t h e i r c o n t i n u o u s e n c o u r a g e m e n t a n d interests o n this subject. T h e useful discussions with the m e m b e r s of t h e F r e e E l e c t r o n L a s e r L a b o r a t o r y are also acknowledged.
References [1] M. Sawamura et al. Proc. 13th Int. Free Electron Laser Conf. 1991, Santa Fe, Nucl. Instr. and Meth. A318 (1992) 127.
[2]
[3]
[4] [5] [6] [7]
345
E. Minehara et al., Proc. 14th Int. Free Electron Laser Conf., Kobe, Japan, 1992) Nucl. Instr. and Meth. A 331 (1993) 182. M. Sugimoto, Proc. Int. Conf. on Accelerator and Large Experimental Physics Control Systems, 1991, Tsukuba, KEK Proc. 92-15 (1992) 198. A. Goldberg and D. Rboson, Smalltalk-80: The Language and Its Implementation (Addison-Wesley, Reading, MA, 1983). A N S I / I E E E standard: 583 (1982). IEEE standards: 488.1 (1987), 488.2 (1987). IEEE standard: 802.3 (1984). Y. Kawarasaki and M. Sugimoto, Proc. 7th Symp. on Accelerator Science and Technology, 1989, Osaka (RCNP, Osaka University) p. 262.
VII. ACCELERATORS
NUCLEAR INSTRUMENTS & METHODS IN PHYSICS RESEARCH Section A
Control system with a software simulator for JAERI-FEL Masayoshi Sugimoto Free Electron Laser Laboratory, Japan Atomic Energy Research Institute, Tokai, Ibaraki 319-11, Japan
The control system for the JAERI-FEL consists of the hardware control process and the software simulator process. The design concept is based on the hierarchical structure to separate the machine dependent parts. The system is implemented on the LAN of MS-DOS machines. The user interface employs the windows system basically; Smalltalk which has a good graphical user interface is used as a primary language at the top layer of the hierarchy. The control system includes several support tools such as a beam optics code, a data base manager, and a guidance system. Using such a control system, the development/maintenance/update tasks become easy and advanced control can be attainable.
1. Introduction The Free Electron Laser (FEL) facility driven by the superconducting linac has been constructed at JAERI, Tokai [1]. It is a relatively small size machine, with a 20 MeV electron linear accelerator and associated apparatus. The main purpose of this facility is to accumulate the expertise on laser oscillation technology using the superconducting accelerator, which may be operated in a cw mode in the future and which can produce a very high power laser. Therefore, the control system of the J A E R I - F E L is designed to have the capability to accumulate such knowledge during test operations [2]. The control system consists of the usual hardware control process and the virtual software simulator for checking the theory or the accumulated knowledge. The design concept is based on the hierarchical structure to abstract the hardware dependent parts. At the top of such layers, the operators tasks are arranged on the window system and Smalltalk [3] is used as the primary programming language to produce the user interface of the operating console. The design architecture is described in section 2. The actual control system is implemented on the Local Area Network (LAN) of the MS-DOS machines (NEC-PC98 series 32 bit personal computers). The computation power of such system is fairly restrictive, however, the hardware cost is the lowest. The control system can be transported to the other machine by reconstructing the lowest layer of the hierarchical structure. This topics is discussed in section 3. The control system includes several supporting tools to facilitate the purposes described above, i.e. a beam optics program, a data base manager, and a guidance system. Users can create their own operator console using the top level language (Smalltalk) and the sup-
porting tools. A typical example is shown in section 4. By using the control system, the tedious tasks of the development, the maintenance, and the update become easier. Moreover the advanced controls can be attainable in a short path. The perspectives of this item and a summary are presented in section 5.
2. Design architecture The general considerations for the control system of the J A E R I - F E L are summarized in order of priority as:
(1) Flexibility for future refinement~upgrade. Our machine is constructed for the R & D study, so the frequent change will be inevitable during its lifetime. The changes would cover the individual devices, the control methods, and the control system hardware. (2) Realtimeness to obtain a good response. The control speed is not necessary to be very fast for our purpose, but it should be done in a reasonable response time ( < several tenth of second). (3) Good user interface for various styles of control information. The operators of this machine are the experimenters of the accelerator and the laser fields, too. They need to control and monitor many types of equipment at the same time, so the information is offered in an organized way with the appropriate form for each item. These representation styles may be different and they are easily replaced by each other. (4) Reliability of the system. The primary objective of the project is to confirm the technology of the stable laser oscillation, so the control system is necessary to be reliable enough, too. From these requirements, we employ the strategies for the hardware and the software of the control system design.
0168-9002/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved
M. Sugimoto / Control system for JAERI-FEL
ITEMS t"
MODELS
I VIRTUAL HOST I
D CONSOLE
PANEL
DATABASE MANAGER
I VIRTUAL CONTROLLER I
SETI-ING
I._l..C
341
READING
SWITCH
1 1
LOCAL CPU#l CAMAC.#I
O "E~'T'o" O ,CELLSO., .KREFR,O., TEMP#I
LEVEL#1
[ VIRTUAL DEVICE]
_/"x_
/VWV~
~r--q
.ELLO ESeA .L-S~
m
~K-REF.,~J
I PHYSICAL MODEL PARAMS I LOGICAL NAMES I
D y 2 ; ~ : E 7R:ES
.."
Fig. 1. A schematic view of the logical hardware. A) The hardware employs the commercially available (well tested) standards where possible. The design is carried out for virtual hardware. B) The software with a hierarchical structure is designed for the levels of the physical dependence.
vice), ii) the controller for a set of the devices or a series of actions (virtual controller), and iii) the host computer used as the console and the data analysis machine (virtual host) (see fig. 1). The virtual device is the abstraction of the actual hardware components and it is essentially the data base of the parameters of each component, which include the physical model parameters, the logical names, the interface types, etc. It is controlled by a
2.1. Logical hardware The hardware is logically considered for three levels of control system: i) the individual device (virtual de-
HIERARCHY
SIMULATOR
LIOATION DEPENDENT LAYER t ,~
o BJECTIVES(STARTUPI'ACTIVATION
/
~aDWAREsVSTE. L
J
/
/oo 2E2"o272222 [ /
HJHARDW'AREDEVICE Lm
/ OE,,,CE O*VF
,,LOW
,~
/
Fig. 2. A schematic view of the hierarchical software structure. VII. ACCELERATORS
M. Sugimoto / Control system for JAERI-FEL
342
hardware device level control in the machine dependent layer of the software, as described below. The virtual controller is the abstraction of the controller which carries out specific actions, such as parameter setting or reading. It is another data base of the links (or relations) between the virtual devices, which are controlled in a single virtual controller. The controlling actions are sent to the corresponding virtual controller from the virtual host by an operator command. The virtual host is the abstraction of the host computer of the control system, however, it may not be fixed to the central host machine and the actual console may be migrated to the other machine for backup or local tests in the case of the distributed control system.
2) Hardware system dependent layer This handles the abstracted hardware system (virtual controller) that carries out the functions according to their specifications. Usually each hardware device is categorized by the types, such as the beam transport elements, the vacuum system, the refrigerator system, etc. The hardware system level controls a set of instruments in such a system and the hardware system simulator can emulate these functions according to the theoretical model stored in the knowledge base. 3) Application dependent layer. It is the highest level of the hierarchy and handles all processes except the hardware dependent part. The application means the operator console task and the related sub tasks invoked by the operating system (virtual c~S). The virtual host is a machine that executes the operator console task currently. The simulator at this level is just a performance analyzer of the multitasking, multi-CPU system through the network.
2.2. Hierarchical software structure The software is developed in a hierarchical structure to facilitate the separation of the physical dependence and the future upgrade of the individual devices and the control methods. There are three layers in the software hierarchy as shown in fig. 2. 1) Machine dependent layer It is the lowest level and handles the hardware (virtual device) directly. The kernel of the task control is also included here. The device simulator is implemented in this layer for checking the individual device.
3. Implementation 3.1. Hardware We employ the networked personal computers (NEC-PC98 series, 32 bit CPU i80386) as the host machine and CAMAC [4] and GPIB [5] standards are used as the device interfaces. Fig. 3 shows the block
COTROL ROOM
ACCELERATOR ROOM LOCAL UNITS
OPERA FOR C O N S O E
VACUUM R~REFRIG. BEAMTRANSPORT
-"-
CRT 21"
eRT""
IL =
KEYBOARD
~--
/
MOUSE
MOUSE ----
"-'-
CAMAC lie
TOUCH PNAEL SCSI IIF
E,'BOARD CRT 14"
L
SCSI IIF " ' 7
FLOPPY DRIVE
FLOPPY DRIVE
GPIB IIF
GPIB I/F ~
,
=
ETHERNETF
----"
RSZ320 I/F-----]
,
PRINTER llFl'll
"--"
ETHEP;.NET IIF RS::'32C I/F ~ I.-----] PRINTER IIF /
MAGNETIC DISK DRIVE + MAGNETO-OPTICAL DISK DRIVE
......
rlo_EN
GPIB I I F - ~-
ETHERNET IIF
. . . . . . . . . . .
PERIPHEP.JkL I SHAR]NG PRINTER+PLOTTER
Fig. 3. Block diagram of the JAERI-FEL control system. The upper half shows the main console at the control room and the lower half represents the triple local control units. The Ethernet LAN connects these computers. Each hardware device is controlled by a CAMAC module or a GPIB controller in the control unit.
M. Sugimoto / Control system for JAERI-FEL
343
LAYOUT
O 77SA fOR CPOEN O LE
GROUND FLOOR
CF'U~ 1Orn
i
[]
Fig. 4. The layout of the control units and other major components of the JAERI-FEL The three local units (CPUIL, CPU2L, and CPU3L) are placed in the target room and the main console (CPU1 and CPU2) in the control room. The distance between the local units and the console is about 30 m, and these are connected by the 10BASE2 ethernet LAN.
diagram of the hardware components in the control system, which will be completed at the end of F Y 1992. T h e r e are two C P U s for the main console and three local CPUs to drive the actual devices. They are connected by the thin-wire (10BASE2) E t h e r n e t L A N [6] as shown in the fig. 4, that represents the locations of the other major components of the J A E R I - F E L facility.
CONTROL
I 5CELL-SCA
#
3.2. Software As the primary programming language for the application dependent layer, we choose Smalltalk, which is an interpreter with a good Graphical U s e r Interface based on the windowing system. It is also an object-oriented language that can perform the abstractions described in section 2 easily.
STATUS
PANEL
1]
BLOCK DIAG RAM [5 CE LL-S C.A/RFsyst e rn] 4~Acontrol
[_.
RFinpo, ] I" TRIG,npo, I
DISPLAY
R
F
Zrns/2wAmp 100w 50kw
i
n
cavity
~
•
[0
aFoutput
Io ALARM
I ]
REFRIG.TEMP.
cavity
4kehield
08,,0v9212:0o:o0 ~ 08Jl]l/9211:PS:00 nnJnl/q~ 11-Pn-nn
1 ~
DIAGRAMTIC DISPLAY
( L__L~
[ /
1 ~
HVGP
shifter
1 [
t J
I I
[BEAM LINE]
Solenoid SHB Solenoid
~
40kshld 80knhld
(
Solenoid
uuuuuu Buncher
1CelISCA
Fig. 5. An example of the CRT displays shows the typical control operation. The left hand side display is the control panel for the accelerator and the right hand side display shows the various status of other components. VII. ACCELERATORS
344
M. Sugimoto / Control system for JAERI-FEL
The operating system is based on MS-DOS, which is a single task c~S, and some extensions are necessary to match the design specifications. The lowest level code (machine dependent layer) is written in C and Assembly to gain the maximum speed, while some parts of the code or its prototype (hardware system dependent layer and application dependent layer) are developed in Pascal and Prolog, too. At the very early stage, Forth is also considered as the primary language [7], but at present it is replaced with Smalltalk.
4. Application The application includes the operator console task, and the supporting tools, such as the beam optics program, the data base manager, and the operators guidance system. The user interface is based upon Smalltalk's environment, and several windows are used to control every part of the facility. Each supporting tool is invoked in another window. The two CRT displays connected to the individual CPUs can be used in the main console, so one of them is dedicated to data entry through mouse a n d / o r touch panel, and the other is used to display the status and the analyzed informations. Fig. 5 shows an example of such a display usage for controlling and monitoring. In the local units the one CRT display is available but the console task on it is mainly used for local debugging or offqine tests. The most characteristic feature of this control system may be that the simulators are considered for all layers of the software structure. It gives the image of
the system performance before the completion of the hardware installments and the effect of a new device or a new algorithm of control method can be predicted. The switching to the simulator from the actual device or hardware system is controlled through the data base of the system definition. Fig. 6 illustrates an example of such a simulation task.
5. Summary Before proceeding to the summary, some perspectives are given first. 1) It can perform self diagnosis of the device and the controller. This makes the long-term operation stable by detecting the malfunctions which may cause the critical flaws. 2) After enough experience on the operations is accumulated, it can start up by a programmed mode and the tuning process has to be done in a scheduled manner. 3) The experiments are directly compared with the simulations, which can be deduced from theoretical study of the accelerator and FEL physics. The results of the comparison may be fed back to test the validity of the theoretical assumptions or the calculation algorithms. As a conclusion, the flexible control system is designed and implemented for the JAERI-FEL facility. It has a new user interface comprising several styles of the representation and the simulator to facilitate the performance check and the accumulation of the experiences through actual operations.
GUIDANCE S Y S T E M
BEAM OPTICS S I M U L A T O R
dd
~8
~x
[L3 x-xJ/{M] ph-E(30)/ER3 y-yJ (D
i
{L3 x-xJ/[M3 ph-E(30)/[R] g-gJ <0)
"/-TROUBLESHOOT selectthe item - BEAM DISAPPEAR chocking beam locations._ [some directions about beam monitor controls and beam positions] analyzing beam profile... possible solutions and reasons: 1. Reduce SHB field and balance the solenoid fields. Lengtudinal focuss is too strong.
Horiz
NL= 3594. £;3mrn(83, 4MHz)
'
Uert
LENGTH=12350, 00nln
First order
Fig. 6. An example of activated simulation task in a control operation.
LENSTH=213SI
M. Sugimoto / Control system for JAERI-FEL
Acknowledgements T h e a u t h o r would like to t h a n k Drs. N. Shikazono a n d M. Ishii for t h e i r c o n t i n u o u s e n c o u r a g e m e n t a n d interests o n this subject. T h e useful discussions with the m e m b e r s of t h e F r e e E l e c t r o n L a s e r L a b o r a t o r y are also acknowledged.
References [1] M. Sawamura et al. Proc. 13th Int. Free Electron Laser Conf. 1991, Santa Fe, Nucl. Instr. and Meth. A318 (1992) 127.
[2]
[3]
[4] [5] [6] [7]
345
E. Minehara et al., Proc. 14th Int. Free Electron Laser Conf., Kobe, Japan, 1992) Nucl. Instr. and Meth. A 331 (1993) 182. M. Sugimoto, Proc. Int. Conf. on Accelerator and Large Experimental Physics Control Systems, 1991, Tsukuba, KEK Proc. 92-15 (1992) 198. A. Goldberg and D. Rboson, Smalltalk-80: The Language and Its Implementation (Addison-Wesley, Reading, MA, 1983). A N S I / I E E E standard: 583 (1982). IEEE standards: 488.1 (1987), 488.2 (1987). IEEE standard: 802.3 (1984). Y. Kawarasaki and M. Sugimoto, Proc. 7th Symp. on Accelerator Science and Technology, 1989, Osaka (RCNP, Osaka University) p. 262.
VII. ACCELERATORS