CA1292080C - Status driven menu system - Google Patents

Abstract

Abstract Menus displayed on a screen of an instrument permit an operator to adjust and monitor the operating state of the instrument. Various menus are added and removed from the display in response to changes in the operating state of the instrument so that those menus appropriate for the operating state of the instrument are automatically displayed while inappropriate menus are automatically removed from the display. Displayed menu items may be added, removed or modified in response to changes in the operating state of the instrument, as evidenced by changes in the configuration parameters, so that only those menu items which are appropriate to a given operating state are displayed.

Description

STATUS DRIVEN MENU SYSTEM

Background of the Invention The present invention relates in general to S ~ystems for configuring the operating state of an instru~ent and in particular to a system permitting an operator to control instrument configuration by making selections from menus displayed on a screen.
In recent years the number of selectable operating modes for instruments such as oscillo-scopes, logic analyzers and the like has greatly increased. For example, many oscilloscopes permit the display of selectable nu~bers of traces, and lS each trace may utilize o~e ~f many internally or externally generated time base signals for hori-zontal ~ontrol and one of two or more vertical input channels for vertical trace control. Each vertical input channel may haYe selectable probe coupling and termination modes and may also permit selection ~etween input ~i~nal inverting and noninverting modes. 5weep delay modes may be selected wherein a sweep sig~al controlling one trace is delayed by a selectable time following initiation of a sweep signal controlling another trace.
The advent of computer-~ased oscilloscopes has permitted a rapid growth in the number of functions which an oscilloscope may perform. Por example, a computer-based oscilloscope may utilize selected digitized waveform da~a stored in a memory to con-trol waveform display, may synthesize such waveform data on the basis of user-defined mathematical expressions, may self-calibrate portions of its circuitry, or may perform numerical measurements on 35 digitized waveform data and display the results.

~; ~

2 ~

As the number of selectabIe oscilloscope operating modes has increased, so have the number and complexity of control pushbuttons and knobs on oscilloscope front panels. Eventually, microcom-puter-based oscilloscopes were programmed to dis-play menus listing various operating modes and permitting an opera$or to choose from among listed operating modes utilizing pushbuttons on the oscillo-scope front panel to indicate menu selections. Use of such menus permi~ted a reduction in the num~er of pushbuttons needed because the same set of pushbutton~ could be utilized to make selections from several alternatively displayable menus.
Many different menus are required to configure lS the operating state of a complex oscilloscope capa-ble of carrying out plural operations, particularly when the oscilloscope may be configured to carry out each operation in several different ways. Since it is normal ly impractical to display ~ore than a few menus at a time, menus are often arranged into a ~menu tree" wherein a ~master~ menu enables an operator to select a "mode" menu from among a set, each mode menu including selections enabling the operatox to conf igure the operating mode of a parti cular oscilloscope operation. Once a particular mode menu is selected, it is displayed, and the operator may make selections from the mode menu to configure a particular aspect of oscilloscope opera-tion. In complex oscilloscopes the operator may be required to traverse several le~els of master menus in order to locate and maKe selections from a parti-cular mode menu, and ~his renders the configuration of the oscilloscope operating state time consuming and difficult to learn.
In the case of such a menu tree, each mode ~9z~

