Eindhoven University of Technology
MASTER
A new user interface for the ARCS antenna- and RCS-measurement system
Derks, P.G.M.J.
Award date:
1991
Link to publication
Disclaimer
This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration.
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
I::D Yi5
EINDHOVEN UNIVERSITY OF TECHNOLOGYDEPARTMENT OF ELECTRICAL ENGINEERING Digital Systems Group
ANew User Interface for the ARCS Antenna- and RCS- Measurement System.
P.G.M.J. Derks
Master's Thesis
Supervisor: Prof. ir. M.P.J. Stevens Coach: Dr. ir. V.J. Vokurka
Date: january 1991 - october 1991
The department of Electrical Engineering of the Eindhoven University of Technology does
Abstract
The Theoretical Electrotechnology group at the Eindhoven University of Technology uses a large software package for the analysis of antenna and ReS measurements. This package consists of several large programs and a number of utility programs written in Fortran.
Software has been written to convert the current applications to the Xll/Motif environ- ment. After analysis of the requirements of the different application programs a set of user interface components is created. The creation of a user interface has been facilitated to a point where major parts of the user interface can be specified by filling structures which describe the user interface. In the software emphasis is put on the ease with which the user interface components are created and placed. This software has been integrated with the Fortran processing modules to create the new programs.
Acknowledgements
I wish to thank the following persons:
• My coach dr. Vokurka for making this project possible and his support.
• Professor Stevens for his advice.
• Bert Schluper at March Microwave Systems for answering all my questions regar- ding ARCS.
• Tonnie Geraets for finding bugs in my software and the helpful discussions.
• Several persons on the Usenet network in thecomp . windows.x and comp. windows. motif newsgroups.
Contents
1 Introduction 2 ARCS
2.1 Antenna and RCS measurements 2.2 Measurement system.
2.3 Software...
3 The HP antenna measurement system
3.1 The HP 8510 .
3.2 The HP 85360A Antenna Measurement system 4 Target Systems
4.1 PC and Unix system.
4.2 BASIClUX .
4.3 Data transfer . . . . .
5 Selection of windowing system 5.1 Introduction .
5.2 X .
5.3 Presentation Manager 5.4 Events and Queue's 5.5 Callbacks
5.6 Windows 5.7 XVT 5.8 Motif 6 Smalltalk
6.1 Portability .
6.2 Extensibility . 6.3 Prices and availability 7 U nix on a high level PC
7.1 Introduction . . . . .
7.2 X window system and Motif.
7.3 Fortran .
1 2 2 2 2 5 5 5 6 6 6 6 9 9 9 9 10 10 10 11 11 13 13 13 13 14 14 14 14
7.3.1 f2c.
7.4 Selection .
8 Interfacing C to Fortran 8.1 Calling Fortran from C 8.2 Fortran source code . . 9 A new User interface for ARCS
9.1 Concepts . . 9.2 Dialog boxes 9.3 Menu bar . . 9.4 Entry fields . 9.5 Option menus 9.6 Drawing area . 9.7 Help . .
9.8 Layout . . 10 Requirements
10.1 Image .
10.1.1 Description . . 10.1.2 Requirements.
10.2 Imgate . . . . 10.2.1 Description . . 10.2.2 Requirements.
10.3 Menu2D and 3D . . . 10.3.1 Description ..
10.3.2 Requirements.
11 First test
12 Implementation using the Motif widget set 12.1 Table widget
12.2 Entry fields . . . . . 12.2.1 Focus . . . . 12.2.2 Specification 12.2.3 Callbacks 12.3 Option menus 12.4 Menubar . . . 13 Mutual influence
13.1 Description ..
13.2 Implementation.
14 Conclusions
15 15 17 17 17 18 18 18 18 19 19 19 19 19 21 21 21 21 22 22 22 23 23 23 26 27 27 27 27 27 29 29 30 32 32 33 35
A Organization of the sources B Source RCS19.C
C Calling Fortran from C D Rcs19f.f
37 38
42 43 E Overview of programming environments for Presentation-Manager and
XII (Motif). 47
E.! XVT 47
E.2 Aspect 48
E.3 Open Interface 48
EA GKS... 49
E.5 Matlab . . . . 49
E.6 Custom interface . 49
E.7 Two seperate interfaces 50
F Table widget documentation. 51
Chapter 1 Introduction
The Eindhoven University of Technology and March Microwave have developed a sofware package for the analysis of antenna and radar cross section measurements (ARCS). This software runs on VMS VAX and HP- UX machines. Under the VMS operating system graphical output is sent to a VT240 terminal and on HP-UX systems the Starbase graphics library is used. The software is developed over a number of years and the user interface and the presentation of data are presently outdated. HP has developed its own antenna measurement package which has a very nice user interface. The processing capabilities of this system are very limited (only antenna analysis) and extremely slow. As a result of this only the acquisition part of the software is usable. The ARCS software has very strong processing capabilities and is much faster than the HP software. If the user interface of ARCS would be made more up to date and easier to use this would be a most useful addition to the HP system. This new version of ARCS will have to run on OS/2 systems and Unix systems, this automatically means Presentation Manager and the X window system.
Chapter 2 ARCS
2.1 Antenna and ReS measurements
Antennas are designed primarily to give a specific distribution of energy in space while minimizing loss and reflections. To evaluate the design of an antenna several measurements are made which include radiation patterns, polarization and beam direction to name a few. RCS (Radar cross section) measurements are used to obtain information about the visibility and detectability of objects with radar.
It
also is valuable as a means of identifying targets, for which time-domain techniques are invaluable. By imaging targets with the use of inverse synthetic aperture radar techniques, resolution in down-range and cross-range can be obtained.2.2 Measurement system
A typical system for antenna and RCS measurements consists of a range with a receiver, a transmitter and instrumentation. On the transmitter side we have a frequency synthesizer and sweep generator and on the receiver end we have a network analyzer which also gets input from the synthesizer to measure phase and amplitude characteristics. The synthesizer and network analyzer are controlled by a computer. This computer also controls a positioner controller which in turn drives a positioner. The elevation and azimuth of the antenna or test object can be altered with the positioner. In an anechoic chamber a parabolic or two cylindrical reflectors can be used to produce a flat wave front.
Currently only one hardcopy output device is support, a HP plotter or any other HP-GL device.
2.3 Software
ARCS consists of a large number of programs written in Fortran.
• ARCS: Acquisition and calibration program
• Menu2D: 2 Dimensional presentation of results
• Menu3D: 3 Dimensional presentation of results
HP-IB
HP 8510 Computer
~
Synthesizer PlotterV
Positioner Positioner
Controller
Figure 2.1: Antenna measurement system
HP-IB RS232
HP 8510 VAX VT240
Controller Plotter
Figure 2.2: ARCS systen using VAX
HP-IB
HP 8510 HP 9000
Controller Plotter
Figure 2.3: ARCS systen using HP 9000
• Image: 2 Dimensional Fourier transformation
• Imgate: Image gating
• Filemath: File mathematics, data files can be added, subtracted etc.
• RCSxx: Several programs to generate data files
Most programs are menu driven and the inputs are checked for correctness. A notable aspect is the fact that in several programs menu items influence each other. This means that as a result of the entry of one value the range or the value of another parameter is changed. The user interfaces of the programs are not very consistent, some programs use the F20 keys to exit, some the FlO key and others the F5 key. Some of the programs have a question and answer interface.
Chapter 3
The HP antenna measurement system
3.1 The HP 8510
The HP8510 network analyzer has become the defacto standard device for antenna measu- rements in recent years. Itis a vector network analyzer which measures the magnitude and phase characteristics by comparing the incident signal with the signal transmitted through the antenna or reflected from its input. The HP 8510 can also perform Fourier transforms on data stored in its internal memory. The device can be programmed by a computer through the GPIB bus (IEEE 488). Several vendors of antenna measurement systems use this analyzer as acquisition device.
3.2 The HP 85360A Antenna Measurement system
To compete in the antenna measurement systems market HP has introduced a complete sys- tem for this purpose.Itconsists of a HP Rocky Mountains basic workstation (HP9000/320), a HP plotter and a HP8510 system. The workstation controls the devices with the GPIB bus. The software for the workstation consists of four programs:
1. Measure: This is used to configure and perform the measurement.
2. View2D: 2 Dimensional presentation of the acquired data.
3. View3D: 3 Dimensional presentation of the acquired data.
4. Standard: To enter the published performance characteristics of a standard gain horn.
The sofware consists of some 30000 lines Basic and 600 kilobytes of compiled subroutines.
The graphical user interface is contained in these compiles subroutines. This interface is cute but impractical and inconsistent in places (see: Survey of the HP antenna Measurement software). The software is adequate for antenna measurements but ARCS has more and better characteristics. Therefore March wants to build an add-on system which connects ARCS, including the RCS software, to the HP system. In this configuration the HP system would merely be used for acquisition while processing and presentation are done by the new ARCS software. There are a number of ways to do this, these possibilities are explored in the next chapter.
Chapter 4
Target Systems
4.1 PC and Unix system
We do not want to port the ARCS software to the HP Basic workstation so a second system must run the processing software. Two configurations are desirable:
1. High level PC running OS/2 2. HP workstation running Unix
The current OS/2 version is 1.3 which still runs on 286 class machines. The windowing system included with OS/2 is called the Presentation Manager. The next OS/2 release will be a 32 bit version and this means that porting a Unix application to that version of OS/2 will become much easier. One can also expect that the X Window system will be ported to OS/2. The HP workstation will be running HP's own version of Unix. This Unix is based on System V and HP has provided a number of BSD extensions including TCP /IP.
4.2 BASIC/UX
HP has a product with which it is possible to run HP Basic programs on HP- UX. The current release of the HP antenna measurement software uses precompiled subroutines.
These are subroutines written in Basic and compiled with a Basic compiler. BASIC/UX does not support these precompiled subs and this makes it impossible to run the antenna software on HPlUX. The next release of the antenna software will run on BASIC/UX.
This means that a configuration will be possible with only one HPlUX system which will run both the new ARCS software and the HP antenna software.
4.3 Data transfer
There are a number of possibilities to transfer the acquired data to the processing system.
The options are:
1. floppy
2. RS232
3. IEEE-488
Positioner
HP-IB
HP-8510 HP-BASIC OS/2 system
Figure 4.1: PC configuration
Positioner
HP-IB
HP-8510 HP-BASIC HP-UNIX
Figure 4.2: HP configuration
Positioner
HP-851O HP-UNIX
Figure 4.3: Single HP Unix system
4. TCP/IP
Walking around with floppies or serial transport using RS232 are not really options because the amount of data can be quite large. The HP Basic system can be equiped with an ethernet card but there is no software support. Third party software is available but this does not implement a TCP /IP server mode. All HP systems are equiped with IEEE-488 (HP-IB or GP-IB) interfaces and HP Basic and HPlUX support this interface. The IEEE- 488 interface has a transfer rate of 10 megabyte per second which is quite adequate for file transfer. In the last configuration (single HP- UX system) there is no file transfer problem because BASIC/UX uses the standard file system.
Chapter 5
Selection of windowing system
5.1 Introduction
I have tried to find the differences and similarities between the OS/2 presentation manager and X and have done a comparison of some of the key elements of the systems. One major difference is the fact that in the X environment the server (the display) and the clients (the application programs) are not necessarily running on the same computer.
5.2 X
The standard graphical environment for Unix systems is the X window system. Ithas been developed during several years at MIT and DEC. The X window system is known by the names X11, X version 11 or just X. X is a message passing system, X clients (application programs) send requests to an X server. X organizes windows as a hierarchy, referred to as the window tree. The top window in this window tree is known as the root window/ The X server automatically creates a root window for each screen it controls. The root window occupies the entire physical screen, and cannot be moved or resized. Every window except the root window has a parent window and can have one or more child windows. Windows which share the same parent are called siblings.
X in its most basic form comes with Xlib which is a library of functions which create and send requests. This is the lowest level of X programming. There are several toolkits available to facilitate programming applications for X. These toolkits are built on the Xt Intrinsics. The Xt Intrinsics serve as a framework that allows programmers to create user interfaces by combining an extensible set of user interface components. These components are called widgets. The widgets determine the look and feel of a program. There are several sets of widgets available, for instance the Athena widget set, the OSF/Motif widget set and the Open Look widget set.
5.3 Presentation Manager
The Presentation Manager is the primary application environment under OS/2. Program- ming for PM is done with the PM application program interface (API). The user interface
and the API of PM are largely derived from Microsoft Windows. Currently OS/2 and PM are being updated. OS/2 2.0 will support the 80386 and 32 bit programs and the API of PM will become almost identical to the MS Windows 3.0 API. This will make the porting of programs from MS Windows to PM easier.
5.4 Events and Queue's
The windowing system needs to send messages to applications when keys are pressed, the mouse pointer moves, a mouse button is pushed etc. In X these items are called events and in PM these are called messages. The main information processing loop looks like this for
PM:
while (WinGetMsg (hab, &qmsg, NULL, 0, 0»
WinDispatchMsg (hab, &qmsg)
And this is the event processing loop for X:
done
=
0;while ( done
==
0 ) {XNextEvent ( mydisplay, myevent );
switch ( myevent.type ) {
5.5 Callbacks
A callback function is used by the windowing system to report events which have occured in a window to that particular window. The X toolkit provides the XtAddCallback function to register new callback functions. This means that callbacks are registered dynamically at run time. For PM callback functions must be declared in a special .DEF file at compile time.
5.6 Windows
One of the more basic functions of a windowing system is the creation of windows on the display. Table 5.1 contains a comparison of the calls used in PM and X.
One can see from this table that there are certain similarities in the parameters i.e. initial size and position of the window, but the order is different. Also different are the return values from the two calls, XCreateWindow returns a Window variable and WinCreate- Window returns hwnd which is a handle (pointer) to the window. Another problem are
the attributes or pControlData, this parameter determines the style of the window. This includes things like the width of the border and the gravity of the new window. These properties are defined as masks in the include files and these are 100% different. In PM the window exists after the call to WinCreateWindow but in X the window still has to be mapped on the display after it has been created with XCreateWindow.
5.7 XVT
From the abovementioned differences it is clear that we can't hide the differences between the windowing systems with some simple #define's. In appendix E we discuss the possible solutions for this. After evaluating these solutions we came to the conclusion that using a toolkit was the best option.
5.8 Motif
In Motif user interfaces are built using widgets. A widget is an X window along with some procedures that manipulate the window. Each widget maintains a data structure that sto- res additional information used by the widget's procedures. Applications are constructed by combining widgets on the screen rather than opening a window and drawing everything yourself. Widgets behave like objects in an object oriented language. Widgets belong to classes of widgets that inherit properties from eachother. Also widgets take care of them- selves when expose or resize events occur. In addition to widgets, Motif provides a user interface component known as a gadget. Gadgets are identical to widgets, except that they have no window of their own. In plain X the programmer needs to deal with all these problems himself. To get acquinted with the object oriented architecture defined by the Xt Intrinsics and all the widgets provided by Motif takes at least as much time as learning a new programming language. An advantage of Motif is the built-in system to provide help with menu items and dialog boxes. The main loop for a Motif program looks like this:
while ( TRUE ) { Xevent event;
XtNextEvent(levent) XtDispatchEvent(levent)
The best way to represent and design a Motif application is by using a widget tree. The widget tree for a simple application could look like figure 5.1.
bb
(XmBulletinBoard)
do quit panel
(XmPushButton) (XmPushButton) (XmRowColumn)
frequency editl
(XmEdit)
Figure 5.1: Widget tree of a simple application
Table 5 1· Create window functions
..
Xll PM
XCreateWindow WinCreateWindow
display hwndParent
parent szClassNarne
x szText
y WS_...
width xStart, yStart
height xSize, ySize border-width hwndOwner
depth hwndOrder
class idChild
visual pControlData
valuemask pPresParams attributes
Chapter 6 Smalltalk
Smalltalk is an object oriented programming language and environment. It is very well suited for the design of graphical user interfaces. It uses the underlying windowing system but uses it's own flavor of windows, popup menu's and dialog boxes. Smalltalk also acts as an execution environment. Executable programs are stored in p-code. Applications are neither compiled nor interpreted but there is a cache in memory where code is stored after it has been compiled and executed for the first time. Succesive execution of the same code is therefore much faster. An application designed with Smalltalk is somewhat slower than an identical application written in C++.
6.1 Portability
There are two major versions of Smalltalk, Smalltalk V and Smalltalk 80. Smalltalk 80 runs on Apollo, Sun and other Unix systems. Smalltalk V is available for MS DOS, Windows 3.0 and OS/2 PM. Porting a large design package from Smalltalk V to Smalltalk 80 at the digital systems group took three months.
6.2 Extensibility
Smalltalk comes with a large library of objects and methods. This is not only convenient but necessary because Smalltalk is a closed system, interfacing to other languages is possible but difficult.
6.3 Prices and availability
The University has a site license which costs DM 2000 per year, for each platform an additional license of DM 300 has to be paid. Versions of Smalltalk are available for all popular systems, the University has versions for Apollo, Sun, OS/2 and MS DOS.
Chapter 7
Unix on a high level PC
7.1 Introduction
Since the introduction of the 386 microprocessor PC's have become powerful enough to run a complete Unix operating system. Unix has been implemented on the 386 by several vendors including AT&T, SCO, Dell, Interactive and Everex. The typical configuration needed to run Unix on a 386/486 computer consists of 4 MB ram (8 MB for X), 100 MB harddisk and a VGA card and monitor. Executables for one UNIX/386 system will work on any other UNIX/386 because all vendors adhere to the Intel ABI (application binary interface).
7.2 X window system and Motif
Each vendor of Unix for 386 systems also sells an X server for their Unix. Support of video cards differs greatly, all support the standard 640 by 480 16 color VGA card, and most servers come with drivers for several higher resolution boards. There is one public domain X server implementation available which supports resolutions of up to 1152 by 900 on a suitable monitor.
7.3 Fortran
There are at least 3 fortran compilers available for 386 Unix systems, these are Microsoft Fortran, LPI Fortran and Microway Fortran.
One report concerning the Microway Fortran compiler (also called NDP Fortran) stated that programs compiled with this compiler on a 486 33 MHz system with Weitek 4167 coprocessor ran just as fast as on a Sparcstation 2 (40 MHz). Microway is represented in Holland by Intra Electronics in Nuenen.
There exists also a public domain Fortran to C translator called f2c which originates from AT&T but this only supports Fortran 77 and not the VMS Fortran extensions.
Table 7 l' Fortran compilers for Unix 386
· .
Microsoft Fortran LPI Fortran Microway Fortran f2c
32bit code No Yes Yes Yes
VMS Fortran extensions Yes Yes Yes No
Weitek support No Yes Yes Yes
Price DM 2050 $ 799 f 2628 0
Educ. price -38% $ 500
-
07.3.1
f2c
The program f2c makes it possible to compile and run fortran programs on Unix systems which do not provide a fortran compiler. To do thisf2c translates the fortran code into C after which it is compiled by the native C compiler. The purpose off2c is not to convert fortran programs to C and then continue with the C program but f2c makes it possible to continue using existing fortran programs. The f2c program is written at Bell labs and available from the anonymous ftp site research.att.com. It can be used on any 32 bit Unix system which includes 386 Unix versions.
Included with f2c are two packages which emulate the normal Fortran libraries. To compile a program with f2c you just type f2c source. f, the resulting source. c includes f2c. h and has to be linked with -lI77 -lF77 -1m to create an executable program.
I have tried to compile the sources of the ARCS processing package with f2c and have had reasonable succes. Most mathematical routines compiled with no problems but several modules dealing with the user interface wouldn't compile. A common source of error was the use of thetypestatement which isn't supported byf2c. Also all the programs which use the HP Starbase library can not be compiled because the Starbase library is not available for 386 systems running Unix.
7.4 Selection
Our initial target systems were OS/2 and Unix. This means that the ARCS software packa- ge should run under PM and the X window system. Because of the substantial differences between these two windowing systems we have been looking for a toolkit which creates a common programming interface to the two windowing systems. After some research we only found XVT to be a reasonable choice. However, this choice has some disadvantages.
Ifwe were to choose XVT this would have the following consequences: To start developing in XVT we would need the PM Toolkit which costs £1000,- and XVT for OS/2 which costs
$795. To develop on the HP340 machines at March we would only need XVT for Motif and this costs $3495. The total cost would be around f9600,-.
Another problem asociated with XVT is the fact that we would become 100% dependent on this product and the company which sells it. Sources are available for $5000 to $10000
depending on the platform but this would mean that March should do the maintenance on XVT if PM and/or Motif would change.
Because market acceptance for OS/2 is still very low it was eventually decided to drop OS/2 as target system. This did not mean we also dropped a 32 Bit PC as hardware platform because such a PC can also run Unix and the X Window system. This facilitates our decision because we are only left with a single windowing system.
Chapter 8
Interfacing C to Fortran
8.1 Calling Fortran from C
It is relatively easy to interface Fortran to C, the calling conventions are the same for C and Fortran. Ints in C become INTEGERS in Fortran and floats become REALS. The variabels are passed by reference, so the parameters from C must be passed with adresses or pointers. Strings are not null terminated in Fortran but are stored as a length count followed by the string itself. To pass strings from C to Fortran the string itself must be passed and as extra parameter the length of the string must be passed as the last variable in the parameter list. Passing strings from Fortran to C only involves appending an extra '\0' to the string. Linking must be done with cc or themain function will not be found. To resolve the problem of undefined externals which arise when linking C and Fortran objects the following libraries must be added to the link command: libF77.a, libI77.a and libFext.a.
8.2 Fortran source code
The Arcs package is almost entirely written in Fortran. Heavy use is made of non Fortran 77 features. The programs have to be altered in order to make it possible to call them from C as subroutines. This is a very laborous task because the interface to the user is not always confined to one module, which makes it necessary to rewrite large parts.
Chapter 9
A new User interface for ARCS
9.1 Concepts
There are a number of goals we want to achieve with the new user interface:
1. Transistion from the old user interface to the new must be simple.
2. Uniform user interface for all ARCS programs.
3. The interface must be easily adaptable for new programs.
To achieve the last goal we must isolate the application-dependent code as much as possible from the user-interface code. The precise user interface for any particular ARCS program must be specified as much as possible in structures and include files and not be hard-coded in the application. In the next paragraphs common requirements for all applications are discussed.
9.2 Dialog boxes
Dialog boxes are popup windows which can be used for several purposes. An example is a file selection box, this is a popup dialog in which a number of items are displayed. The file selection box must consist of a window which displays the files in a directory, a directory specification area and a filter area. The filter can be used to enter a wildcard string against which the files in a directory are checked. Dialog boxes can also be used for warning and error messages and to inform the user that a time consuming operation is running.
9.3 Menu bar
A menu bar is a horizontal bar in which a number of labels are placed. Ifa label is activated, either with a key combination or by using the mouse, a pulldown menu appears in which an item can be selected. An item in a pulldown menu can itself consist of another pulldown menu. This second pulldown menu must be placed adjacent to the already visible pulldown menu.
9.4 Entry fields
There are four types of field items:
• Normal fields
• Fixed fields
• Calculated fields
• List fields
All fields consist of a label field and an entry field. Normal fields are used to change numeric or alphanumeric values, for instance start and stop frequencies and labels of axes. The entry field is right next to the title field, if the mouse pointer is in the entry field the user can type a value. The one exception to these rules are file names. To input a filename a file selection box is used. Fixed fields are displayed in a different color than normal fields. In these fields parameters are shown which follow directly from the input file(s). Calculated fields show parameters which are calculated as a result of the values entered in normal fields.
These parameters are shown in another different color. List fields are used for parameters for which only a fixed (small) set of choices is possible, they are described in the next paragraph.
9.5 Option menus
An option menu is a list of choices of which one can be chosen. On the screen the option menu is displayed as a button, if a mouse button is clicked on the button a list pops up which displays the list.
9.6 Drawing area
All ARCS programs use graphics to display measurement and processing results. This means that we have to reserve an area on the screen for these graphics, such an area is known as a drawing area.
9.7 Help
Every menu item, push button or radiobutton must be accompanied by a context sensitive help page.
9.8 Layout
All programs must have a uniform layout and identical functions in all programs must work the same way. All applications will consist of three major elements, a menu bar on top, a large drawing area on the left side and a list of entry fields on the right side of the screen. (See figure 9.1)
Menu bar
Drawing area
Table
Status line
I
Figure 9.1: General screen layout
We have chosen for a fixed screen layout to make the user interface as uniform and con- sistent as possible. The menu bar on top will hold a title, common pulldown menus for file selection and the quit button. If the entry form on the right side is not big enough to hold all the entries there will be several pages on top of each other. Entries will be grouped in logical sets and each entry form will have a title. We are deliberatly not using all the features (like popup menus) which Motif gives us to make the learning curve as low as possible for users who are familiar with the old ARCS software or the HP antenna measurement package.
Chapter 10 Requirements
10.1 Image
10.1.1 Description
The IMAGE program is used to calculate an image by performing a 2-dimensional Fourier transform of the measured RCS as function of frequency and aspect angle. The down- range response essentially is the Fourier transform to the frequency response of the target obtained with a frequency ramp. The cross-range response is the Fourier transform of the angular variation of the reflection.
10.1.2 Requirements
Image currently consists of two menupages, a text only entry form and a graphics screen in which a simple 2D cartesian plot can be made. To aid in choosing the parameters it will be possible to place markers in the graph. If a user clicks a mouse button on the marker a small text window will appear above the marker which diplays the span (the span is determined by the resolution), center angle and other parameters (and a close option to remove the text). The entry form has these fields:
• Input file
• Output file
• Function (read from file, HH or VV)
• Window (Normal, Hanning, Hamming etc.)
• Correction (On/Off)
• Start frequency
• Stop frequency
• Number of frequencies (read from file)
• Start angle (read from file)
• Stop angle (read from file)
• Number of angles (read from file)
• Cross Range Cell size Resolution
Target size Number of cells Total image size Points per cell
• Down Range
Cell size Resolution Target size Number of cells Total image size Points per cell
• Processing Error
• Center minimum
• Center Maximum
• Angle span
• Center angle
In the graphics page of Image markers can be used to read the value of the function and set various parameters. There are also three softkeys, Exit, RCS plot and Process. Process and RCS plot will become pushbuttons.
10.2 Imgate
10.2.1 Description
Imgate is used to remove or isolate rectangular parts of an image and calculate the resulting RCS. After the first 5 items are entered (see next paragraph), imgate draws a contour plot on the screen. In this plot the rectangular area can be selected by giving center and span (vertex) or start and stop points.
10.2.2 Requirements
Imgate consists of one page, on the right side are adjustable parameters and on the left side a list of instructions is displayed. After the first parameters are entered a contour plot is placed over the instructions. The entry form has these fields:
• Input file
• Output file
• Function (read from file, HH or VV)
• Down Range (of graph)
• Cross Range (of graph)
• Contour (list of number of levels)
• Gate shape (minimum, normal, maximum)
• Down Range (start, stop)
• gate
• #cells
• Cross Range (start, stop)
• gate
• # cells
• Mode (general, bandpass, bandstop)
• Filter
db within gate db outside gate
Selection of the rectangular section can be done in two ways: by selecting center and then moving the mouse to a vertex or by selecting one vertex and moving to the other vertex.
10.3 Menu2D and 3D
10.3.1 Description
The Menu2D and Menu3D programs are used to display graphical data obtained from the measurements or processed measurements. The menus of these two programs are very similar. On VMS computers a VT240 terminal is used to display the graphs. The terminal is programmed with the REGIS language. HP 9000 computers display graphs on the console which in most cases is a 1024 by 768 pixel display. This display is programmed with the Starbase graphics library. These libraries are very different so the code which programs the displays is concentrated in a few routines. The new target will only be theX window system but we have also concentrated the output routines in one source file to make adaption to a different windowing system as easy as possible.
10.3.2 Requirements
Based on the current functions of the Menu programs we have made a list of the functions that should be present in the new programs. We obtained this information from the ARCS Graphics Reference Manual. This took some time because this manual is a classic example of how manuals shouldn't be written.
1. Grid: The type of graph is chosen in this menu
• Cartesian
• Polar
• 2 Polars
• Polar
&
Cartesian• Cartesian
&
Polar• Horizontal split
• Vertical split
2. Graph: Two graphs can be displayed at anyone time, they are called A and B.
3. File: Filename
4. Function: Name of the function to be displayed, the names are extracted from the data file.
5. Axis names 6. Axis range
7. Axis types: choose from
• Log. mag.
• Phase
• Lin. mag.
• Real part
• Imaginary part
• Nyquist (only contour plot in Menu2D) 8. Format range and contour levels
9. Output device:
• Display
• Plotter
• Table in file (Table must become a separate option)
• Table on display 10. Parameters
11. Size of comment
• Small, 77 characters
• Big, 38 characters 12. Graph giving the comment
• none
• A
• B
• A and B
13. Graph giving the annotation
• none
• A
• B
14. Viewing angle (3D only)
• isometric
• dimetric
• waterfall
15. Layout of contour plots:
• contour lines
• color map
• contour lines plus marginal plots
• color map plus marginal plots 16. Grid type (2D and contour)
17. Markers
18. Graph: graph for which the markers are set, A or B
19. Reference marker: One marker can act as a reference, here the marker number is shown
20. Marker to be operated
21. Narne of vertical independent grid axis (for reference only)
22. Vertical position display, if a value is entered here the marker jumps to the indicated value
23. Name of horizontal independent grid axis (for reference only)
24. Horizontal position display, if a value is entered here the marker jumps to the indicated value
25. Format of the dependent grid axis 26. Function value (display only)
Chapter 11 First test
To test Motif and the development system I built a prototype application program using RCS19. This is a program which calculates and creates a data file that contains time domain (range) vs. aspect angle data. The program produces a data file which simulates the HP8510 network analyzer for uncorrected radar imaging with a question and answer style interface. The source of this program is given in appendix B
Chapter 12
Implementation using the Motif widget set
12.1 Table widget
Table is a composite widget designed to manage the size and location of its children.
Appendix F contains the entire documentation for the table widget. The widget uses an array model to simplify the arrangement of child widgets. The widget is directly derived from the core and composite widgets provided by the X Toolkit and can be used with any widget set. The Table widget addresses formatting for dialog boxes. Dialog boxes are rectangular windows that contain a wide variety of widgets. Most dialog boxes are arranged with widgets aligned in a way similar to the layout found in business forms. The Table widget is designed to make such layouts easy to specify.
When designing dialog boxes that resemble business forms, the primary problem is specify- ing the alignment between widgets. The Table widget addresses this problem by adopting an array model. Under this model, widgets are placed at row and column locations in a variable sized array. Widgets may span more than one row or column. The array can ex- pand or contract in pixels - as needed. There are options to control justification and place size restrictions on rows and columns of widgets.
12.2 Entry fields
12.2.1 Focus
When a text widget gets the focus i.e. is ready to take input the text_callback is called and the current contents of the widget is saved. When the user moves to another field the text_callbackchecks if the contents have changed. Ifthis is the case a recalculation takes place. This happens also if the return key is pressed. If the escape key is pressed the old contents of the text widget are restored.
12.2.2 Specification
The description of the layout and functions of the entry field is in the include file entries. h.
It would have been possible to put this description in a file which is read by the application
at start up time, but this would make it possible for ordinary users to change the file and thereby introduce errors. This is the structure which defines the entry fields:
struct entry {
String name; /* name of the widget to be created */
int widgettype; /* widget type */
int widgetindex; /* index to the created Widget */
String label; /* text which is in the label widget */
Position row; /* row in the table widget where the widget */
/* is to be placed */
Position col; /* column in the table widget where the widget */
/* is to be placed */
int width; /* number of columns for text widget */
Dimension h_span; /* horizontal span in columns */
Dimension v_span; /* vertical span in rows */
XtTblMask opt; /* options (See table widget documentation) */
void *varp; /* pointer to variable */
int var_type; /* type of variable */
};
Here follows a more precise description of the various parameters:
• name: The name of the widget, this can be used in a resource file to change re- cources of the widget.
• widgettype: the type of widget to be created, currently 3 widget types can be specified: TEXT_WIDGET, LABEL_WIDGET and SEPARATOR_WIDGET.
• widgetindex: This number must be an item from the enumeration which is declared in the main include file for the application.
• label: Ifthe widget is a label widget this field contains the text for the widget.
• row: The row in the table widget where the widget is to placed.
• col: The column in the table widget where the widget is to placed.
• width: Ifthe widget is a text widget this field specifies the width of the field in characters.
• h...span: The number of columns the widghet should span.
• v...span: The number of rows the widget should span.
• opt: Adjustment of the widget in the table widget (see Table widget documenta- tion).
• *varp: Ifthe widget is a text widget this is a pointer to the location of the variable which is associated with this entry field. If not, this field contains NULL.
• var_type: The type of variable the pointer (see previous item) is pointing to. Cur- rently 3 types are possible: TYPE.-NONE, TYPE-FLOAT and TYPEJ:NT.
By using the XmAddTabGroup function all the entry widgets are placed in a tab group. A tab group specifies a set of widgets within which the user can use arrow keys to traverse the widgets. With the functions set_text-widget-active and set-text_widget_inactive a
widget can be made part of the tab group or removed from it. A tab group must consist of a single container widget, in this case the table widget.
12.2.3 Callbacks
A single callback function is used for all the text widgets in the table widget. With the pointer and the type of variable from the specification structures the entered value can be checked. The widgetindex number is passed to the calculation module of the application.
12.3 Option menus
An option menu consists of the following widgets: a pulldown menu pane which holds the push button gadgets and the option menu widget. We want to use several option menus in the table widget but this creates a problem because an option menu consists of two widgets and the child of a table widget must be a single widget. We therefore use a bulletin board as an intermediate widget which holds the pulldown menupane and the optionmenu. There are a number of option menus in which the number of items change as a result of a change in certain parameters. An example of this in the IMAGE program is theNUMBER OF CELLS.
This option menu must be filled with powers of 2 starting with O.
i
=
0;while ( (i < MAXSER) tt «l«i) < number_of_freq) ) { nrcelldr[i]
=
l«i;i
=
i+l;}
As can be seen from this fragment of code the contents of the array can change if an other file is read (new number of frequencies). When we try to destroy the option menu (by destroying the bulletin board which holds it) the table widget starts resizing and rearranging all the widgets which takes a long time. To solve this problem we introduce another bulletin board widget which holds the bulletin board widget which contains the option menu. When we want to change the option menu we destroy the bulletin board widget which holds the option menu and we create a new one. (See figure 12.1) One item in an option menu is specified as follows:
to the callback
*1
active or not
*1
the name of the item
*1
mnemonic for the item
*1
callback to be invoked
*1
client data which is passed determines if the option is _option_struct {
*item;
1*
mnemonic;
1*
(*func)
0 ; 1*
data;
1*
sensitive;
1*
typedef struct char
char void caddr_t int
} option_struct;
Usually all the callbacks for an optionmenu will point to one callback function, the client data will be used to set the parameter associated with the option menu. However, this is not a requirement and different callbacks can be specified.
BulletinBoard
I
BulletinBoard
----
~PullDownMenu OptionMenu
PushButton PushButton PushButton PushButton
Figure 12.1: Option menu widget tree
12.4 Menubar
The menubar in the top row of the application consists of a number of buttons which when activated display a pulldown menu. In turn these pulldown menus can have pulldown menus attached to them. See figure 12.2 for an example.
To simplify the creation and changing of a menubar the menubar can be specified with the following structure.
name;
(*func) 0;
data;
*sub_menu;
n_sub_items;
*sub_menu_title;
typedef struct _menu_struct{
char*
void caddr_t
struct _menu_struct int
char
} menu_struct;
1*
name of the button*1 1*
Callback to be invoked*1 1*
Data for the callback*1
1*
data for submenu of this button*1 1*
How many items in sub_menu*1 1*
Title of submenu*1
The function which handles these structures interprets these in a number of ways. Each item in the topmost menu-.Struct (which creates the actual menubar) should have only a name and a submenu. The function which creates the menus loops through the array of menu entries creating an appropiate widget for each entry. Ifa title is given, the function creates a label widget as a title, separated from the rest of the menu by a separator widget.
For each item in the menu description, if the name of an entry is given as NULL,the function
I
Menu 1 Menu 2I
Item 1
Item 2 SubMenu
Item 3 Item 2A
Item 2B
Figure 12.2: Menu bar example
creates a separator widget. Ifthe entry has a name and a callback function, the function creates a pushbutton widget and assigns the callback. If the entry has a name, but no callback function, and the submenu member is NULL, a label widget is created. Finally, if a submenu is specified, the function creates an XmCascadeButton widget and a pulldown menu, and attaches the pulldown menu to the menu entry, after adding the entries in the submenu to the pulldown menu by calling the function recursively.
Chapter 13
Mutual influence
13.1 Description
The entry form of Image has some special problems associated with it because several entry fields influence other entry fields. As a graphical aid the original author has constructed a matrix in which the dependency relations are represented by a cross when one parameter influences another. A cross on the diagonal indicates that this parameter can be changed by the user. All the parameters are listed on the left hand side of the matrix and across the top. They are listed in the same order on the left hand side and across the top. By starting at the left hand side of the matrix you can see what other parameters change when the input parameter changes. The matrix has been arranged in such a way that a row parameter only influences parameters which are listed under that parameter. To avoid circular changes in parameters the lower left triangle of the matrix must be kept zero.
This is impossible to achieve for the parameters cell size Down Range and cell size Cross Range, so this must be handled as a special case. An m means that a change in the row variable results in a change in the boundaries of the column variable.
For instance if the target size is adjusted the maximum value for the corresponding points per cell array is affected.
i
=
0;while ( (1«i) > ( (OMAX-1)/nr_cell_dr ) ) { i++;
}
max_opt_dr_ppc
=
i;Cell size Down Range is used as a starting point for the initial calculations.
The original implementation in Fortran makes heavy use of computed goto's and is not commented at all. As a result it is almost impossible to change or add anything to the dependencies. The new implementation must facilitate the making of changes or additions in the dependencies.
1 2 3 4 5 6 9 10 11 7 8 17 23 12 18 13 19 14 20 15 21 16 22 24 25 26 27 28 Ilnpul file 1 x x x x x x x x x x x x x
Oulpul file 2 x
Function 3 x
Slar!f 4 x x
SlOpf 5 x x
# freq 6 x
Start angle 9 x
Slop angle 10
# anglea 11
Window 7 x x x x
Correction 8 x x
P/Cell DR 17 x m
P/Cell CR 23 x m
Cellaize DR 12 m m x x x x x x x x x x x x x x x
Cellaize cR 18 x x
Rea. DR 13 Rea. CR 19
Targelaz.DR 14 m x x x x
Targe18z. CR 20 m x x x x
# cella DR 15 m x x
# cella CR 21 m x x
Imagen. DR 16 Imagen. CR 22 Proc. error 24 Bore leU 25 Bore righ1. 26 Angle Span 27 Center anI:. 28
Table 13.1: Influence matrix for Image
13.2 Implementation
The influence problem is not unique for Image but occurs (in a much simpler form) also in other ARCS programs.
All the parameters are declared as global variables. Associated with each parameter is an array which holds function pointers to functions which calculate the value of a particular parameter. When an entry form (an xmText widget) loses the focus because the user has clicked on another widget or has used the arrow keys to move to another field, a function is called which calls all the functions listed in the dependency array for that parameter.
This structure is shown in figure 13.1
Figure 13.1: Influence array structure
Funktion 1
Funktion 2
Funktion 3
Funktion 4
Chapter 14 Conclusions
Itis relatively easy to convert existing applications to X windows with the written software.
Separating the user interface code from the processing code in the existing fortran sources is a very laborous task.
The choice of Motif to develop the user interface has been very appropriate, all requirements could be fulfilled with the Motif widget set.
The learning curve for Motif and the X window system is very high as a result of the complexity of the combination and the need to use Xlib functions in several cases.
A minimum completion and realisation of the conversion of the ARCS package to the X window system woul involve:
• Conversion of Imgate
• Conversion of Menu2D and Menu3D A completely new package would also involve:
• New version of ARCS data aquisition
• Batch processing
• Command history
• New file format
Based on the experience gained in this project I would estimate that this could take up to two years to realize with experienced programmers.
Bibliography
[:I.]
Usenet News: Frequently asked question (FAQ) list comp.windows.x.motif [2] Usenet News: Frequently asked question (FAQ) list comp.windows.x[3] ARCS File Reference Manual, First Edition, Release 1.2. March Microwave Systems B.V. august 1988.
[4] Kernighan, Brian and Ritchie, Dennis. The C ProgrammingLanguage Second Edition Prentice Hall, Englewood Cliffs, N.J. 07632
[5] A Fortran-to-C Converter, Computing Science Technical Report AT&T Bell Labora- tories august 1991.
[6] Geraets, A.G. A New Graphics Interface for the ARCS Antenna- and RCS- Measurement System. Master's thesis, Eindhoven University of Technology, Depart- ment of Electrical Engineering, october 1991.
[7] OSF/MotifProgrammer's Guide: Toolkit, Revision 1.0, 1989. Open Software Foun- dation, Eleven Cambridge Center, Cambridge, MA 02142.
[8] OSF/Motif Programmer's Reference Manual, Revision 1.0, 1989. Open Software Foundation, Eleven Cambridge Center, Cambridge, MA 02142.
[9] OSF/Motif Style Guide, Revision 1.0, 1989. Open Software Foundation, Eleven Cam- bridge Center, Cambridge, MA 02142.
[10] OSF/Motif Release Notes/Porting Guide, Revision 1.0.A, 1990. Open Software Foun- dation, Eleven Cambridge Center, Cambridge, MA 02142.
[11]
X Manual Set. Volume2:
X Library Interface, first edition, 1988. Addison-Wesley Publishing Company.[12] X Manual Set. Volume3: XIntrinsics & Athena Widgets,first edition, 1988. Addison- Wesley Publishing Company.
[13] Young, Douglas A. The X window system: programmingand applications with Xt / OSF/Motif edition. Prentice Hall, 1990.
Appendix A
Organization of the sources
The sources are located in the directory - paul/work/image. Imakefiles are present to build the executables. The subdirectory fortran contains Fortran sources of modules which are nessecary for the programs. There is an Imakefile to compile and link the Fortran modules to build a library. This library is linked with the C sources.
imagel.c Initializes the intrinsics and creates the form widget, the menubar, the status line and the table widget
image.h This include file is used by all the application dependent source files for imagel. Itincludes the necessary system include files and defines the struc- ture in which the global parameters are stored and the array and the enumeration for the widget identifiers.
entry.c Functions for filling and manipulating the entries in a table widget.
entry.h Defines the structure for the entry field declarations.
entries.h Contains the declaration of all the Text, Label and Separator widgets in the Table widget. This file has to be carefully synchronized with tabopts.c table_cb.c Common callback for the Text widgets in the Table widget.
tabopts.c Creation of the option menus in the table widget and callbacks for all these option menus.
tabopts.h Definitions of the structures used for the creation of the option menus.
popup.c Creation of the popup dialog boxes (including the file selection box).
options.c Functions used for creating and changing option menus.
options.h Defines the structure for the optionmenus declarations.
calc.h Contains definitions of some constants.
calc.c Functions to recalculate the entry fields when parameters are changed.
repfile.h Defines a structure which holds the fourth page of an ARCS report file.
readrep.c Reads an ARCS report file, returns a pointer to a structure which holds all the information.
libxs.h Definitions and prototypes for the functions from the xs library described in [13].
util.c Several utility functions.
color.h Definitions for the colors for the various parts of the user interface.
menus.h Definitions for the structures for the menubar declarations.
Appendix B
Source RCS19.C
/********************************************************************
* rcs19.c: Simple example of a new user interface for rcs19
*******************************************************************/
#include <X11/Intrinsic.h>
#include <Xm/Xm.h>
#include <Xm/Text.h>
#include <Xm/PushB.h>
#include <Xm/Label.h>
#include <Xm/BulletinB.h>
#include "libXs.h"
#define items 8 void get_text
0 ;
void the_endO;void calculate();
char *labels[itemsJ
=
{"Target number","Start frequency",
"Stop frequency",
"Number of freq.",
"Start angle",
"Stop angle",
"Number of angles",
"Filename"};
char *editors[itemsJ;
char *buttons[itemsJ;
main(argc, argv) int argc;
ehar *argv[];
{
Widget toplevel, bb, label[items], edit[items], button[items];
int i;
Arg al[40];
int ae;
toplevel = Xtlnitialize(argv[O], "Res1g",
NULL, 0 , large, argv);
ae=O;
/*
* Create the XmBulletinBoard widget that manages
* the edit fields.
*/
bb = XtCreateManagedWidget("board",
xmBulletinBoardWidgetClass, toplevel, NULL, 0);
/*
* Create single line XmEdit widgets
*/
for(i=O; i < XtNumber(editors); i++){
XtSetArg(al[ae],XmNx,120);ae++;
XtSetArg(al[ae],XmNy,i*30+10);ae++;
edit[i] = XtCreateWidget(editors[i],
xmTextWidgetClass, bb, aI, ae);
/* XtAddCallbaek(edit[i], XmNmotionVerifyCallbaek, e_enter,
*/
}
for(i=O; i < XtNumber(labels); i++){
XtSetArg(al[ae],XmNx,10);ae++;
XtSetArg(al[ae],XmNy,i*30+10);ae++;
label[i] = XtCreateWidget(labels[i],
xmLabelWidgetClass, bb, aI, ae);
}
/* Set up the GO Pushbutton and the quit button */
XtSetArg(al[ac] ,XmNx,30)jac++j XtSetArg(al[ac],XmNy,i*30+10)jac++j button[O]
=
XtCreateWidget(IQUIT",xmPushButtonWidgetClass, bb, aI, ac) j
XtAddCallback(button[O], XmNactivateCallback, the_end, NULL)j
XtSetArg(al[ac],XmNx,130);ac++;
XtSetArg(al[ac],XmNy,i*30+10);ac++;
button[l]
=
XtCreateWidget(IGO",xmPushButtonWidgetClass, bb, aI, ac);
XtAddCallback(button[l], XmNactivateCallback, calculate, NULL);
XtManageChildren(edit, XtNumber(editors))j XtManageChildren(label, XtNumber(buttons));
1*
Manage buttons*1
XtManageChildren(button, 2)j XtRealizeWidget(toplevel)j XtMainLoop
0 ;
}
void get_text(w, textwidget, call_value) Widget w;
Widget textwidget;
XmAnyCallbackStruct *call_value;
{
printf(" retrieving text: Yos\n", XmTextGetString(textwidget));
}
void the_end(w, flag, call_data) Widget w;
int *flagj
XmAnyCallbackStruct *call_data;
{
XtCloseDisplay(XtDisplay(w))j
exit(O);
}
void calculate(w, flag, call_data) Widget w;
int *flag;
XmAnyCallbackStruct *call_data;
{
rcs19(&fstop,&fstrt,&nfreq,&thstrt,&thstop,&nangle,name,&len,strlen(name));
printf(ICalculating\n");
}
Appendix C
Calling Fortran from C
\begin{verbatim}
#include<stdio.h>
#include<string.h>
char name [] =tltest 1ab tl ; mainO
{
float fstop,fstrt,thstrt,thstop,dc,dr;
int len,itarg,nangle,nfreq;
itarg = 1;
I*target(itarg,dc,dr);
*1
fstrt=8;
fstop=12;
nfreq=100;
thstrt=O;
thstop=89;
nangle=90;
len=strlen(name);
rcs19(&fstop,&fstrt,&nfreq,&thstrt,&thstop,&nangle,name,&len,strlen(name));
printf(tlfinished!\n tl );
}
Appendix D Rcs19f.f
C Author: H.F. SCHLUPER C PROGRAM RCS19
SUBROUTINE RCS19(FSTOP,FSTRT,NFREQ,THSTRT,THSTOP,NANGLE,NAME,NCH) C This program creates a data file that contains frequency
C domain (range) VB. aspect angle data for a target consisting C of point scatterers.
COMPLEX MEASRD(1025),RESPNS INCLUDE 'EXT.INC'
CHARACTER NAME*40,DAT*9,TIM*8,COMENT*80 REAL FSTOP,FSTRT,THSTRT,THSTOP
INTEGER NFREQ,NANGLE,NCH COMENT(1:80)=' ,
C CALL COPYRIGHT('RCS19I ','1.21') C TYPE *
C TYPE *,
C *'This program simulates the output of the HP 8510 for radar' C TYPE *,'imaging.'
C TYPE *,'It creates a file of RCS vs. frequency and asp. angle.' C TYPE *,'A number of scatterer configurations are predefined;' C TYPE *,'with target number 0 a configuration can be set up.' C TYPE *
PI=3.141592654 C=2.9979E8
C TYPE *,'Enter target number ., C READ(*,*) ITARG
C
C Moet rechtsreeks vanuit de callback van Motif worden aangeroepen
C
ITARG=1
CALL TARGET(ITARG.DC.DR)
C
C TYPE *
C TYPE *.'Enter start and stop frequency in GHz:' C READ(*.*) FSTRT.FSTOP
FSTRT=FSTRT*1.E9 FSTOP=FSTOP*1.E9 FO=.5*(FSTRT+FSTOP) B=FSTOP-FSTRT
C TYPE *.'Enter number of frequencies:' C READ(*.*) NFREQ
IF (NFREQ .EQ. 1) THEN FSTEP=O.
ELSE
FSTEP=(FSTOP-FSTRT)/(NFREQ-1) END IF
C TYPE *.'Enter start.stop angle in degrees:' C READ(*.*) THSTRT.THSTOP
C TYPE *
C TYPE *.'Enter number of angles:' C READ(*.*) NANGLE
THSPAN=THSTOP-THSTRT IF (NANGLE .EQ. 1) THEN
THSTEP=O.
ELSE
THSTEP=THSPAN/(NANGLE-1) END IF
C TYPE *.
C * 'Enter the name of output file (without extension):' C CALL READQ(NAME.40.NCH)
NAME=NAME(1:NCH)//EXTREP
OPEN(UNIT=1.STATUS='UNKNOWN'.FILE=NAME)
C Write page 1-4 of directory to file .REP WRITE(1,100) CHAR(12)
WRITE(1,100) CHAR(12) WRITE(1,100) CHAR(12)
100 FORMAT(A1)
NAME=NAME(1:NCH)IIEXTRCS
CALL RPHEAD(1,.FALSE.,NAME,DAT,TIM,COMENT,O,1,1) WRITE(1,140) 'SIMULATION'
140 FORMAT(A10) WRITE(1,600) 600 FORMATO WRITE(1,600) DO 1=1,3
CALL RPAXI S(1 , . FALSE. , , UNUSED
I ',0. DO, 0 . DO , ,
I ',0, ,
I ' , , I ' )END DO
CALL RPAXIS(1,.FALSE.,'ASP. ANGLEI',DBLE(THSTRT),
* DBLE(THSTOP),'degrl',NANGLE,'EQUII','I') WRITE(1,600)
CALL RPAXIS(1,.FALSE.,'FREQUENCYI',DBLE(FSTRT),
* DBLE(FSTOP),'Hzl',NFREQ,'CMPLX','sml') CLOSE(UNIT=1)
OPEN(UNIT=2,FILE=NAME,STATUS='UNKNOWN',ACCESS='DIRECT',RECL=
*4*2*NFREQ) TYPE 160,NANGLE
160 FORMAT(' Counting to ',14,' ... ',/) DO IANGLE=1,NANGLE
THETA=THSTRT+(IANGLE-1)*THSTEP TYPE 170,IANGLE
170 FORMAT('+',I4) THETA=THETA*PI/180.
ST=SIN(THETA) CT=COS(THETA) DO I=1,NFREQ
FREQ=FSTRT+(I-1)*FSTEP
MEASRD(I) =RESPNS(FREQ, ST,CT) END DO
WRITE(2,REC=IANGLE) (MEASRD(I),I=1,NFREQ)
Appendix E
Overview of programming environments for Presentation-Manager and XII (Motif).
There are several possibilities to unify the Presentation Manager and the X Windows programming environment, here is a list with the options we have:
1. XVT (Advanced Programming Institute) 2. Aspect (Open Incorparated)
3. Open Interface (Neuron Data)
4. GKS
5. matlab
6. custom interface 7. two separate interfaces
The first three possibilities are Application Programming Interfaces (API's), which unify PM and XII.
E.! XVT
Price: approx. $ 500 per platform (runtime-licence requirement unknown).
Advantages:
• The product offers the programmer a programming interface which is identical for XlI and PM, this means that a single version of the program can be written and maintained.
• The product has been on the market for a while.
• There are a number of manufacturers who support XVT. (for instance Desqview and Unisys)
Disadvantages:
• The product represents the largest common denominator of MS-windows, MAC, PM and XII.
• The product was originally designed for Macintosh and MS-Windows, X support was added later.
• Sources not available.
• No application generator available. (Application generators for X and PM can not be used.)
E.2 Aspect
Price: unknown.
Advantages:
• The product offers the programmer a programming interface which is identical for XII and PM, this means that a single version of the program can be written and maintained.
Disadvantages:
• Unknown company and unknown product: little guarantees for support III the future.
• Just recently available, probably not stable yet.
• No application generator available. (Application generators for X and PM can not be used.)
E.3 Open Interface
Price: $ 9000 - $ 12000 for development-kit (dependent of platform) $ 1000 for run-time version.
Advantages:
• The product offers the programmer a programming interface which is identical for XlI and PM, this means that a single version of the program can be written and maintained.
• Includes an interactive interface builder with which the framework for an applica- tion can be built.
Disadvantages:
• Rather expensive.
• The product represents the largest common denominator of MS-windows, MAC, PM and XII. (It appears to be less restricted than XVT).
• Sources not available.
• Unknown company and unknown product: little guarantees for support III the future.
• Just recently available, probably not stable yet.
