- Email: [email protected]
Tools for man-machine interface development in accelerator control applications
Nuclear Instruments and Methods in Physics Research A 352 (1994) 424-426 North-Holland
NUCLEAR INSTRUMENTS & METHODS IN PHYSICS RESEARCH Section A
Tools for man-machine interface development in accelerator control applications L. Kopylov *, M. Mikhev, N. Trofimov, V. Yurpalov IHEP, Protvino, Russia
For the UNK Project a development of the Accelerator Control Applications is in progress. These applications will use a specific Graphical User Interface for data presentation and accelerator parameter management. A number of tools have been developed based on the Motif Tool Kit. They contain a set of problem oriented screen templates and libraries. Using these tools, full scale prototype applications of the UNK Tune and Orbit measurement and correction were developed and are described, as examples. A subset of these allows the creation of the synoptic control screens from the Autocad picture files and Oracle DB equipment descriptions. The basic concepts and a few application examples are presented.
1. Introduction As a part of the U N K Control Project, the development of a Graphical User Interface (GUI) for the application software is in progress. The G U I is being developed in the environment of the de-facto standard X-Window and Motif Tool Kit graphical systems. These systems provide a wide range of capabilities for G U I creation but they are not sufficient for accelerator control applications. Firstly, the existing set of graphical objects - widgets - in this system does not cover the requirements in G U I for accelerator control. For example Motif does not provide even a primitive object for 2D graphics, but the accelerator control applications require complex graphical objects for numeric data presentation such as graphs, tables and different tools for editing data. Secondly, these systems are rather complex to use and require a deep knowledge and considerable experience on the part of the application programmers even for solving trivial tasks. Even for the experienced programmers it is a tedious job due to the low level interface of the graphical systems libraries. The complexities of the objects used by application programmers should not exceed the complexity of developing the functional part of the application. The way to solve these problems could be to develop a specialised tool kit for the application designer that would allow the use of the full power of the X-Windows and Motif Toolkit systems but which would also liberate an application programmer from the routine job of developing the standard graphical objects needed of G U I for accelerator control. This tool kit * Corresponding author.
should contain a package of libraries, utilities and templates solving the problems mentioned above. We have developed such a package and are using it for the U N K control application. Components of this package and two application examples are described below.
2. Graph port One of the main tasks of the G U I is numerical data presentation and manipulation. An extension of the Motif Toolkit capability is given by the widgets developed in the C E R N PS control group, such as Graph, Digit, Wheelswitch [1]. They cover the needs of application programs for numeric data presentation, but they do not solve the problem mentioned above completely. A design procedure can be simplified by using one of the visual packages such as V U I T (Visual User Interface Tool) or X-Designer, but these packages allow the creation of a static interface as the geometry and resources of the widgets are defined in the coding phase. The goal is to develop an intermediate software layer which hides from the users the low level libraries and provides functionally powerful and habitual interfaces to the widgets mentioned above. The solution to this problem leads to the Graph Port concept. The Graph Port is a complex object built on the basis of C E R N PS widgets which has a software interface in GKS style and provides an internal coupling between the widgets that form it. Graph Port is implemented in the form of a library package that creates an application program interface to the graphical widgets. The Graph Port itself is a container for the different G U I components. It can be placed in a separate window or share the window with other ports or wid-
0168-9002/94/$07.00 © 1994 - Elsevier Science B.V. All rights reserved SSDI 0168-9002(94)00066-G
L. Kopylov et al. /Nucl. Instr. and Meth. in Phys. Res. A 352 (1994) 424-426 gets. The geometry and content of the Graph Port and its components may be constructed by VUIT. The internal identifiers and call-backs are hidden from the user, only the port identifier and elements identifier are visible outside. The library allows the creation of the dynamic connections between application data sets and the Port's internal elements via an object called Link. Link is established at run time and keeps data coherency between the coupled port elements and data sets. The application programmer does not need to care about data modification in all elements connected to the Link as this action is done by one call per Link. The Graph Port toolkit comprises a set of predefined port configurations and templates corresponding to the different requirements of specific applications. Users can construct an application from existing ports or modify port templates and add new elements to them. However when adding a new element, the user should take care of the need for any new event processing and call-back resolving. Access to the port internal object is implemented via the following libraries: GraphLib provides an interface to the Graph widget. The standard Graph attributes and resources such as background colour, axis type and location are predefined and the user can select a desirable one from the list. The library allows the creation of an arbitrary number of plots on the graph at run time and the modifications of their attributes (style, limits). DigitLib is an interface to the Digit widget, a module unit for the creation of different numeric tables. The library allows the creation of a table to show numeric data in the specified format. KnobLib is a library to access the Wheelswitch widget. It allows the addition of a new wheelswitch to the desired port, the definition of an editing mode and output of the data. A standard library function will be called when data are modified. GraphBar is a complex object for managing the internal graph parameters such as scaling, editing and zooming modes. It includes a menu object for switching at run time the application variables to be displayed on the graph, selecting them from the pre-defined list. A number of applications such as Orbit measurement and Correction and Tune Control were developed using Graph Port for G U I creation. It was shown that the Graph Port tool fully covers the requirements of such kind of application and significantly diminishes the coding effort.
3. Synoptics For a number of accelerator control application, a G U I should be developed which displays a synoptic
425
diagram of the controllable facilities, showing the geographical or functional layout of the equipment. Most of the engineering systems such as vacuum, cryogenic, RF facilities have this requirement. In this case a control screen should contain a static picture representing the functionality or equipment location (background) and active control tools for equipment control. If the controllable object is rather simple and can thus be described by a single status or variable, control can be implemented on the diagram itself. Otherwise, a specialised control panel should be called similar to the device front panel for local control. In both cases an icon is representing a device on the synoptic diagram. It is an entry point for more detailed and specific control. The icon can represent a device status by changing a colour or pictogram. Such a complex icon we call a token. The components of a synoptic G U I are described in below. A Synoptic Background can be developed with any modern graphical editor creating an output file in GIF format. For many engineering systems the technical and design drawings exist in A U T O C A D format; a utility was developed to convert existing drawings to form the Background. The controllable devices are described in A U T O C A D as a block with attributes specifying the device name, type and control options. The utilities then create a set of files including a background file in GIF format and a control elements (token) description file in U I L format. The library allows one to have up to eight different backgrounds for the control screen and change them at run time. A Token is shown on the synoptic diagram as a button with a pictogram reflecting the functionality of the controllable device. All actions with Token are done by selecting options from a pop-up menu which is attached to the current token at run time by name. A standard menu contains a set of options applied to a wide range of devices (open control panel, show control value). The library allows one to create a specific option and connect it to functions either from a defined set or supplied by the user. A Token can be created with a real device name specification or one for a virtual device. In this case the token is attached to the real device at run time. This feature is useful when developing the control screens for a facility with a large quantity of equipment of similar type. In this case only one screen template needs to be developed, showing a small periodical part of the facility and the application at run time reads the information from the database (in our case Oracle dB) and makes an attachment of the virtual token to the real equipment. Control Panel is a main tool for manipulating the device parameters. Control Panel itself is an empty container and carries a number of control blocks. Panel has the name and device name attribute as well as a VII. SOFTWARE ENGINEERING
426
L. Kopylov et al. /Nucl. Instr. and Meth. in Phys. Res. A 352 (1994) 424-426
Fig. l. An example of an application control screen developed with tool kit.
few buttons to manage the control blocks appearance. Panels are created dynamically in run time from the templates so that for many devices of a similar type only one template needs to be developed. It will be multiplied by a library call with actual device name specification. The control blocks are the module units to carry out a specific control function. There are two types of control blocks, one placed inside Panel and one outside. The major difference is in their size. The small blocks are placed inside the panel. Large blocks with variable size like graphs, histograms are placed in separate windows (or Graph Ports) with their own control buttons. The analysis of device functionality shows that for the most type of equipment only a restricted set of control modules is enough to implement the Control Panel. Such a set was developed. It allows one to show
status and device indicators, to show and modify variable parameters in graphical form, to present history and operational statistic, and to control device timing. On the basis of these synoptic tools a number of applications has been implemented. One of these is the control screen shown in Fig. 1. This is the vacuum control for LINAC2 (CERN). The existing design drawings were used to create the screen background. Four types of device are shown by using different token pictograms. A control panel for ion pump and number of graphs are shown as well.
4. References
[1] P. Antonsanti et al., Workstations as Consoles for the CERN-PS Complex, setting up the environment, ICALEPS-9I, Tsucuba, 1992, KEK Proceedings.
NUCLEAR INSTRUMENTS & METHODS IN PHYSICS RESEARCH Section A
Tools for man-machine interface development in accelerator control applications L. Kopylov *, M. Mikhev, N. Trofimov, V. Yurpalov IHEP, Protvino, Russia
For the UNK Project a development of the Accelerator Control Applications is in progress. These applications will use a specific Graphical User Interface for data presentation and accelerator parameter management. A number of tools have been developed based on the Motif Tool Kit. They contain a set of problem oriented screen templates and libraries. Using these tools, full scale prototype applications of the UNK Tune and Orbit measurement and correction were developed and are described, as examples. A subset of these allows the creation of the synoptic control screens from the Autocad picture files and Oracle DB equipment descriptions. The basic concepts and a few application examples are presented.
1. Introduction As a part of the U N K Control Project, the development of a Graphical User Interface (GUI) for the application software is in progress. The G U I is being developed in the environment of the de-facto standard X-Window and Motif Tool Kit graphical systems. These systems provide a wide range of capabilities for G U I creation but they are not sufficient for accelerator control applications. Firstly, the existing set of graphical objects - widgets - in this system does not cover the requirements in G U I for accelerator control. For example Motif does not provide even a primitive object for 2D graphics, but the accelerator control applications require complex graphical objects for numeric data presentation such as graphs, tables and different tools for editing data. Secondly, these systems are rather complex to use and require a deep knowledge and considerable experience on the part of the application programmers even for solving trivial tasks. Even for the experienced programmers it is a tedious job due to the low level interface of the graphical systems libraries. The complexities of the objects used by application programmers should not exceed the complexity of developing the functional part of the application. The way to solve these problems could be to develop a specialised tool kit for the application designer that would allow the use of the full power of the X-Windows and Motif Toolkit systems but which would also liberate an application programmer from the routine job of developing the standard graphical objects needed of G U I for accelerator control. This tool kit * Corresponding author.
should contain a package of libraries, utilities and templates solving the problems mentioned above. We have developed such a package and are using it for the U N K control application. Components of this package and two application examples are described below.
2. Graph port One of the main tasks of the G U I is numerical data presentation and manipulation. An extension of the Motif Toolkit capability is given by the widgets developed in the C E R N PS control group, such as Graph, Digit, Wheelswitch [1]. They cover the needs of application programs for numeric data presentation, but they do not solve the problem mentioned above completely. A design procedure can be simplified by using one of the visual packages such as V U I T (Visual User Interface Tool) or X-Designer, but these packages allow the creation of a static interface as the geometry and resources of the widgets are defined in the coding phase. The goal is to develop an intermediate software layer which hides from the users the low level libraries and provides functionally powerful and habitual interfaces to the widgets mentioned above. The solution to this problem leads to the Graph Port concept. The Graph Port is a complex object built on the basis of C E R N PS widgets which has a software interface in GKS style and provides an internal coupling between the widgets that form it. Graph Port is implemented in the form of a library package that creates an application program interface to the graphical widgets. The Graph Port itself is a container for the different G U I components. It can be placed in a separate window or share the window with other ports or wid-
0168-9002/94/$07.00 © 1994 - Elsevier Science B.V. All rights reserved SSDI 0168-9002(94)00066-G
L. Kopylov et al. /Nucl. Instr. and Meth. in Phys. Res. A 352 (1994) 424-426 gets. The geometry and content of the Graph Port and its components may be constructed by VUIT. The internal identifiers and call-backs are hidden from the user, only the port identifier and elements identifier are visible outside. The library allows the creation of the dynamic connections between application data sets and the Port's internal elements via an object called Link. Link is established at run time and keeps data coherency between the coupled port elements and data sets. The application programmer does not need to care about data modification in all elements connected to the Link as this action is done by one call per Link. The Graph Port toolkit comprises a set of predefined port configurations and templates corresponding to the different requirements of specific applications. Users can construct an application from existing ports or modify port templates and add new elements to them. However when adding a new element, the user should take care of the need for any new event processing and call-back resolving. Access to the port internal object is implemented via the following libraries: GraphLib provides an interface to the Graph widget. The standard Graph attributes and resources such as background colour, axis type and location are predefined and the user can select a desirable one from the list. The library allows the creation of an arbitrary number of plots on the graph at run time and the modifications of their attributes (style, limits). DigitLib is an interface to the Digit widget, a module unit for the creation of different numeric tables. The library allows the creation of a table to show numeric data in the specified format. KnobLib is a library to access the Wheelswitch widget. It allows the addition of a new wheelswitch to the desired port, the definition of an editing mode and output of the data. A standard library function will be called when data are modified. GraphBar is a complex object for managing the internal graph parameters such as scaling, editing and zooming modes. It includes a menu object for switching at run time the application variables to be displayed on the graph, selecting them from the pre-defined list. A number of applications such as Orbit measurement and Correction and Tune Control were developed using Graph Port for G U I creation. It was shown that the Graph Port tool fully covers the requirements of such kind of application and significantly diminishes the coding effort.
3. Synoptics For a number of accelerator control application, a G U I should be developed which displays a synoptic
425
diagram of the controllable facilities, showing the geographical or functional layout of the equipment. Most of the engineering systems such as vacuum, cryogenic, RF facilities have this requirement. In this case a control screen should contain a static picture representing the functionality or equipment location (background) and active control tools for equipment control. If the controllable object is rather simple and can thus be described by a single status or variable, control can be implemented on the diagram itself. Otherwise, a specialised control panel should be called similar to the device front panel for local control. In both cases an icon is representing a device on the synoptic diagram. It is an entry point for more detailed and specific control. The icon can represent a device status by changing a colour or pictogram. Such a complex icon we call a token. The components of a synoptic G U I are described in below. A Synoptic Background can be developed with any modern graphical editor creating an output file in GIF format. For many engineering systems the technical and design drawings exist in A U T O C A D format; a utility was developed to convert existing drawings to form the Background. The controllable devices are described in A U T O C A D as a block with attributes specifying the device name, type and control options. The utilities then create a set of files including a background file in GIF format and a control elements (token) description file in U I L format. The library allows one to have up to eight different backgrounds for the control screen and change them at run time. A Token is shown on the synoptic diagram as a button with a pictogram reflecting the functionality of the controllable device. All actions with Token are done by selecting options from a pop-up menu which is attached to the current token at run time by name. A standard menu contains a set of options applied to a wide range of devices (open control panel, show control value). The library allows one to create a specific option and connect it to functions either from a defined set or supplied by the user. A Token can be created with a real device name specification or one for a virtual device. In this case the token is attached to the real device at run time. This feature is useful when developing the control screens for a facility with a large quantity of equipment of similar type. In this case only one screen template needs to be developed, showing a small periodical part of the facility and the application at run time reads the information from the database (in our case Oracle dB) and makes an attachment of the virtual token to the real equipment. Control Panel is a main tool for manipulating the device parameters. Control Panel itself is an empty container and carries a number of control blocks. Panel has the name and device name attribute as well as a VII. SOFTWARE ENGINEERING
426
L. Kopylov et al. /Nucl. Instr. and Meth. in Phys. Res. A 352 (1994) 424-426
Fig. l. An example of an application control screen developed with tool kit.
few buttons to manage the control blocks appearance. Panels are created dynamically in run time from the templates so that for many devices of a similar type only one template needs to be developed. It will be multiplied by a library call with actual device name specification. The control blocks are the module units to carry out a specific control function. There are two types of control blocks, one placed inside Panel and one outside. The major difference is in their size. The small blocks are placed inside the panel. Large blocks with variable size like graphs, histograms are placed in separate windows (or Graph Ports) with their own control buttons. The analysis of device functionality shows that for the most type of equipment only a restricted set of control modules is enough to implement the Control Panel. Such a set was developed. It allows one to show
status and device indicators, to show and modify variable parameters in graphical form, to present history and operational statistic, and to control device timing. On the basis of these synoptic tools a number of applications has been implemented. One of these is the control screen shown in Fig. 1. This is the vacuum control for LINAC2 (CERN). The existing design drawings were used to create the screen background. Four types of device are shown by using different token pictograms. A control panel for ion pump and number of graphs are shown as well.
4. References
[1] P. Antonsanti et al., Workstations as Consoles for the CERN-PS Complex, setting up the environment, ICALEPS-9I, Tsucuba, 1992, KEK Proceedings.