menu includes a fixed set of selectable menu items, but it may also be that when the oscilloscope is in a particular opera~ing state, some or all of the menu items should not be selected because the menu items may control operations incompatible ~ith the current operating state of the oscilloscope. Thus while an operator may cause a particular mode menu to be displayed, the operator may be unaware that selections from the menu may have no effect, or may have an unantici~ated effect, depending on the current operating state of the oscilloscope.
Summary of the Invention According to one aspect of the invention there is provided a method for adjusting the operating state of an instrument of the type having display means for displaying a menu, comprising the steps of: selecting a first menu, comprising at least one menu item, from among a plurality of menus, each menu corresponding to an operating state of said instrument, said first menu being selected by said instrument since it corresponds to a current operating state of said instrument; causing said display means to display said first menu; and adjusting the operating state of said instrument in response to operator selection of a said menu item.
~ ore particularly, menus permitting an operator to adjust and monitor the oper~ting state of an instrument are automatically selected to be added or removed from a display screen in response to changes in the operating state of the instrument. When the operator selects a menu item on a displayed menu, a "configuration command" is generated invoking a procedure which changes values of one or more stored "configuration parameters". The-values of the stored configuration parameters, which control the operating state of the instrument, may also be changed in response to configuration commands generated in response to other input devices, such as, for example, knobs or pushbuttons mounted on the instrument, or in response to signals transmitted to the instrument from external sources. Data indicating combinations of configuration parameter values for which each menu is to be displayed is stored in a memory and when the value of any configuration parameter changes, the menu management system of the present invention consults this data, determines which menus are to be added or removed from the display based on the current configura~ion parameter values, and updates the menu display 1 ZS~2(~80 accordingly. Thus when the operating state o~ the instrument changes, menus appropriate for the new operating state are automatically displayed while menus inappropriate for the instrument operating state are automatically removed from display.
This aspect of the invention minimizes the need for an operator to manually select the appropriate menus to be displayed for a gi~Jen instrument operating state.
According to another aspect oE the invention there is provided an apparatus for adjusting the operating state of an instrument, comprising: display means for displaying a menu selected from among a plurality of menus, each menu corresponding to a different operating state of said instrument; and means for selecting a first menu comprising at least one menu item, from among said plurality of menus, said first menu corresponding to a current operating state of said instrument, for causing said display means to display said first menu, and for adjusting the operating state of said instrument in response to operator selection of a said menu item.
More particularly, the menu management system is adapted to add, remove or modify menu items of a displayed menu in response to changes in the configuration parameters so that only those menu items which are appropriate to a given operating state are displayed. This aspect of the invention enables an operator to easily determine which instrument configuration choices are currently available for the current instrument operating state and prevents display of irrelevant or misleading information on the instrument screen.
It is accordingly an object of the invention to provide an improved system for configuring the operating state of an instrument.
It is another object of the invention to provide an improved system for automatically controlling the display of menus for configuring and indicating the operating state of an instrument.
The subject matter of the present invention is particularly pointed out and distinctly claimed in the concluding portion of this specification. However, both the organization and method of operation of the invention, together with further advan-~9~

tages and objects thereof, will best be understoodby reference to the following description taken in connection with accompanying drawings.

Drawings FIG. 1 is a front elevation view of an oscilloscope utilizing the present invention;
FIG. 2 is a block diagram of hardware associated with the oscilloscope of FIG. l;
FIG. 3 is a data flow diagram showing operation of software systems controlling the vscilloscope of FIGS. 1 and 2;
F7G~ 4 is a data flow diagram showing detailed operation of the human interface subsystem of the software of ~IG. 3; and FIGS. 5-18 illustrate data structure~ main-tained by the human interface subsystem of FIG. 4.

Detailed Description The present invention relates to a me~hod and apparatus for controlling the operating state of computer-based instrumentation systems such as oscilloscopes, logic analyzers and the like.
Referring to FI~. 1, a front elevation view of an example of one such instrumentation system, a microcomputer-based digitizing oscilloscope 10, is depicted. Oscilloscope 10 i~cludes a main chassis 12, a front panel 14 mounted on the chas-Si5, knobs 16, a screen 17 and pushbuttons 18 mounted on the front panel, as well as a set of three ~plugins" 20, 22 and 24. Each plugin com-prise.s a hardwars subsystem of.-the oscilloscope mounted on a small, removable chassis "plugged"
into main chassis 12 through a correspondinq slot in front panel 14. The plugin hardware subsystems, -lZ~2~
interconnected with other hardware within chassis 12 through backplane wiring in chassis 12, may include vertical channel amplifiers, trigger sys-tems and other equipment. Each plugin includes an individual front panel on which additional pushbut-tons, control knobs and jacks may be mounted. The screen 17 is adapted to display waveforms, menus, data and other graphics and text produced by the oscilloscope and includes a well-known "touch screen" 19 mechanism comprising rows of light sources and light sensors distributed around the edge of the screen providing control input signals to the oscilloscope indicating locations on the screen touched by an operator's finger. The touch screen 19 is used primarily to permit an operator to make selections frQm menus displayed on the screen.
FIG. 2 is a block diagram of hardware asso-ciated with the oscilloscope 10 of FIG. 1. Signals produced by devices under test and applied as inpu~
to oscilloscope 10 through jacks on plugins 20, 22 and 24 are preconditioned by the plugins and applied as waveform and triggering inputs to a digitizer 30. The digitizer 30 digitizes selected input signals to produce sequences of waveform data representing the magnitude of successive waveform samples, and transmits these waveform data sequences for storage in a waveform memory 32 by way of a memory arbitrator 34 which arbitrates competing demands for access to the waveform memory 320 Through memory arbitrator 34, a display controller 36 acquires selected waveform data sequences stored in waveform memory 32 and utilizes these sequences to create a bit map of of an oscilloscope display, the bit map being stoxed in a display memory 38.
The display controller 36 periodically acquires bit 7 1.Z~2~8C~
map information from the display memory 33 and transmits it to a display driver 40 which produces a display on the cathode ray tube screen 17 of the oscilloscope 10 according to bit map data.
The memory arbitrator 34 also provides micro-computer 44 with read and write ~ccess to waveform memory 32 by way of a computer bus 45 including control, data and address lines~ Microcomputer 44 suitably comprises an Intel model 80286 micro-proc~sssr and may include an Intel 80287 arithmetic coprocessor for performing fast arithmetic opera-tions and an Intel 82258 direct memory acces~ (DMA~
controller for fast I/O operations. The microcom-puter ~4, operating under control of software (sometimes called "firmware~) stored in a read only memory (ROM) 46, is programmed to carry out a number of unctions including, for example, the control of operating states of plugins 20, 22 and 24, digitizer 30, and display controller 36 as 2~ hereinafter described. The microcomputer 44 pro-vides control input signals to plugins 20, 2~, and 24 through bus 45 as hereinafter described to which the plugins are connected by means of suitable bus input/output II/O) interface circuitry 50. Micro-computer 44 also controls digitizer 30 operating modes through commands sent over bus 45 and stored in waveform memory 32 by way of memory arbitrator 34, ~he stored commands being subsequently read out of memory 32 by digitizer 30. ~icrocomputer 44 determines which stored wavefo.rm data seguences display controller 36 i5 to display by sending commands to memory arbitrator 34 telling it to obtain selected waveform ~equences from memory and to transmit them to the display contr~ller 36.
Microcomputer 44 also controls the display of 8 ~9z~

menus, graphics and data on screen 17 by storing data in waveform memory 32 and commanding arbi-trator 34 to forward that data to the display controller 36.
Input signals, produced by operation of the oscilloscope main front panel knobs 16 and pushbut-tons 18, by operation of knobs, pushbuttons ox switches on the individual front panels of plugins ~0, 22, or 24, and by operation of the touch screen 19, are ~ensed by the I/O circuitry 50 which trans-mits messages to microcomputer 44 in response thereto. In response to the messages, micro-computer 44 configures various subsystems of the oscilloscope for selected modes of operation. The I/O circuitry 50 also provides an interface between bus 45 and two external buses, a general purpose interface bus (GPIB~ 58 and an RS232 bus 60, buses 58 and 60 being accessable through pin connectors at the rear of the oscilloscope chassis. Buses 58 and 60 provide a path for communication between the oscilloscope 10 and external equipment such as a remote computer~ A remote computer may, for example, provide control signals over bus 58 or bus 60 for configuring the oscilloscope 10 for carrying out selected operations and for obtaining through bus 58 or bus 60 test data acquired by oscilloscope 10 in the course of carrying out such operations.
The I/O circuitry 50 converts ASCII messages transmitted on buses 58 or 60 to ASCII messages sent to microcomputer 44 and converts ASCII mes-sages from microcomputer 44 to ASCII messages for transmission over buses 58 or 60. The I/O cir-cuitry 50 also permits external equipment connected to the oscilloscope through buses 58 or 60 to access interrupt and direct memory access control 9 l~ U80 lines 62 of microcomputer 44 so that the external equipment can interrupt microcomputer 44 and/or gain direct memory access to RAM 48.
The microcomputer 44 may be programmed to carry out a number of operations involving computa-tions. For example, the microcomputer may acquire vne or more digital waveform data sequences from waveform memory 32, combine the data sequences according to a user-defined mathematical expression to produce a "synthesizedn waveform data sequence, store the synthesized data sequence in waYe~orm memory 32, and then ~ause display controller 36 to ~isplay a synthesized waveform de~cribed by the stored data sequence. The synthesized waveform might, for example, represent the sum of two digi-tized input waveforms also displayed on the screen, the integral of a digitized input waveform, or any other function of a waveform. The microcomputer 44 can also calculate synthesized waveform data on the basis o~ a user-defined mathematical expression which does not operate on da~a from waveforw memory 32. For example, the microcomputer may calculate waveform data ~epresenting a simple sine wave or square wave and store that dat~ in waveform memory 32 for subsequent use in creating a waveform dis-play. The microcomputer 44 may also be programmed to enable the oscilloscope to perform various "measurements~ on waveform data sequence~ stored in memory 32 such as, for example, determining the peak or RMS values of an input signal represented by the digitized waveform data, the results being di~-played on ~creen 17.
The hardware architecture of ~IG. 2, particu-larly the use of plugins, allows hardware subsys-tems to be added, removed, or modified with little ~2~2~380 or no change to the oscilloscope chassis or otherhardware subsystems of the o~cilloscope. Various software controlled operations of the oscilloscope can be added or changed by replacing ROM 46 with a new ~OM containing different software tfirmware).
The hardware architecture of FIG. 2 permits the response of the~oscilloscope to operation of knobs, pushbuttons and touch screen inputs to be deter-mined by software rather than by hardwired connec-tions and this enables oscilloscope response to asignal from one of these input sources to be changed ~on the fly" so th~t any particular input signal source may control more than one oscilloscope operating parameter. For example, in one operating state the oscilloscope may determine and display data representing the magnitude of a displayed wave-form at a point along the waveform indicated by a cursor an the screen, and one of the knobs 16 of FIG~ 1 may control the position of that cursor. In another o~cilloscope operating state, the same knob 16 may be utilized to set the value of a parameter controlling trigger delay. As another example, the effect of an operator touching a point on touch screen 19 may vary depending on which of several ~enus may be displayed on the screen.
Software in ROM 46 for controlling the operating state configuration and steady state operation of the oscilloscope is organized according to a flexible architecture which accommo-dates changes in hardware and software-based oscil-loscope operations without extensive software modi-fication. Referring to FIG. 3, depicting thi~
software architecture in data flow diagram form, oscilloscope software is organized into an operating system (OS) 70, a control interface 8~
system jCIS) 72, a command execution system (CEX) 74, a steady state system (SSS) 76, and an inter-board communlcation system IIBCS) 78. The control interface ~y~tem 72~ command execution system 74, steady state system 76 and interboard communication system 78 each comprise tasks which run within an operating environment provided by the operating system 70, and the operating system multiplexes the microcomputer through these tasks on a "time slice~
basis so that tasks run in a substantially "concurrent~ fashion. The operating ~ystem 70 also manages allocation of storage space in random access memory 48 of FIG. 2, synchronizes access to common data structures by the ~arious tas~s to provide task-to-task communication, proYides I/O
interfacing, and maintains a set of timers for controlling periodic activities.
The steady state system 76 includes a set of software subsystems running as concurrent tasks within the operating system 70, each subsystem operating in a mode set according to the values of one or more nconfiguration parameters~ 77 stored in RAM 48 of FIG. 2. A waveform display subsystem 80 controls the transfer of waveform data from the waveform memory 32 to the display controller 36 of FIG. 2. ~he digitizer 30 of FIG. 2 includes an internal computer which may be programmed to stop digitizing a particular input waveform and to transmit an ~acguisition stopped~ message to micro-computer 44 when predetermined conditions (such asfor example receipt of a given number of triggers~
have been fulfilledO An acquisition control subsystem 82 of the steady state system 76 of FIG.

3 responds to the "acquisition stopped~ message by executing a routine which may be configured to 12 129Z(~80 cause the newly acquired waveform data to be dis-played on the scr~en, A waveform calculation ~ub-system 84 calculates the previously mentioned ~yn-the~ized waveform data according to user-defined expressions, and a measurement subsystem 86 deter-mines attributes of selected input waveforms (such as peak values, rise times, etc.) from the digitized input waveform data stored in the waveform memory. A
display list subsystem 88 controls the display of ~he results o measurements performed by the measurement subsystem 86, and controls the positioning of graphi-cal elements such as cursors and icons on the screen A self-calibration subsystem 90 periodically ini-.
tiates commands to the oscilloscope digitizer and plugins which cause them to self-calibrate.
All of the above-described subsystems of the steady ~tate system 76 are tasks whic~ run con-tinuously during normal ~steady state" oscilloscope operation, and most of tbese tasks ~an be "con-figured" to perform their functions in a variety ofways by setting the values of various oscilloscope operating state configuration parameters 77. For example the waveform calculation subsystem 84 can be configured to simultaneously calculate from 1 to 8 waveform data seguences, and the expression controlling calculation of each sequence may be changed by a user. Once a subsystem of s~eady state system 76 is confi~ured to operate in a particular manner, the subsystem continues to operate in such manner until lt i5 reconfigured by changing the values of appropriate configuration parameters 77.
The digitizer, display ~ontroller and plugin hardware ~ubsystems each may be also be configured according to various configuration parameters 77 to operate in a particular "steady state~ mode of ` 13 1~2~

operation and will continue to operate in such mode until the configuration parameters controlling sub-system operation are changed. For example the diqi-tizer may be configured to digitize a particular set S of input waveforms utilizing triggering events, sampling rates and other controllable operating conditions determined by input configuration data, and will continue to do so until the digitiæer is supplied with new configuration control data which changes some aspect of its operation.
The interboard communication system 7~ com-prises drivers for providing for communication between the microcomputer 44 and various hardware subsystems of the oscilloscope, including a set of drivers 85 for handling communication with the plugins, a driver 87 for handling communication with the digitizer, and a driver 89 for handling communication with the display controller. The drivers are utilized to transmit configuration control commands to the hardware subsystem when values of configuration parameters 77 affeeting operation of these subsystems ~hange. The drivers are also utilized ts transmit data between hardware and software subsystems. Data, including waveform data sequences, calculation results, messages and the like, is passed between the hardware and soft-ware subsystems by storing the data in data files 79 in ~AM 48 accessed ~y the drivers in the inter-board communication system ~8 and software subsystems.
The operating state o~ each software subsystem of steady s~ate system 76, as well as the operating state of each hardware plugin, digitizer and dis-play controller ~ubsystem, may be configured by an operator utilizing the touch screen, knobs or pushbutton~ on the oscilloscope main front panel, 14 ~2~Z~

or by a remote control system such as an external co~puter utilizing data transmitted over the GPIB or R5232 buses. As discussed hereinabove, the I~O cir-cuitry 50 of FIG. 2 transmits messages to the micro-computer 44 in response to control signals ormessages from these sources. The control interface system 72 of FIG. 3 provides a set of interface subsystems operating as task~ within operating system 70, and each subsystem is adapted to respond to messages produced by the 1/0 circuitry S0 by generating a predetermined "configura~ion command~.
Each configuration command invokes a procedure for changing the value of one or more configuration para-meters 77 so as to reconfigure one or more subsystems of the steady state system 76 and/or one or more o~
the oscilloscope hardware subsystems for selected modes of operation. Each command also conveys a block of "confi~uration data" utilized by the invoked procedure when setting the values of the configura-tion parameters 77. Features of oscilloscope 10 arealso set forth and clai~ed in our application (4022).
A human interface management subsystem 92 of control interface system 72 manages the display of menus on the oscilloscope screen and also produces configuration commands in response to messages from interface circuitry 50 indicating touch screen 19 menu selections or indicating operation of oscillo-scope fr~nt panel pushbuttons 18 of FIG. 1. A knob interface subsystem 94 produces configurati~n commands in response to messages from the I/O eir-cuitry indicating the direction and amount of rota-tion of ei~her one of the two front panel knohs 16 of FIG. lo A set of three plugin interface subsys-tems 96, ga and 100 produces configuration commands in response to I/O interface circuitry messages ~2~Z¢~

indicating operation of knobs or pushbuttons on the plugins 20, 22 and 24 of FIG. i, and an ASCII"
interface subsystem 102 produces configuration commands in response to messages from the I/O inter-face circuitry based on messages carried over the GPIB and RS232 buses. Operating system 70 stores the configurati~n commands produced by interface subsystems 92, 94, 9~, 98, 100, and 102 of control interface system 72 in RAM 48 of FIG. 2 in the form of data queues 104-109, respectiYely, and each command remains stored in a queue until executed.
. Each configuration command comprises a block o da~a structured in a similar fashion, including the data fields as shown in Table I b~low:
Field- Field- Parameter-Na~e Length Type Function errorMb 16 bits boolean return error doneSem 16 bit boolean return done semaphore cmdId 16 bit integer command identifier key 16 bit integer trace number enumArg 16 bit boolean any purpose si . .16 bit signed int. any purpose ui(3) 3x16 bit 3 integers any purpose nrx 64 bit flt. pt. . any purpose slot 16 bit integer slot identifier data 32 bit pointer pointer to stored data len 16 bit integer length of stored data Table I

Although each command includes each of the data ields listed in Table I, a procedure invoked by any particular command may not utilize data contained in every field. The errorMb and doneSem fields contain 16 1 2 9 ~ ~ ~ 0 data indicating whether the control interface ~ub-system producing he command wants the command exe-cution system 74 to return "error informati~n~ or a Udone semaphore" (as described hereinbelow) in the course of executing a command. Data in the cmdId field identifies the procedure to be invoked by the command. The key field i~ u~ed to identify a parti-cular waveform data base element (e.g. waveform trace) in commands affecting wa~eform displays, sucA
as for example a command to cease displaying a waveform. The enumArg, si, ui, and nrx fields con-vey various types of parameters (bool~ans, signed and un~igned integers and floating point numbers) which may describe some particular feature of sub-system configuration depending on the nature of theprocedure being invoked. For example, in a oo~mand to change the background intensity of the display in response to knob rotation, the intensity may be increased or decreased according to the ~alue of data in the si field, and most of the other fields may be unused.
The slot field listed in Table I contains an integer whose value identifies a particular plugin, and this field is used in command~ which affect plugins. The data field is a pointer to an initial location in RAM 48 of FIG~ 2 where a block of data is stored and the len field indicates the num~er of memory addresses the block of data consume~. The - data and len fields are used in commands invoking procedures requiring large blocks of input data.
For example, when the hu~n interface management subsy~tem 92 produce~ a command which invokes a procedure for configuring the waveform ralculation sub~ystem 84 so a~ to calculate a waveform accor-ding to a particular expression, infor~ation defi-17 ~ Q ~ o ning the expression is not conveyed in the commandbut i5 rather stored in RAM 48, and the dat~ and len fields conveyed in the command identify the storage location of the expression information.
S The invoked procedure acquires this information from memory in the course of executing the command.
The command execution system 74, operating as an additional tas~ within the operating system 70 environment, executes procedures identified by configuration oommands stored in queues 104-109, such procedures being executed one at a time according to a predetermined arbitration scheme~
Each comma~d is executed by calling a subroutine identified by the command, the subroutine modifying configuration parameters 77 controlling operation of one or more subsystems of steady state and/or hardware subsystems. The command execution system 74 includes a set of command execution modules (subroutines~ 112, one for carrying out each type of configuration command, and an arbitrator routine 110 for checking each queue 104-10~ according to a predetermined priority system and invokinq operation of the appropriate command execution module whenever a command is encountered in one of the queues. If no command is encountered after checking all of the queues, arbitrator operation is suspended until a semaphore 114, a flag maintained by the operating system, is set. Each one of the control interface system 72 subsystems sets semaphore 114 whenever it produces a configuration command for storage in a queue, and when ~he semaphore is set while arbitrator operation is suspended, operating system 70 ~awakens~ the arbi-trator 110, which rechecks all of the queues for commands, invokes command execution modules 112 as 18 ~ ~9~8~

necessary to execute all commands encountered in the queues, and then resets the semaphore 114.
When a command execution module 112 is inYoked by arbitrator 110, it may reconfigure one or more selected hardware subsystems by changing configura-tion control parameters 77 and invoking operation of the appropriate driver 85, 87 and B9 in the interboard communication system 78 as necessary to convey configuration data to the hardware subsys-tems. A command execution module 112 may al50 reconfigure one or more of the subsystems of steady state system 76 simply by changing values of appro-priate configuration parameters 77. The configura-tion parameters are monitored by the steady state subsys~ems, each of which operates continuously during normal oscilloscope operation, and changes in certain configuration parameters automatically result in a change in operation modes of one or more steady s~ate ~ubsystems.
Various command execution modules 112 may be adapted to detect and report errors encountered in the course of attempting to reconfigure oscillo-scope hardware or software subsystems~ such as for instance errors arising out of inappropriate data in configuration command data fields, or out of failure to carry out reconfiguration due to some conflicting prior state of the oscilloscope. When an error is detected, a command execution module may return an error indication to the arbitrator llO, and the arbitrator will store a ~Display Mes-sage ~enu~ command in either of a pair of "mail-boxes" 116, se~tions of RAM 4B reserved for trans-mitting information to human interface management subsyst2m 92 and to the ASCII interface subsystem 102. This message causes the human interface lg ~LZ~Z~

managem~nt subsystem to display an error message on the screen or causes the ASCIl interface subsystem to transmit an error message over the RS232 of GPIB
buses .
When the command execution module 112 has co~pleted its operation, the arbitrator 110 ch~cks the state of a ~,done~ semaphore in the mailbox 116 of the human interface subsystem 92, and if the flag i5 not set, it will set the flag and place an NUpdate" command in the mailbox 116. According to the present invention, when the human interface management subsystem 92 detects an Update command, it updates the menu display to account for any changes required by the change in system operating state. Thereafter the human interface management subsystem 92 removes the Update command from its mailbox, and resets the done flag. Thus a new Update command i~ placed in its mailbox 116 only when no Update command i5 already stored therein.
While human interface management subsystem 92 can change the operating state of various steady state and hardware subsystems of the oscilloscope by transmitting configuration commands to the com-mand execution system 74, which in turn adjusts the values of configuration parameters 77, the subsys-tem controls display of menus on the oscilloscope screen by storing menu display control data 79 in RAM and invoking display communication driver 89 to cause that data to be sent to the display con-troller. The display communication driver 89 ini-tiall~ transmits menu display control data to the waveform memory 32 of FIG. 2 for storage therein, and subsequently causes the memory arbitrator 34 to transfer the data to display controller 34. Dis-play controller 34 utilizes this data to create bit 20 ~Z~Z(~!80 maps of menus superimposed over the waveform bit map in display memory 38. Thereafter, when the display controller updates the display on screen 17, the appropriate menus are displayed.
According to the present invention, the human interface management (HIM) subsystem 92 may automa-tically change the menu display when the operating state of the oscilloscope changes. When the HIM
subsystem 92 detects an Update command in its mail-box 116, it checks values of various configuration parameters 77 to see if they have been altered, thereby indicating that the state of the oscillo-scope has changed. If so, the HIM subsystem 92 may change the menu display so that menus appropriate to the new oscilloscope operating state are dis-played while inappropriate menus are removed from the display. This reduces the need for an operator to tell the oscilloscope IbY means of menu selec-tions, pushbuttons and the like) which menus are to be displayed when the operating state of the oscilloscope changes. The human interface manage-ment system 92 is adapted not only to automatically determine the menus that are to be displayed when the oscilloscope operating state changes, but it is also adapted according to the present invention to change individual menus so as to add menu items which are appropriate, and remove menu items which are inappropriate to the new oscilloscope operating state, and to change individual menu items to indicate aspects of the new operating state.
In the preferred em~odiment of the invention, the human interace management subsystem 92 pro-vides six types o menus. ~ "permanent selec~ion menu~ is not actually displayed on the screen, rather it is formed by the pushbuttons 18 on the Z~80 fr~nt panel of the oscilloscope 10 as shown in FI~. 1. One pushbutton controls whether ~IM ~ub-system 92 responds to touch screen input. Each of five other pushbuttons 18 cause the HIM subsystem 92 to display a particular menu on screen 17, the name of the menu being printed on the oscillscope front panel 14 next to the pushbutton which controls it. The remaining pushbuttons 18 on the oscilloscope front panel cause ~he human interface management subsy~tem 92 to generate configuration commands which configure the oscilloscope to carry out specific operations, su~h as for example startin~ or 3topping the digitizer, ~hanging digi-tizer accuracy, transmitting bit-map data over the RS232 bus ~o that external equipment can create a hardcopy picture of the display, etc.
"Status ~enus" show various o~cilloscope operating parameter values. Only one status menu 21 may be displayed at any time, and it is dis-played in the lower left corner of screen 17. A~knob menu" 23 is displayed in the lower right hand corner of screen 17. The knob menu shows the value of parameters currently controlled by knobs 16.
Whenever one of the knobs 16 i~ rotated, knob interface ~ubsystem 94 of ~IG. 3 generates a con-figuration command which causes a change tG the value of the parameter currently controlled by knob according to the amoun~ of knob rotation. ~hen human interface management subsystem 92 detects an Update command ~n its mailbox, it checks the cQn-figuration parameters, and on finding a change to the parameter controiled by the knob, it updates the knob menu accordingly.
~he o~cillos~ope ~ay operate in either dual or single axis modes. When the oscillo~cope is in the 22 12~Z~

single axis mode, an ~axis menu" 25 is displayed along the left and upper edges of the ~waveform area~ 27 of the screen 17 above the status and ~nob menus. When the oscillsocope is in the dual axis S mvde, the axis menu is displayed along the left and upper edges of both upper and lower halves of the wav~form display area. The axis menus are used to reas~ign the knob function for control of vertical and horizontal waveform po~itioning, to display positions of cursor~ and f~r other purposes relating to the waveform di~play~
A "popup menu~ 29 may be superimposed over the waveform dlsplay area 27 to permit an operator to change various operating parameters of the oscillo-seope, utilizing the touch screen to make menuselections, or to indicate values of variou~
oscilloscop~ operating parameters. For example, a popup menu may be used to rea~sign the function of knobs 16, to select expressions for synthesizing wave~orms, to select which stored waveforms are to be displayed, etc. A popup menu may be displayed in response to a selection made from anothPr menu, in response to operation of a pushbutton, or in response to any other action which changes the oscilloscope state. ~nly one popup ~enu is displayed at a time and the operator can remove a popup menu by touching any area of the screen not covered by the popup n~nu.
A "message menu~ 31 m~y be displayed in the upper two lines of ~he d~play, superimposed over the axis menu and waveform display. This menu is utilized to display me~sages conveyed in the previously mentioned Display Message ~enu ~ommand~
generated by the command exeoution system ?4 or b 35 the operating system 70 of FIG, 3. The operator 23 12~2~30 may remove a message menu from the display by ~ouchiny any part of the screen. If a new Display Message Menu command is received while the me,ssage menu is displayed, human interface management S subsystem 92 automatically replaces the displayed message with a message indicated by the new command.
Referring to FIG. 4, a data flow diagram depicting detailed operation and architecture of human interface management subsystem 92 of FIG. 3, subsystem HIM 92 accesses vario~ types of data files stored in ROM 46 and RAM 48 of PIG. 2, including the configuration parameters 77, "string files" 120, a ~current menu list" 126, ~formatted menus" 124, a Uselection map" 128, and a set of "template menus~ 122. The string files 120 store data utilized by command execution modules 112 of FIG. 3 in the course of executing a command generated by human interface management subsystem 92 when the data cannot be conveyed in the standard command data fields shown in table I. In such case, HIM subsystem 92 stores the data in a string file 120 and the command conveys information in the ~data" and ~len" fields of table I indicating the location of the string ~ile in RA~ 48. The command execution module 112 responding to the command thereafter obtains the data from the string file.
A string file 120 is used, for example, to convey information regarding user-defined expressions for guidin~- the operation of the waveform calculation subsystem 84 of F~. 3.
Characteristics of each menu which may be displayed on the screen are described by a corres-ponding "template menun 122, one template menu 122 being stored in ROM 46 for each displayable menu.

24 l~Z~8~
Each template menu includes instructions for deter-mining when the menu is to be displayed, what items may be included in the corresponding menu, what each menu item is to look like when displayed, where on the screen the menu is to be displayed, what operations are carried out when a menu item is selected, and other aspects of the menu as described in more detail hereinbelow. Each tem-plate menu 122 describes a range of characteristics a particular menu might have when actively dis-played depending on the operating state of the oscilloscope. In order to initially establish the actual characteristics of a menu to be displayed during a given current operating state of the oscilloscope, HIM subsystem 92 reads the data contained in the corresponding template menu 122, determines from this data what configuration parameter 77 values identify oscilloscope operating states relevant to the menu, reads these parameter values, and then creates a corresponding "formatted menu" 124 data file in RAM.
Each formatted menu includes much of the information in its corresponding template menu and also includes data reflecting relevant aspects of the current state of the oscilloscope so as to enable HIM subsystem 92 to determine whether the menu is currently to be displayed, exactly how the menu should be displayed, how the HIM subsystem 92 is to respond to menu selections, etc. When HIM
subsystem 92 determines that an undisplayed menu is to be displayed, it creates or updates the corres-ponding formatted menu as necessary to reflect the current operating state of the oscilloscope, obtains menu display control data from the for-35 matted menu file~ and passes it to the display 1Z~ZC)8() communication driver subroutine 89 of FIG. 3 ThPdisplay communication driver then transmits the display control data to the display controller 36 of FIG. 2 via waveform memory 32 and memory arbi-trator 34 as previously described. The display controller 36 updates the menu display.
Menus are initially formatted the first time they are to be displayed. Menus which do not change siæe (i.e., the number of menu items) in response to changes in oscilloscope operating state are treated as "static" menus, while menus which do change size are treated as "dynamic" menus. Most menus are "static", meaning that when the menu is removed from the display, the formatted menu is not discarded but is kept in RAM and modified as necessary whenever configuration parameter values affecting the menu change, even though the menu is not currently displayed. Thus whenever a previously formatted static menu is redisplayed, it is not necessary to reformat the menu from its template menu, although it may be necessary to update the formatted menu to reflect changes in oscilloscope operating state. On the other hand, when a "dynamic" menu is removed from display~ its formatted menu is discarded and HIM 92 must recreate the ~or~atted menu from the template menu whenever the dynamic menu is subsequently redisplayed. A new formatted menu must also be created whenever a change in oscilloscope operating state affects a currently displayed dynamic menu.
The current menu list 126 is a list of pointers to ROM storage locations of template menus 122 corresponding to currently formatted menus 124, and the selection map 128 is a data structure HIM
subsystem 92 uses to determine its response to 26 ~Z~20~3~

touch sc~een input. HIM subsystem 9~ updates current menu li~t 126 whenever a menu is for~atted and whenever a menu is added to or removed from the di~play. The selection map 128 divides the touch screen into a set of ~touchable" areas, and includes for each touchable area, as well as for each pushbutton~on the oscilloscope front panel, a pointer to a set of instructions in a particular formatted menu 124. It is t~ese instructions which tell HIM subsystem 92 what to do wh~n a particular area of the screen is touched. Whenever the menu display is changed by adding, removing or modifying a menu, ~IH subsystem 92 response to a screen touch ~t one or more locations on the touch screen may change. Thus when the menu display is changed, pointers in selection map 128 are usually changed.
Th~ human interface management subsystem 92 of FIG. 4 respond~ to six types of commands which may be placed in its mailbox 116, includiny Update, Touch Response, Display Message Menu, Remove Message Menu and Remove Popup Menu commands. Each message is of the format shown in Table II below.

Field Name Field Length Parameter Type ComplSem 16 bits semaphore Cmd 16 bits integer Origin 16 bits integer X 16 bits integer Y 16 bits integer Key 16 bits integer ErrorArray 110x16 bits characters Table I I

27 ~2~Z~)~O

In all messages, data in the Cmd field identifies the mes~age type and data in the ComplSem field identifies a semaphore, if any, that ~IM ~ubsy~tem 92 should ~ignal when message proce~sing S complete.
A ~menu actions~ routine 132 of human inter-face management subsystem 92 re~ponds to Touch ~esponse commands. The I/O circuitry 50 of FIG. 2 sends a Touch Re~ponse cvmmand whenever the touch screen or a front panel pushbutton is operated.
The X and Y fields of the command identify th~
touch screen area or pushbutton that was operated.
The I/O circuitry 50 can also send a Touch Rssponse command in response to a me~sage transmitted over the GPIB or RS232 bu~es to allow an external control sy~tem ~uch as a computer to simulate touch screen or push button operation. The Origin field indicate~ whether the command came from the remote sourc~. The Key and ~rrorArray fields are not used by the Touch Response command.
In response to a Touch Response co~and, the menu actions routine 132 determines from pointers in selection map 128 the storage location o~ an appro-priate "Action" data field in a formatted menu 124 providing instructions for an action to be taken. If HIM sub~ystem 92 is to display a menu in response to a Touch Response command, the menu actions routine 132 calls a menu activate routine 134 which checks the current menu list 126 to determine whether the me~u to be displayed is currently formatted. If the menu i~ not currently formatted, menu activate rou-tine 134 calls a menu format subrou~ine 136 which copies selected information from the template menu 122 intc a new formatted menu 124 file. There-after, the menu activate routine 134 reads data in lZ~ZO~O
the formatted menu file to determine which configu-ration parameters 77 are relevant to the menu, reads those configuration parameters, and then adjusts data in the formatted menu 124 according the current values of the configuration parameters.
Next, the menu activate routine 13~ generates menu display control data based on information in the formatted menu 124 and passes it to the display communication driver ag of FIG. 3. The driver causes the display controller 36 of FIGo 2 to create the new menu display according to the dis-play control data. The menu activate routine 134 also changes the current menu list 126 to add a pointer to the template menu corresponding to the newly ~ormatted and displayed menu and changes pointers in the selection map 128 to point to appropriate action instructions in the new for-matted menu 124.
The menu actions routine 132 may remove a menu from display in response to a Touch Response com-mand. In such case the menu actions routine 132 c~lls a menu deactivate routi~e 138 which chacks the current menu list 126 to locate the template menu 122 for the menu to be removed from display, checks the template menu for a pointer to the corresponding formatted menu 124r generates display control data based on information in the formatted - menu, and passes the data to the display communica-tion driver. The display communication driver thereafter passes this data to the display con-trol ler causing it to remove ~he menu from the display. The menu deactivata routine 138 modifie~
the selection map 128 to account for removal of the menu display. In the case of a static menu, the menu deactivate routine 138 also modifies the cur-29 ~Z92~30 rent menu list 126 to indicate that the menu is nolonger active. In the case of a dynamic ~enu, the menu deactivate routine "destroys" the formatted menu 124 by deleting references to the formatted 5 menu from the current menu list 126.
Instruction~ referenced by the selection map 128 may tell the menu actions routine 132 to gene-rate a configuratlon command so a~ to reconfigure the oscilloscope operating state. In response to such an instruction from the selection map, the menu action~ routine 132 calls an appropriate com-mand generator subroutine 140 stored at a ROM loca-tion indicated by a pointer in a formatted menu 12~, and the sub}outine 140 generates one or more commands, utilizing a s~ring file 1~0 when neces-sary to pass large blocks of data to the command execution system.
The arbitrator 110 of PI~;. 3 places an Update command (utilizing only the ComplSem and Cmd 20 fields) in mail box 116 when a command execution module 112 completes a respon~e to a configura ion command, if no ~pdate command is pending in the mailbox. HIM subsystem 92 may add a menu to the display, may remove a menu from the display, or may modify a displayed menu in response to the Update command. A ~menu update~ routine 130 of ~IM ~2 responds to the ~pdate commands by checking all of the template ~enus 122 to determine which paramet~rs 77 may affect the menu display. It then reads the appropriate parameter~ to determine what menus should be displayed ba~ed on the values of the parameters and checks the current menu list 126 to determine what menus are currently formatted and what menus are currently displayed. If the menu update r~utine 130 determines that a currently ~z080 displayed menu should no longer be displayed, it calls the menu deactivate routine 138 to remo~e the menu from the display in a mannQr previously described. If the menu update routine 130 determines that a menu which has not yet be~n formatted is to be added to ~he display, it calls the menu activa~e routine 134 which formats and activate~ (displays) the menu in a manner previou31y described.
The menu update routine 130 also inspects the contents of each formatted menu 124 to determine if the new configuration parameter 77 values would cause any chanqe to the formatted menu, andO in the case of a static menu, changes the formatted menu accordingly. If the static menu is currently dis-played, the menu update routine 130 generates dis-play control data based on the information in the formatted menu 124 and passes it to the display communication dri~er so as to update the di3play.
For a curren~ly displayed dynamic menu, when the menu update routine 130 determines from data in the formatted menu that the new confi~uration parameter values require a change to the formatted menu, the menu update routine calls the menu deactivate routine 138 to remove the existing displayed menu and then calls menu activate routine 134 to create a new formatted menu and to redisplay the menu based on data in the new formatted menu.
A Display Message Menu may be stored in the HIM subsystem 92 mailbox by the çommand execution sy~tem 74 or by the operating ~ystem 70 of FIG. 3 ~nd i5 utilized to initiate display of a message menu. In this command the ErrorArray ield çontains the ASCII text o the message to be displayed and ends with a NULL character. The ~Z9;~080 Display Message Menu command does not us~ the Origin, X, Y or Key fields. ~he menu update routine 130 responds to a Display Message Menu command by calling the menu deactivate routine 138 to remove any currently displayed message menu and then calling the menu activate routine to format and display a new message menu containing the-message conveyed in the cvmmand.
A Remove Message Menu command, using only the CmplSem and Cmd fields, may be stored in the HIM
mailbox to cause menu update routine 130 to call the menu deactivate routine 13B to remove a message menu. A Remove Popup Menu command placed in the HI~
subsystem mailbox, also utiliizing only the ComplSem and Cmd fields, causes the HIM subsystem 92 to remove a popup menu from the display by calling the menu deactivate routine 138.
FIGS. 5-18 show details of the various data structures accessed by HIM subsystem 92 of FIGr 4 in the course of responding to the above described commands. In FIGS 5-18 each data structure is depicted as a list including data field names in a left hand column and corresponding data field types in a right hand column. With respect to data types, "Short" indicates a 16 bit in~eger, "Bool"
indicates a boolean, "Fn Ptr" indicates a pointer to a RAM or ROM storage location of a set of instructions, ~PTR" indicates a pointer to a RAM
storage location o~ a data structure, ~Union"
indi~ates a data subs~ructure contain~ng variable data fields depending on men~ type, and "Structn indicates a data substructure which does not vary with menu type.
Each template menu 122 and each formatted menu 124 includes a "header" data structure and a set of 32 ~2~Z~

~entity" data structures, and FIGS. 5 and 6 show the header structures for the template and format-ted menus, respectively. The template menu header of FIG. 5 comprises a HIMMnuTmplStr ~tructure including a MnuType field indicating the menu type (permanent, status, knob, axis, popup or me~sage~
and a LckFlg field indicating whether the menu may be selected by operation of a front panel pushbut-ton even if the front panel i~ "locked~. (A confi-guration command produced by the ASCII interface subsystem 102 of FIG. 3 may cause a command execu-tion module 112 to set a configuration parameter 77 which t~lls the menu update routine 130 of PIG. ~
to deactivate various ~menu~" associated with the ront panel pushbuttons and touch screen, and the LckFlg field of each menu indicates whether menu display is to be inhibited by such a command.) A
DynFlg field indicates whether the menu is dynamic or static and a DispFn field points to a RAM loca-tion containing a boolean indicating whether the menu is currently displayed. An EntryFn field contains a pointer to a ROM storage location con-taining instructions for actions to be performed when a menu is first displayed (such as, for exam-ple, initiating a configuration command to reassign a knob function), and an ExitFN contains a pointer to a ROM storage location containing instructions for an action to be performed when a menu is removed from the display. A Formatted field con-~cain~ a pointer to a RAM storage location ~ontain-ing another pointer ~o the RAM ~torage location of the corresponding formatted menu header. This "double pointer" is used because the template menu, being in ROM, cannot contain a varying datum.
When the menu is formatted, the menu format , routine copies the MnuTyp, DispFn, EntryFn, and ExitFn template menu fields into the formatted menu header structure HIMMnuFmtStr, shown in FIG. 6~ and the menu activate routine adds several other fields. ~nuLft and MnuTop fields identify the location on the screen where the upper left hand corner of the menu is to be displayed. An InstanceNext field indlcates a~ "instance number"
u~ed by HIM subsystem 92 to identify the first ~menu entity" of the collection of menu entlties associated with the ~enu. ("Menu entities" are described in detail hereinbelow.) If the menu is a status menu, a MnuUniq field contains information indicating what functions knobs 16 of FIG. 1 would contrsl if the status menu were to be displayed~
If the menu is a popup menu, the MnuUniq field contains data indicating the area of the screen to be covered by the menu when displayed. An EntChn field is a pointer to the RAM storage location first formatted entity of the entities included in the formatted menu Several types of "menu entity" data structures may be included in a template or formatted menu. A
selector entity includes data defining a touchable area on the screen where a "selector" (i.e. a menu item) may be displayed, data indicating what text or graphical ~ymbol representing the selector is to be displayed, data indicating the circumstances under which the selector is to be included in a displayed menu, and pointers to memory locations containing instructions for carrying out ac~ions in response to touch screen or pushbutton operation.
One selector entity is included in the template menu for each menu selector and a corresponding selector entity is included in the formatted menu.

34 ~ ~ ~ Z ~ ~

FIG. 7 shows the structure of a selector entity in the template menu and FIG. 8 shows the structure of a selector entity in the formatted menu.
With reference to the template menu selector entity (HIMSelTmplStr) of FIG 7, an EntType field contains data indicating that the entity is a sele-ctor entity. A StevesArg field contains an integer constant passed to boolean functions called by HIM
subsystem 92 to determine whether the selector is to be displayed, highlighted, or selectable, to deter~ine what text or icon is to be displayed in the field, and to determine what actions are tg be taken in response to selection. A DispFn field includes a pointer to the boolean function which determines whether or not the selector associated with the entity is currently displayed based on current values of configuration parameter data and on data included in the StevesArg field. A
PlaceHold field contains data lndicating whe~her or not the selector's position in a displayed menu is to be held (i.e. left blank) when the selector is not displayed, or whether the menu display is to be reformed such that no gap is to be shown between selectors that are displayed. ~The latter choice is a~propriate only for dynamic menus which are reformatted before each display update.) In some oscilloscope operating states it may be desirable to display a selector but to prevent thç HIM subsystem 92 from responding to it~ selec-tion. ~ SlctFn field contains ~ pointer to aboolean function which determines whether or not the selector is currently ~selectable" ~i.e.
whether HIM subsystem 92 will respond to its selection) based on the Yalue of StevesArg and current configuration parameter data. When a ~ O ~ ~

selector is selectable it may be highlighted, and a HilitFn field contains a pointer to a boolean function indicating whether the selector should be highlighted based on the values of StevesArg and configuration parameters. ColorExcep, FColorIndex, and BColorIndex fields control selector color while Width and Height~fields control selector size.
PlaceCode, PlaceX and PlaceY fields contain data indicating how the selector is to be positioned on the screen, whether at an absolutP screen position, at an absolute position within the menu, at a position relative to some other selector, etc. An Overlayed field indicates whether the selector shares its screen location with another entity of the menu on a mutually exclusive basis. HIM
subsystem 92 uses the Overlayed information in determining whether to update the menu display upon changed system status.
OutFldFn is a pointer to an "output field"
function which determines from StevesArg and current configuration parameter values whether an output field (data) is to be displayed with$n the selector, and OutFldChr is a parameter indicating where in the selector the data is to be displayed.
Whenever HIM subsystem g2 activates a menu for which an output field function is specified, HIM
subsystem 92 executes the outpu~ field function.
The output field function causes ~IM subsystem 92 to send a message to the steady state system - 30 causing the steady state system 76 to initiate display of the value of a particular datum speci-fied in the message, such as, for example, the value of waveform measurement data produced by the measurement subsystem 86 of the steady state system 76 of FIG. 3. The datum value is displayed within lZ~ 8~
3~

a particular selector at a screen position ind~-cated by the message. Th~reafter, the steady state system automatically updates t~e d~tum value di~-play within the selector whenever the datum value changes, without requiring further action on the part of HIM ~ubsystem 92. When the HIM subsystem 92 ~ubsequently removes the menu from the di~play, it sends another message to the steady st~t~
system, telling it to stop updating the datum ~aluç
display. A TxtIcon fiel~ contains data indicating whether ~ext or graphics to be displayed in ~he selector, and a SelUniq field contains pointers o data which enable~ the HIM subsystem 92 to deter-~ine the nature of such text or graphics.
An Actions substructure (HIMActPtrStr~ of HIMSelTemplStr ~ontains data indicating menu and non-me~u actions to be performed when the ~elector i8 selected. Menu actions may include displaying a message or popup menu ~r removing a popup menu.
Non-menu actions include, for example, generating a particular configura~ion command. The Actions structure HIMActPtrStr includes a NewMsg pointer to a template me~sage menu, a NewPopup pointer to a template popup menu, a DelPopup boolean indicating whether a currently dlspl~yed popup menu is to be removed from the display, a NonMnuAct pointer to a command generator subroutine, and a NonMnuArg pointer to data which may be required by the command genera or subroutine.
With reference to the formatted ~enu ~elector en~ity data structure ~HI~SecFmtStr) shown in FI~.
8, the EntTyp, PlaceHold, Wldth, Height, DispFn, SlctFn, HilitFn, ColorExcep, FColorIndex, BColorIndex, OutFldFn, Actions, StevesArgD TxtIcon Overlayed and SelUniq fields are copied fro~ the 37 ~Z9Z~

corresponding template menu. DispRslt, SlctRslt and HilitRslt fields contain booleans indicating whether the selector is to be displayed, selec table, or highlighted according to the results of functions (indicated by the DispFn, SlctFn and HilitFn fields, respectively) called by the menu activate routine,when the menu is formatted. These fields enable the menu update routine 130 to deter-mine whether the display status of the menu has changed. The OutFldX and OutFldY fields contain data indicating the absolute screen coordinates of an output field, if any~ to be displayed, and the OutFldNo field contains data comprising a unique identifier for the output field to be displayed at the screen position indicated by the OutFldX and OutFldY screen coordinates. The OutFldX, OutFldY
and OutFldNo data fields are passed to the steady state system when the menu is first displayed, as previously discussed so that the steady state system knows where to initate display of output field datum. The OutFldNo is also pas~ed to the steady state system when the menu is subsequently removed from the display in order that the steady state system knows which output field to stop updating. InstanceBase and InstanceMax are refe-rence nu~bers used by HIM subsystem 92 to identify the selector associated with the menu entity.
LocateX and LocateY contain the absolute screen coordinates of the upper left cornPr of the selec-tor determined from the PlaceX and PlaceY fields ofthe template menu. Data in a BlankState field indicates which lines of the selector are blank and enables the ~elector to be redrawn more efficiently by not redrawing blank lines. Finally, a NxtEnt pointer indicates the storage location in RAM of 38 ~ Z ~ O

the next entity of the menu. NextEnt pointers connect all the entities of a particular formatted menu into a linked list traversed by HIM subsystem 92 when obtaining data. (NextEnt pointers are not used in the template menus because the entities of each individual template menu are stored consesu-tively in ROM and no NxtEnt pointers are necessary.) Another type of menu entity is a list entity which produces a rectangular array of selec-torsl one selector for each item on a list ofvariable length, such as, for example, a list of currently displayed waveforms. Referring to FIG.
9, showing the template menu list entity structure ~HIMLstTmplStr~, the list entity includes EntTyp, PlaceHold, DispFn, SlctFn, HilitFn, Overlayed, StevesArg, and Actions fields which have substan-tially the same functions as similarly named fields in the selector entity. EnvLft and EnvTop fields contain absolute screen coordinatçs of the list of selectors to be displayed. MaxEnvWidth and MaxEnvHight fields indicate the maximum width and height the ~elector list may attain, and SelWidth and SelHeight fields indicate the width and height of each selector (all selectors are the same size).
LstLen is a pointer to a RAM location containing data indicating the number of items on the list (i.e. the number of selectorsj, and TxtFn is a - pointer to the storaqe location of a function which determines from StevesArg the text that is to be displayed in each selector for each possible oscil-loscope state as indicated by configuration para-meter values.
The structure of a formatted list entity ~HIMLstFmtStr) is shown in FIG~ l0 and includes the EntTyp, PlacPHold, EnvLft, EnvTopr DispFn, SlctFn, lZ9Z~8~

HighlitFn, Overlayed, SelWidth, Sel~eight, LstLen, TxtFn, Actions and StevesArg fields copied from the correspondinq format menu list entity. It also includes NxtEnt, DispRslt SlctRslt, HilitRslt, InstanceBase, InstanceMax, and BlankState fields containing data similar in purpose to similarly named fields of the previously described selector entity of FIG. 8. The formatted list entity also includes ActEnvWidth and ActEnvheight fields con-taining data indicating the actual width and heightof the selector stack determined from the actual number of items on the list (LstLent and the size of each selector. LstStart and LstAdjust fields contain parameters used to control selector array scrolling when the array is too large to be dis-played in its entirety. In such case the last two selectors of the array cause the array to scroll up or down when selected.
Another menu entity which may be included in each menu is a ruling entity, the template and formatted forms of which are shown in FIGS. l1 and 12, respectively. The ruling entity is used to draw boxes around individual selectors, or groups of selectors, or to draw lines separating various parts of a displayed menu. The template menu ruling entity (HIMRulTmplStr) of FIG. 11 includes EntTyp, PlaceHold, DispFn and StevesArg fields similar in purpose to similarly named fields of the selector entity. The PlaceCode and PlaceData 3~ fields include data indicating relative or absolute starting and ending positions of a line, and a ColorIndex field indicates line color. The line type (solid, dotted, dashed, etc.~ may be determined by a function to which the LineTypFn field points. Alternatively, line type may be 40 ~2~Z~o specified by a LineTyp field indicating one of a set of predetermined line types. The formatted ruling entity structure (KIMRulFmtStr) of FIG. 12 includes NxtEnt, EntTyp, PlaceHold, DispFn, DispRslt, StevesArg, InstanceNo, ColorIndex, LineTypeFn, and LineTyp fields containing data utiliæed for the same purposes as similarly named data fields of previously described entities. In addition, StartX, StartY, EndX and EndY indicate absolute screen coordinates of line endpoints.
A text menu entity is utilized to describe text (or an icon) to be displayed in a non-selecta-ble portion of a menu for annotation purpsses. The template version of a text entity ~HIMTxtTmplStr), shown in FIG. 13, includes EntTyp, PlaceHold, DispFn, PlaceCode, PlaceX, PlaceY, Overlayed, FcolorIndex, BColorIndex, StevesArg, TxtIcon and TxtUniq fields which have functions similar to previously described fields of the same name.
TxtLen field indicates the length of the text to be displayed, and a TxtUniq field contains a pointer to data in ROM describing the text or icon to be displayed. A format~ed version of the text entity (HIMTxtFmtStr)p shown in FIG. 14, includes NxtEnt, EntTyp, PlaceHold, DispFn, DispRslt, PlaceX, PlaceY, Overlayed, FColorIndex, BColorIndex, StevesArg, TxtIcon, Txtlen, and TxtUniq fields similar to previously described fields of the same names.
An output field entity allows display of data such as measurement results produced by the ~teady ~tate system. As previously mentioned, to establish display vf data in an output field, HIM
subsystem 92 sends a mes~age to ~he steady state system and thereafter the steady state system 41 ~208~3 automatically updates display of this data whenever the date value changes. The template ~ersion of an output field entity (HIMOutFmtStr), shown in FIG. 15, includes previously discussed EntTyp, DispFn, StevesArg, PlacéCode, PlaceX, PlaceY, FColorIndex, and BColorIndex fields. The index number for the entity is contained in an OutFldNo field. The formatted version ~HIMOutFmtStr) of the output field entity, shown in FIG. 16, includes pre-viously described NxtEnt, EntTyp, DispFn, DispRsltStevesArg, PlaceX, PlaceY, FColorIndex, BCoiorIndex, and OutFldNo fields.
Only one menu of a particular type may be displayed, but more than one menu of a given type may be formatted and ready for display. The current menu list 126, indicating which formatted menus are concurrently active~ is implemented as a family of RAM data structures as shown in FIG. 17. A master data structure (HIMCurLstStr) is a list of pointers ActMnu() to each of a set of HIMActMnuStr struc-tures, one for each menu type. Each HIMActMnuStr structure includes a pointer PtrVal to the storage location of the header file of an active Idisplayed~
formatted menu and a ConCur pointer to a HIMConCurStr structure comprising a list of pointers PtrVal() to the storage locations of the template menu header files of each formatted menu (including both active and non-active menus) of the type asso~
ciated with the HlMActMnuStr structure.
The selection map 128 of FIG. 4 i5 implemented as a family of RAM and ROM struc~ures as shown in FIG. 18. A master structure in ROM, HIMMnuDataStr, is a list of MnuDef() pointers to a set of HIMMnuDefStr structures in ROM, one MmuDef() pointer and one corresponding HIMMnuDefStr struc-42 ~Z9Z080 ture being provided for each menu type. EachHIMMnuDefStr structure includes Left, Top, Width, and Height fields which determine the size and position of each menu and a TchMap pointer to a HlMTchMapStr structure in RAM. One HIMTchMapStr structure is provided for each active menu and is updated whenever, a new menu becomes acti~e or a currently displayed menu is changed, the update being based on data in the corresponding formatted menu. Each HIMTchMapStr structure contains the LckFlg boolean associated with the menu and a set of pointers to HlMTchStr RAM structures, one fQr each selector in the menu. Each HIMTchStr struc-ture contains an ActPtr pointer to a formatted entity Action structure, an EntryNum instance num-ber identifying the selector, and PixLft, PixTop, PixRgt, and PixBot fields indicating the absolute screen position of each selector.
The above-described commands, routines, and data structures enable the human interface mana-gement subsystem to control the display of menus permitting an operator to adjust and monitor the operating state of an instrument such as an oscilloscope. Menus are selected to be added or removed from a display on a screen by HIM subsystem 92 in response to changes in the operating state of the instrument. When a configuration command is generated by the HIM subsystem 92 in response to menu item selection, or by any other source of configuration commands r the command execution system changes the values of on~ or mo~e stored configuration parameters which control the operating state of the instrument and then transmits an Update command to HIM subsystem 92.
In response to the Update command, HIM subsystem 92 43 lZ9ZOBO

determines the current operating state of the instrument by checking the values of the configura-tion parameters and determines from information provided in the template menus whether a menu is to be added or removed from the display depending on the current configuration parameter values. HIM
subsystem 92 then~updates the menu display so that menus appropriate for the operating state of the instrument are automatically displayed while irrelevant menus are automatically removed from the display, thereby minimizing the need for an operator to manually select appropriate menus to be displayed or removed from display. In addition, HIM subsystem 92 also adds, removes or modifies items in displayed menus in response to changes in the operating state of the instrument, according to instructions provided in the template menus, so that only those menu items which are appropriate to a given operating state are displayed.
While a preferred embodiment of the present invention has been shown and described, it will be apparent to those skilled in the art that many changes and modifications may be made without departing from the invention in its broader aspects. The appended claims are therefore intended to cover all such changes and modifica-tions as fall within the true spirit and scope of the invention.

Claims (15)

1. A method for adjusting the operating state of an instrument of the type having display means for displaying a menu, comprising the steps of:
selecting a first menu, comprising at least one menu item, from among a plurality of menus, each menu corresponding to an operating state of said instrument, said first menu being selected by said instrument since it corresponds to a current operating state of said instrument:
causing said display means to display said first menu; and adjusting the operating state of said instrument in response to operator selection of a said menu item.

2. A method for adjusting the operating state of an instrument of the type having display means for displaying menus, and having memory means for storing data including configuration parameter values, the operating state of the instrument being determined according to said configuration parameter values, the method comprising the steps of:
storing menu data in said memory means describing characteristics of a plurality of menus, each comprising at least one operator selectable menu item, said menu data including instructions associated with each operator selectable menu item for displaying the associated menu and for altering configuration parameter values when an operator selects a selectable menu item of the associated menu;
selecting a first menu comprising an operator selectable menu item from among said plurality of menus according to configuration parameter values stored by said memory means;
causing said display means to display said first menu according to said instructions included in said menu data; and adjusting configuration parameter values stored by said memory means according to said instructions included in said menu data in response to operator selection of a selectable menu item of the displayed first menu.

3. The method according to claim 2 further comprising the steps of:
selecting a second menu from among said plurality of menus for display by said display means according to the adjusted configuration parameter values; and causing said display means to display said second menu according to said instructions included in said menu data.

4. The method according to claim 2 wherein said menu data stored in said memory means includes instructions for determining according to configuration parameter values which of said plurality of menus are to be displayed.

5. The method according to claim 4 wherein said menu data stored in said memory means includes instructions for selecting menu items to be included in each of said plurality of menus when displayed according to configuration parameter values.

6. The method according to claim 5 wherein said menu data stored in said memory means includes instructions for determining according to configuration parameter values the appearance of each menu item included in each of said plurality of menu items when displayed.

7. A method for adjusting the operating state of an instrument of the type having display means for displaying menus and memory means for storing data including configuration parameters, the operating state of the instrument being determined according to values of configuration parameters stored in said memory means, the method comprising the steps of:
storing in said memory means menu data describing a plurality of menus each comprising at least one operator selectable menu item, said menu data including first instructions for selecting subsets of said plurality of menus for display by said display means according to values of said configuration parameters, and second instructions for modifying values of said configuration parameters in response to operator selection of at least one selectable menu item from said plurality of menus;
causing said display means to display a first subset of said plurality of menus;
modifying values of stored configuration parameters according to said second instructions in response to operator selection of a menu item of the displayed first subset of said plurality of menus;
selecting a second subset of said plurality of menus according to said first instructions and modified values of said configuration parameters; and causing said display means to display said second subset of said plurality of menus.

8. The method according to claim 7 wherein the step of causing said display means to display said second subset of said plurality of menus comprises the substeps of:
causing said display means to cease displaying menus of said first subset not included in said second subset; and causing said display means to begin displaying menus of said second subset not included in said first subset.

9. A method for adjusting the operating state of an instrument of the type having display means for displaying menus including operator selectable menu items, and having memory means for storing data including configuration parameters, the operating state of the instrument being determined according to values of configuration parameters stored in said memory means, the method comprising the steps of:
storing in said memory means menu template data describing a plurality of menus comprising operator selectable menu items, said menu template data including first instructions for selecting menus from among said plurality of menus and for displaying at least one of the selected menus according to values of said configuration parameters stored in said memory means, and second instructions for modifying configuration parameter values stored in said memory means in response to operator selection of at least one selectable menu item of said plurality of menus;

storing in said memory means menu format data describing a first subset of said plurality of menus selected according to said first instructions;
selecting at least one of said first subset of said plurality of menus for display according to said first instructions; and causing said display means to display said at least one menu of said first subset selected according to said menu format data.

10. The method according to claim 9 further comprising the steps of:
modifying values of said stored configuration parameters according to said second instructions in response to a menu item selection made by an operator from said at least one displayed menu;
modifying said menu format data stored in said memory means such that the modified format data describes a second subset of said plurality of menus selected according to said first instructions and changed values of configuration parameters; and causing said display means to display at least one menu of said second subset selected for display according to said first instructions.

11. The method according to claim 9 wherein said menu data stored in said memory means further includes instructions for selecting according to configuration parameter values menu items to be included in displayed menus.

12. The method according to claim 11 wherein said menu data stored in said memory means further includes instructions for determining according to configuration parameter values the appearance of each menu item to be included in displayed menus.

13. An apparatus for adjusting the operating state of an instrument, comprising:
display means for displaying a menu selected from among a plurality of menus, each menu corresponding to a different operating state of said instrument; and means for selecting a first menu comprising at least one menu item, from among said plurality of menus, said first menu corresponding to a current operating state of said instrument, for causing said display means to display said first menu, and for adjusting the operating state of said instrument in response to operator selection of a said menu i em.

14. An apparatus for controlling operation of an instrument comprising:
display means for displaying menus;
memory means for storing configuration parameter values and for storing menu data describing a plurality of menus including operator selectable menu items; and configuration control means for controlling instrument operation according said configuration parameter values, for selecting according to stored configuration parameter values a first menu from among said plurality of menus, for causing said display means to display said first menu according to said menu data, for modifying configuration parameter values according to said menu data in response to operator selection of a selectable menu item of said first menu, for selecting a second menu from among said plurality of menus for display by said display means according to the modified configuration parameter values, and for causing said display means to display said second menu according to said menu data.

15. An apparatus for controlling operation of an instrument comprising:
display means for displaying menus;
memory means for storing configuration parameter values and for storing menu data describing a plurality of menus including menu items;
configuration control means for controlling instrument operation according said configuration parameter values, for selecting a first menu from among said plurality of menus according to stored configuration parameter values, for selecting at least one menu item to be included in said first menu according to stored configuration parameter values, for causing said display means to display said first menu according to said menu data, for modifying stored configuration parameter values according to said menu data in response to operator selection of a menu item of said first menu, for selecting a second menu from among said plurality of menus for display by said display means according to the modified configuration parameter values, and for causing said display means to display said second menu according to said menu data.