WO1996013216A1 - Control system for opthalmic surgery - Google Patents

Abstract

An object oriented control system (10) for use by a surgeon in opthalmic surgery has a plurality of modules (e.g., (20, 30, 40, 50) for controlling the tasks of a plurality of microsurgical instruments, each of the modules responsive to a data control signal to control the operation of its respective instrument. A computer control device (10) receives the control commands from a surgeon and invokes one or more of the computer program objects while the control system periodically polls the control field of each computer program object to determine the status of each selected task and enable or disable the execution of the functions in accordance with the polled status to generate data control signals to control the operation of the instruments.

Description

CONTROL SYSTEM FOR OPTHALMIC SURGERY

BACKGROUND OF THE INVENTION

1. FIELD OF THE INVENTION

The present invention relates to the field of ophthalmic surgery, and in particular to the control of micro surgical systems used in ophthalmic surgery.

, -, 2. DESCRIPTION OF THE PRIOR ART

Microsurgicai systems including a plurality of related surgical modules and instruments are known for preforming precise microsurgicai procedures in the. field of ophthalmology, and had been widely used for performing interior as well as posterior chamber surgery.

In either type of surgery, a remote hand piece having a small surgical instrument is used to cut, macerate or cauterize the eye tissue while an irrigation or infusion liquid such as Ringer solution is brought to the site of the surgery. The cut or macerated tissue (detritus) is carried away from the surgical site by aspiration through a suction conduit or tube, which may or may not be connected to the tool and to some type of collection vessel i.e. a bag or bottle located at a remote location from the instrument.

The operation of the various microsurgicai tools, including the suction produced in the suction conduit is usually controlled by the surgeon via some combination of nand switches and footswitches so that operation cf the tools can be controlled during surgery ~^* and so that infusion/aspiration can be regulated during the surgery without removing the instrument from the size of the surgery.

U.S. Patents 4,627,833 and 4,493,695 disclose ^ a microsurgicai system cassette assembly particularly adapted for ophthalmic surgery. Figure 1 of U.S. Patent 4,627,833 discloses a conventional prior art module system having a phaco emulsification module, a cutting module, an infusion/aspiration module and an ¹ illumination module.

U.S. Patent 4,643,717 discloses a phaco emulsification hand piece particularly adapted for use in the microsurgicai system illustrated in Figure 1 of U.S. Patent 4,627,833. ^5 Each of the foregoing patents, previously assigned to Site Microsurgicai Systems, Inc., are now assigned to the assignee of the present invention.

Other such Microsurgicai Systems include the model 8000V system of Cavitron Kelmon and the Occutome 0 II/Fragmatone II System of Cooper Medical Devices Corporation.

U.S. Patent 4,933,843 discloses a control system for ophthalmic surgical instruments having an integrated system control console which is programmable ^5 b the user by inserting a pre-programmed key into the system console. The key changes the default values normally used by the control system to those values selected by a particular surgeon. The system contemplates infusion/aspiration, phaco emulsification, 3° cutting and cauterization instruments, the operation of one or more being controlled by a footswitch.

5 U.S. Patent 5,249,121 discloses a remote ^* control console for a surgical control system, particularly adapted for ophthalmic surgery. This console includes a video display screen surrounded by a plurality of membrane switches which are used to set the ^ various operating states of the surgical instruments controlled by the system. The control system contemplates infusion/aspiration, phaco emulsification, cauterization, and cutting (vitrectσmy) .

U.S. Patent 5,091,656 discloses a fσσtswitch assembly with electrically engaged detents that is particularly adapted for use with the foregoing remote control console described in U.S. Patent 5,249,121. This patent discloses in Figure la, a prior embodiment of an integrated console for a surgical system, also having a CRT display with two columns of membrane switches adjacent either vertical side of the display. U.S. Patent 4,770,654 discloses an apparatus for driving powered surgical instruments particularly adapted for use in ophthalmic surgery. To implement and control the various functions of the system, a central processing unit reads a plurality of switches and sensors to control a pneumatic system which drives the surgical instruments, and to control a vacuum generation systems uses to aspirate, cut or fragment tissues and fluids in the operating site.

One common problem that has arisen in the modular prior art systems is a necessity for matching the microsurgicai instrument to the module used to drive the instrument. Micro surgery necessarily entails very small and extremely precise instruments which may need to be balanced with respect to the natural resonance of z^'r.e instrume t and the frequency of the pneumatic or electronic circuitry used to drive the instrument. In many prior art modular systems, this is a time consuming and expensive procedure.

Furthermore, in completely integrated

-^> consoles, the multiplicity switches and components renders the device unduly complex and difficult to upgrade or improve. A significant improvement in the performance of one instrument or modular component may require an upgrade of the entire console.

SUMMARY OF THE INVENTION

The present invention is a fully integrated surgical system for ophthalmic surgery which utilizes an object oriented control system. The system includes a plurality of modules for controlling the operation of a plurality of micro surgical instruments including infusion/aspiration, phaco emulsification, cauterization and cutting instruments. The electronics of each of these modules are configurable, and are controlled by data control signals to generate electronic or pneumatic signals which control the operation of each of the respective instruments. An electronic display system is provided for displaying a plurality of sets of control parameters wherein each of the instrument modules has an associated set of control parameters that are displayed by the display system. The display system is also an input device and the surgeon may invoke a system task or instrument module by simply touching the icon displayed on the screen. Similarly, secondary state functions or tasks can be altered or re-programmed by touching the _ΛΛ„

WO 96/13216

j -

display screen. Input from tnε surgecn to control the - operation of one or more individual instruments may be through the touch screen of the electronic display, or, during the operation, from a user programmable footswitch which acts as an input device for entering ^ control commands during the surgery. The central control system is an object oriented control system that includes an operation Kernel and a plurality of computer program objects, with a separate object for each of the modules and instruments. Each of the program objects ^^• includes a computer program object for implementing tasks of the associated module which may be setforth as having executable primary and secondary state functions and a control field having status bits for each task. The operating kernel receives control commands from a ^ surgeon via the electronic display system or the programmable footswitch and in response thereto invokes one or more of the computer program objects to accomplish the primary or secondary tasks. The control kernel periodically polls the control field of each of ²⁰ the computer program objects to determine the status of each selected task and to enable or disable the execution of the primary or secondary state functions in accordance with the task status.

The aforementioned design enables integration 5 of all of the modules through the centralized control system, but yet enables a module and its associated computer program object to be upgraded, without having to replace the entire operating system, or its associated control switches. By upgrading the computer ° program object, the operating parameters displayed on the electronic display system and the surgeon preferences and cnoices can be updated as the program 1 object is updated. The instrument modules include electronic drivers that are actuated by separate micro processors associated with the module. This enables for quick and speedy interchange of instruments in the event ^Ό of a malfunction since calibration of the instrument to the module can be accomplished electronically by the associated microprocessor. The use of a fully programmable footswitch enables the functions or tasks executed by the footswitch to change as each successive module is invoked through the centralized control system. This enables the individual surgeon to set surgeon preferences for each phase of the micro surgical procedure quickly and easily by merely touching the screen of the display. The display system includes a CRT touch screen display having a plurality of icons displayed thereon which are used to invoke specific tasks. As each task is invoked, the controls associated with that task, and any prs-set operating ranges are displayed on the CRT display. Bar graphs function as both output and input devices inasmuch as when the task is invoked, the initial display of the bar graph represents a preset level. The surgeon can adjust the preset level by touching the bar at its desired level or by dragging the bar with the figure tip to a desired level.

Alternately, up and down arrows are provided to change the preset value. During operation, the preset value and the actual value at the instrument are displayed side by side as an output display device. This type of control and indicator design is consistently applied for all of the surgical modules and all of the surgical functions which have both a preset control value and a -¹ monitored actual value which changes in real time, hen t o modules are invoked at the same time, both sets are displayed on the screen simultaneously. Thus, when infusion/aspiration has been invoked, and the surgeon is using a cutting or phaco emulsification hand piece, both sets of controls and both se:s of monitored actual values will be simultaneously displayed. When an icon selection enables multiple selection options, a drop down or side fly panel will be displayed showing the selection options. When the user makes a selection the panel disappears and the screen returns to its previous display.

It is therefore an object to the present invention to provide an object oriented control system in which the program code for implementing a task, and the surgeon preset data values associated therewith are invoked when the task function is invoked.

It is another object to the present invention to provide an integrated system for ophthalmic surgery that may be easily updated or reconfigured to an improved instrument design by loading a new program object.

It is another object of the present invention to provide an improved display system which provide for simultaneous control and indication of preset values and monitored actual values.

It is object of the present invention to provide an integrated system for ophthalmic surgery with an improved variable speed pump to generate positive or negative pressure as desired, and as directed by the control system. - 3 -

t is anotner ob ect of the present invention - to provide a user programmable footswitch in which the f nctionality controlled by tne footswitch may be altered from task to task. The footswitch further includes accessory switches that may be used by the surgeon to invoke preset values or additional functionality at the option of the surgeon.

It is another object of the present invention to provide surgical modules having improved electronic drivers for generating electrical control signals for " microsurgicai instruments.

It is another object of the present invention to provide a plurality of micro processor controlled modules, which are in turn controlled by a central micro processor utilizing an object oriented program control system.

Other objects and advantages of the invention may be more readily appreciated and understood by reference to the following detailed descriptions and the associated drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1(a) is an isometric view of the control console and visual display system of the computer controlled apparatus for performing opthalmic surgery. FIG. Kb) is an isometric view the modified electronic footswitch of the present invention.

FIG. 1(c) is an illustration of the remote control unit 13 for operating the system of the present invention. FI3. 2 is a system block diagram illustrating - the various subsystems (hardware modules) comprising the microsurgicai system 10.

FIG. 3 is a conceptual diagram of the microsurgicai control system and software architecture of the instant invention.

FIGs. 4(a)-4(d) illustrate the CRT control and indicator displays for the phaco module.

FIG. 5 illustrates the CRT control and indicator displays for the bipolar module. ° FIG. 6 illustrates the CRT control and indicator displays for the fiber optics module.

FIGs. 7(a)-7(d) illustrate the CRT control and indicator displays for the Peristaltic I/A module.

FIGs. 8(a)-8(c) illustrate the CRT control and 5 indicator displays for the Rotary Vane I/A module.

FIGs. 9(a)-9(b) illustrate the CRT control and indicator displays for the cutter module.

FIG. 10 is a detailed diagram of the control task data structures for controlling GUI displays based upon user input.

FIG. 11 illustrates a state diagram of the control task power up procedure.

FIG. 12 illustrates a data flow diagram between the touch task and touch screen driver task. FIG. 13 illustrates a state diagram of the touchscreen task.

FIG. 14 illustrates a state diagram of the ts driver task^'.

FIG. 15(a) illustrates the key selections for the remote control unit 13. F G. 15(b) illustrates the transmission and - mode selection circuits within the remote control unit 13.

FIGs. 16(a)-16(j) illustrate the remote control task corresponding to the key selections of the -* remote control unit.

FIG. 17 illustrates the data flow diagram for the adc task 105.

FIG. 13 illustrates the state diagram for the dac task 107. FIGs. 19(a)-19(b) illustrate respective state and data flow diagrams for the ext_232 task.

FIGs. 20(a)-20(c) illustrate respective state diagrams for the footswitch task, the existing (linemaster) footswitch task, and the modified (ATXR) footswitch task.

FIG. 21 illustrates a state diagram of the bipolar task.

FIG. 22 illustrates a state diagram of the Phaco task. FIG. 23 illustrates a state diagram of the cutter function task.

FIGs. 24(a) and 24(d) illustrate state diagrams for rotary vane mode and peristaltic mode I/A tasks, respectively. FIGs. 24(b), (c) and (e) illustrate timing diagrams for the footswitch control positions.

FIG. 25 illustrates a state diagram of the fiber optic^'s task.

FIG. 26 illustrates a state diagram of the warning task. FIG. 27 illustrates a state diagram of the

-^■ audio task.

FIG. 28(a) illustrates the message structure for the display task 119.

FIGs. 28(b) - 23(d) illustrate the state

5 diagram implementation of the display task.

FIG 28(e) illustrates the state diagram for painting actual value bargraphs on the CRT display.

FIG. 29 is a functional block diagram of the phacoemulsification module 30 of the present invention. ° FIG. 30 illustrates the phacoemulsification handpiece 25 and power cord 326 for connection with the phacoemulsification module of the microsurgicai system

10.

FIG. 31 is a control flow diagram for the 5 improved phacoemulsification module 30 controllable by the control system of the present invention.

FIG 32. is a toplevel flow diagram of the special test module included in the improved phacoemulsification module 30.

DETAILED DESCRIPTION OF THE INVENTION

Figure 1(a) illustrates the microsurgicai system 10 that is controlled by the control system of the present invention. The system 10 is an easy to use, state-of-the-art, computer enhanced, precision surgical instrument that is both mechanically and electrically modular in ^'design and intended for surgical use on the human eye. AS shown in Figures 1(a) and 3, the system contains the necessary components (hardware modules) housed in system console 5 to provide: ^ phacoemulsification ("phaco"), indicated as module 30; bipolar coagulation ("bipolar"), indicated as module 20; fiber optic illumination ("fiber optics"), indicated as module 60; cutting ("cutter"), indicated as module 40; - and, infusion, vacuum and peristaltic aspiration ("I/A pumps"), indicated as module 50. As shown in Figure 3, each hardware module interfaces with a processor module 8 and have remote control capabilities. Additionally, a CRT monitor ("CRT") 19 functions as the primary -_ - input/output ("I/O") device for the system and provides the means to select and set user preferences and selections. As will be explained in detail below, user input may be implemented by both the Touchscreen 15, which preferably is an ELOGRAPHICS^ touchscreen with -- touchscreen controller 15' overlayed onto the VGA monitor 16, and, a hand-held remote control unit 13 for communication with a remote receiver 13'.

The microsurgicai system 10 additionally includes a processor module 8 comprising a *-. m. microcontroller and suitable ROM/RAM memory for controlling the individual modules as well as the entire system 10. Connected to the processor module 8 is a speaker 11 for emitting audio frequency signals and a footswitch controller 17 which, as will be explained in _c- detail below, may comprise an existing type (Linemaster) or modified type (ATXR) footswitch. The processor module contains the necessary interfaces and serial communication channels for footswitch and remote controllers. It also provides both digital and analog input and output capability to communicate with other modules and external devices. Digital input from other

^•3 modules is accomplished using a single octal latch (not shown) and 32 bits of digital output are provided by four registered bus transceivers. Eight channels of analog output is provided by using two quad digital to analog converters and eight channels of analog input is provided by an analog multiplexer (not shown) and an analog to digital converter (not shown). Two of the input channels read reference voltages to allow automatic verification of the analog input system calibration. Additionally, the processor module 8 is provided with system timer and interrupt circuitry 4 that includes: a 100 millisecond watchdog timer, a system clock running at 8 Mhz, and periodic timers comprising Intel 8254 16 bit counters for dividing down the 8Mhz clock and for generating periodic interrupts. Details of the system timer function will be explained in further detail below.

The system 10 additionally includes power supply module 12 that is provided for connection to a universal a.c. energy source for powering the system. The module 12 is provided with a main power on/off switch and interlock circuitry 12' and functions to convert the main (line) voltage to appropriate DC voltages for all other modules in the system.

Since the microsurgicai system is computer driven, it offers a surgeon the option of programming surgical machine operational settings and indicators (e.g. bipolar power, aspiration flow rate, phaco power settings, etc.) into the computer's memory to eliminate the need for a support person (e.g. nurse) to know and manually change these machine settings before or during

: an operation or procedure. The processor

Ϊ ? module 8 contains the firmware (software in ROM-Read

- Only Memory) which is used to control the system and also to generate a graphical user interface (GUI) for display on the CRT. Speci ically, it is the microcontroller in conjunction with series of ROM look-

- up tables, that actually draws indicators on the CRT display 19 and then interprets the touch points on the transparent touch screen overlay 15, as will be explained in greater detail below. Since the computer knows the exact position of every graphic object it

--' displays, the touch points are translated by system software to specific display screen coordinates. The computer then correlates the touch points to the graphic objects displayed at those coordinates. The CRT touch screen display 19 is designed to look like a control ^ panel with bargraph displays indicating both preset user preferences and actual parameters. Both preset and actual values will each have separate bars within the same graph. Due to the real time operating system (RTOS), to be described in detail below, the graphs dynamically change as the changes occur in real time, just as conventional controls respond. Since the system has a touchscreen overlaid on the CRT, the bargraphs also function as input devices. The user can adjust the preset level by touching the bar at the desired level. 5 Moving the value of the bar causes the microcontroller to change a programmable control voltage in a circuit in the same manner as a potentiometer. For instance, as shown in Figure 1(a), fine resolution changes can be made by touching up or down arrows 33 located next to the bargraphs 32,34. Preset values appear in the left side 32 of double bargraphs, such as shown by the double

5 - m -

bargraphs indicating preset and actual power m the Phaco module control display shown in Figure 1(a) and Figure 4(a); the actual values appear on the right side bargraph 34. The actual value bargraphs are next to the preset graphs, and the height changes, up or down, as -' the actual value changes in real time. This display gives an instantaneous reference point for the actual value versus the preset value. This control/indicator design is consistently applied for all surgical functions having both a preset control value and a -~ monitored actual value which changes in real time. Other controls act like push buttons and repeated touching of a push button icon will cause the computer to turn that particular function on or off, in the same way as a physical switch, by supplying or ^ removing power to the circuit. When touched, the appearance of the button image, or icon, will change to show the selection. The icons graphically represent their associated functions. For example, the push button which controls the Infusion/Aspiration functions ⁰ is displayed on the CRT as an I/A icon which depicts an aspiration cassette with fluid in the container, such as shown in Figure 7(a). The Bipolar Module icon 21 as shown in Figure 5, is displayed as a set of forceps with a lightning bolt between the tips, which represents the 5 high voltage known to cause coagulation.

The CRT 19 shows only the controls needed for the user's currently selected devices, however, there is always ready access to all modules. As the user selects operating modes, the touch screen CRT display changes to show the selections. For instance, the selected icon will change in color, brightness, etc. to show the

5 change in status. If there are grapns or indicators for the new selection, these will be displayed on the appropriate part of the screen. New indicators and controls will be available for the user. The computer will interpret which areas of the display are active and also what actions to perform for that particular display, and for the selected mode of operation.

Operating parameter changes within a given instrument panel will be made when the user selects the icon for that parameter. A small display panel will show the selection options. When the user makes a selection, the panel will disappear and the screen will return to its previous display, indicating the change made.

As mentioned above in view of Figure 2 and discussed in greater detail hereinbelow, the hardware modules designed into the microsurgicai system 10 and controlled by the control system 100 of the instant invention provide phacoemulsification ("phaco"), bipolar coagulation ("bipolar"), fiber optic illumination ("fiber optics"), cutting ("cutter"), infusion, vacuum and peristaltic aspiration ("I/A pumps"). As shown in Figure 1(a), multipin connectors 101-104 are provided on the front of the control system console 5 to enable quick and convenient handpiece connection to the hardware modules intended for use in the system 10. For instance, connector 101 is the connection for the bipolar handpiece 20' and bipolar module 20. Connector 102 is the connection for the phaco handpiece 25 and phaco module 30. Connector 103 is the connection for the cutter handpiece 40' and cutter module 40.

Connector 104 is the connection for the fiber optic illuminator 60' for connection with fiber optics module 60. Additionally, a replaceable and disposable infusion/aspiration cassette 6 is provided for controlling the flow of an infusion solution, and the aspiration of this solution from the microsurgicai site through a plurality of pinch valves and vent chambers defined within the I/A module 50 disposable cassette. ? removable collection container 6' ' is provided for accumulating fluids and tissues aspirated from the microsurgicai site during the surgical procedure.

The Dhacoemulsification crocess

As shown in the functional block diagram of Figure 29, the phacoemusification ("phaco") module 30 includes a microcomputer 315, which in the preferred embodiment, is an MC68HC11 microcontroller comprising a system clock (not shown), timer interrupt circuitry, ROM/RAM memory, and I/O ports for controlling the module. The module 30 includes a phacoemulsification handpiece 25, as shown in Figure 30, that is compact, lightweight, and includes a piezoelectric structure designed to vibrate flat or bevel angled needles (not shown) at ultrasonic frequencies of up to 54 kHz in the preferred embodiment. Through output connector 102 at the output of the system console 5 (Figure 1(a)) and suitable power cord 326 (Figure 30) for connection therewith, an output power amplifier circuit, in conjunction with an FET driver circuit, operates to drive the phaco handpiece 25. Specifically, as shown in Figure 29, FET driver circuit 322 and power amplifier 320 receives and amplifies an ultrasonic frequency signal 319 that is output from a numerically controlled - 1 3 -

oscillator 13. The output driver circui - voltage drive signals 324 to operate the handpiece 25 and vibrate the needles at ultrasonic frequencies. Serial data signals 353 that represent the optimum ultrasonic frequency for the particular handpiece ^D installed and determined during a special test procedure (explained in further detail below), are input to a D/A converter 362 in the oscillator 313 from the microcontroller 315 for conversion into an analog voltage signal. This analog signal is subsequently

-° converted to a pulsed frequency signal 319 by a voltage to frequency converter (not shown) of oscillator circuit 318. The Phaco module 30 includes a voltage controlled power supply 212 which converts a 24 VDC signal 347 from system power supply 12 into a suitable DC voltage signal

- 357 for powering the microcontroller 315 and output driver circuitry.

The Phaco module is additionally provided with feedback circuitry 321 for generating instantaneous voltage, current, and power signals that represent power

- output delivered from the output circuit 320 to the handpiece 25. These signals are fedback to the microcomputer 315 for monitoring and control. As shown in Figure 29, signal 346 represents the instantaneous power delivered to the handpiece and this signal is 5 input to the processor module 8, which provides means for calculating the total amount of power delivered to the phaco handpiece 25 during time the handpiece has been activated. Other signals that are output from the Phaco module 30 for digital input to the processor

3- module 8 include status assignment bits including: Phaco handpiece fault bit, indicated as signal 341; Phaco

5 module enabled bit, indicated as signal 3 Z; phaco - module fault bit, indicated as signal 343; Phaco power reading valid bit, indicated as signal 344; and, Phaco handpiece installed bit, indicated as signal 345. As mentioned above, in the preferred ² embodiment, the system processor 8 of system 10 controls and monitors the power level and the user can select the Phaco operating mode, power level, pulse rate, etc., on the CRT Touch Screen Display 15 or buttons on a remote :ol. For instance, as shown in Figure 29, the user

1

-^ may select the handpiece "pulse" or "continuous" operating mode, which is represented as signal 348 for input from the system module 8 (touchscreen, remote control unit, or, footswitch) to the microcontroller 315. In addition, the user may select a desired pulse rate, indicated as signal 349, for input to the microcontroller 15 when operating the handpiece in the pulse mode. The analog power setting, indicated as signal 350 in Figure 29, is also user selectable, and this signal is input to the microcontroller 15 for 0 controlling the amount of power delivered to the handpiece 25. An additional signal 352 is input from the system processor 8, when it is desired to run a handpiece test for testing and optimizing power to the handpiece prior to its use. 5 Additionally, power to the handpiece is controlled by the footswitch 17. There are three modes: panel mode, where a fixed preset power is delivered to the handpiece when the footswitch is depressed; surgeon mode, where a power level between 0 and a percentage of 0 the preset that is proportional to the footswitch position is delivered to the handpiece; and, pulse mode.

5 nere the output power is pulsed at a user selected rate - from 1 to 15 pulses per second as the footswitch is depressed.

Figure 4(a) illustrates the phaco control settings on the CRT 19 touch screen display. The ^ phacoemulsifier icon 31 as indicated in Figure 4(a) is selected through the CRT Touch Screen Display 15 (and buttons on the remote). The percentage of power transmitted through the amplifier is controlled by the system microprocessor (processor module 8) and adjusted -" by the user by pressing the adjustable bar graph and power up/down control icons 33 on the CRT Touch Screen Display 15. The user selected power setting display 32 is shown in Figure 4(a) as a bargraph and numeric display on the CRT touch screen. The actual power -2 display indicator 34 displays the real time percentage of maximum power (actual power value) delivered to the handpiece and is shown in Figure 4(a) as below the preset power setting value displayed by bargraph 32. When the pulse on/off control icon 35 is selected, the 20 RT display 15 will reveal a screen, shown in Figure 4(c), having up/down arrow icons 36 to allow the user selection and adjustment of the pulse rate. Numeric display of the pulse-mode rate (range from 1-15 pulses per second) is shown on the CRT display 19 as display 5 37. As shown in Figure 4(a), when selected, the phaco time display 38 indicates the elapsed time in minutes and seconds, (maximum of 99 minutes and 59 seconds). When the energy display icon 39 is selected, the CRT display 15 will reveal a screen, as shown in Figure 4(d), indicating the cumulative amount of energy delivered to the handpiece during time the handpiece has been activated. When the time/energy reset control iron ^~ 39' is selected, the CRT display 15 will reveal a screen, as shown in Figure 4(d), indicating that the time and energy displays have been reset to zero. It should be understood that the phaco and cutting "' functions are mutually exlusive operations so that selection of the phaco icon 31 automatically turns the cutting function off (no pictorial image displayed). When the mode-selection control icon 31' is selected, the CRT display 15 will reveal a screen, as shown in ^{~ J} Figure 4(b), allowing the user to select either panel or surgeon mode.

The software controlled phaco module 30 consists of several processes as follows: tne Main Background process which performs nearly ail the ^" processing tasks required by the phaco module software; the Power On reset process which runs once when power is first applied to the phaco module 30 and drops into the Main Background Program process when it completes; the Special Test Mode process which controls the phaco -" module according to commands received from serial communication bus 359 and serial communication input port 361 (shown in Figure 29) from an external host, such as a personal computer running communication software; the Pulse Rate interrupt process which 5 functions to alternatively turn the Phaco module power output on and off at the proper rate when operating in pulse mode; and, the Periodic interrupt process which monitors the analog inputs from the system processor module and those internal to the Phaco module. Each of the above-mentioned processes will be described in further detail below.

5 ?: er Cn Reset Module

As mentioned above, the Power On reset process runs once when power is first applied to the phaco module 30. Initially, the module enable signal 351 that is generated from the system processor 8, enables phaco module operation. Specifically, this process configures the MC68HC11 Phaco microcontroller 315 for proper operation by: initializing the microcontroller's stack pointer (not shown); starting the analog to digital converter system comprising A/D converter 363 (Figure 29) which converts the 0-10 V analog signal representing power to be applied to the phaco handpiece into a digital signal transmitted over serial data line 354 for controlling the output of voltage controlled power supply 312; specifying and enabling two interrupt inputs and serial communication I/O ports and initializing the Serial Communication Interface 361; initializing the Programmable Timer IC (not shown); setting default values of initialized global variables; outputting default frequency to frequency D/A converter 362 (Figure 29) and outputting zero power to the power D/A converter; and, enabling all interrupts.

When the system processor enables the module enable signal 351, the the microcontroller 315 enables the FET enable and Power enable signals 364,365,

25 respectively, to turn on respective AND gates 366,367 to enable the driver circuitry to power the handpiece. Should a fault arise during the handpiece operation, the FET and/or Power enable signals 364,365, may become deactivated as controlled by the microcontroller 315 to remove power from the handpiece and deactivate the system.

ml J .n Background Prcqram Module

A top level flow chart of this module is shown in Figure 31. As mentioned briefly above, this module performs nearly all the processing tasks required by the phaco module software. It consists of a kernel (not - shown) which periodically polls the system status input register (not shown) at step 372 and uses the result to look up a state number in a look-up table (not shown) as indicated at step 374. A section of code corresponding to each state is then executed. In the preferred embodiment, there are seven defined states numbered from state 0 to state 6 as shown in Figure 31.

The Idle State (State 0), indicated as process 376, is entered whenever the hand piece 25 is connected and the phaco module 30 is not enabled by the system -^~ processor module. The code here outputs status via status bit 345 (Figure 29) to the processor module 8 to indicate that the module is ready and then returns to the software kernel.

The Start State (State 1^indicated as process -- 378, is entered when a hand piece 25 is connected and the phaco module 30 receives an enable signal from the system processor module. A test is first made to determine whether or not a hand piece test is required. If it is determined that a hand piece test is required, this section of code sends status to the processor module to indicate that a test predecessor is required and then returns to the kernel. The software will stay in this sta-te until a hand piece test signal 352 (Figure 29) is received from the system processor module. If a 0 hand piece test is not required, the code sets the module enabled status bit signal 343 of Figure 29 and

5 returns to tne kernel. .his will cause either the Phaco continuous or puise mode state to be entered next.

The continuous run mode

The normal or run fixed mode (State 2), indicated as process 380 in Figure 31, is entered when the module 30 is operating in the continuous power mode. The code here turns on the DC power and enables the output stage drivers so that power can be continuously delivered to the hand piece 25. Before returning to the kernel, a check is made to see if the Special Test mode (a module diagnostic mode), indicated as process 384, should be entered. If not, a return is made to the kernel (idle state).

The Run pulse mode

The run pulse mode (State 3), indicated as process 382 in Figure 29, is entered when the module 30 receives pulse mode on bit 348 (Figure 29) from the system processor. To accomplish pulse mode, the voltage controlled power supply 312 is turned on and off at the desired duty cycle. The on/off control of the voltage controlled power supply 312 at the specified duty cycle is performed by a pulse rate interrupt routine whenever the software is in this state. This routine enables the microprocessor to generate a serial data signal 354 for controlling the on/off pulse mode rate. Before returning to the kernel, the code checks to see if the Special Test mode 384 should be entered. If not, a return is made to the kernel (idle state). The Hand Piece test

The Hand piece test (State 4), indicated as process 386 in Figure 29, is entered when the hand piece test signal 352 (Figure 29) generated from the processor module, is received. The hand piece test is run and the results are reported back by means of the hand piece fault status signal 341. For instance, if the microcontroller determines that the VRMS signal output from the feedback circuit 321 is not within its predetermined optimum range when operating, the hand piece fault status signal 341 will trigger. The test remains in this state unit the hand piece test signal 352 from the processor module goes false at which time a return the kernel (idle state) is made.

The Hand Piece flag

The Hand piece flag (State 5), indicated as process 388, is entered whenever a hand piece disconnect signal 368, as indicated in Figure 29, is detected. The code clears the hand piece complete flag and the hand piece failed flag, and waits in this state until a hand piece is connected to the module after which a return to the kernel is then made. When these flags are cleared, a new hand piece test will be required before normal operation can take place.

The Module error detect

The Module error test (State 6), indicated as process 390 in Figure 29, contains Phaco module error detection capability. I D -

mode orccess

The special test module receives serial input from bi-directional serial communication data line 359 to the serial communication port interface 361 (Figure 29), and recognizes and executes valid commands. This ' module is entered from the Main Background Program module by software detecticn of an access code received over the serial communication interface comprising routines for communicating with external RS-232 serial devices. This process uses analog input variables from ~~ the Periodic Interrupt process (explained in detail below) . It also sets a counter which is decremented by this interrupt code when a timed delay is required.

A top level flow chart of the special test module is shown in Figure 32. As shown in Figure 32, ~~ this mode controls the phaco module according to commands received from the serial communication input port and enables special testing of the module and/or handpiece whether connected with or external to the microsurgicai system. The process consists of a kernel ~ (not shown) which receives a command interrupt input at step 373 and uses the result to look up a state number in a look-up table (not shown) as indicated at step 375. A section of code corresponding to each command is then executed. In the preferred embodiment shown in Figure -5 32, the following commands are recognized and will be executed when the phaco module 30 is in special test mode or handpiece test mode: the FMIN command, indicated as 377, sets minimum output frequency; the FMAX command, indicated as 379, sets maximum output 30 frequency; the FREQ value command, indicated as 381, sets handpiece output frequency at a value ranging

so between 0 < value < 4095, where 0 sets maximum and 4095 sets minimum; the POWER value command, indicated as 333, sets handpiece drive voltage at a value ranging between 0 < value 4095, where 0 sets minimum and 4095 sets maximum; the SWEEP power,fstar,fstop,fdelta command, indicated as step 387 enables the phaco module to sweep from fstart frequency to fstop frequency in increments of fdelta with drive voltage set to power; the HPTEST command, indicated as step 385, runs the hand piece test with results sent to serial output port. Hand piece test results consist of the optimum operating frequency (ptiezoelectric resonant frequency) for the present handpiece installed for efficient transfer of power to the handpiece; and, the EXIT command 389, which exits the phaco module from the special test mode to return to the main background program. Each of the command functions includes subroutines for enabling the phaco module to: read a line of serial input, compare two NULL terminated strings, convert signed, unsigned, decimal and hexadecimal strings to 16 bit binary, convert two's complement 16 bit binary to BCD, convert unsigned 16 bit binary to BCD, and convert unsigned 16 bit binary to hexadecimal.

Pulse Rate Interrupt Process

This process uses new pulse rate data provided by the Periodic Interrupt process when a change in pulse rate setting, indicated as signal 39 transmitted by processor module 8, is input to the microcontroller 315. It runs at a rate which is twice the pulse rate setting from the processor module. When the Phaco is in the run pulse state, this process alternately turns the voltage cor.trolled power supply 312 power on and off at the _ - desired duty cycle (1 - 15 Hz). It also checks the software state provided by the Main Background Program process .

5 Periodic Interrupt Process

This process reads the analog inputs for use by the Phaco system processes at a rate of 50 times per second (50 Hz). Power and pulse rate signals from the processor module 8 is used to control the module output _.1 power and to set the rate of the pulse rate interrupt. It uses the state of the software data provided by the Main Background Program process.

Serial Communications

2_.= The Serial Communications Module is a module that contains all the routines for communicating with external RS-232 serial devices. Included are the following routines: the "scinit" routine for initializing the serial communication port 361 (Figure

2 29); the "sndmsg" routine for sending a NULL terminated string; the "sndchr" routine for sending one character; the "getupr" routine for receiving a character and forcing conversion to upper case; the "getchr" routine for receiving a character; and, the "chkchr" routine for testing if the receive data register is full.

Included in the Serial Communications module is the Serial Peripheral Interface Module which contains all the routines for communicating with the frequency control and the power control D/A converters over the serial peripheral interface. The routines included in this module are: the "spinit" routine for initializing

5 _^a.

tne serial peπpneral interface; and, tne "spse.nd" routine for transmitting frequency and power settings to the D/A's.

Programmable Interval Timer Module

This module contains all the routines used to control the programmable interval timer IC. This device contains three 16 bit counters with programmable periods. A first counter is programmed to count the system clcck down to produce a constant 8 kHz rate which is used as input to the other two (second and third) counters. The second counter is programmed to produce a 50 Hz signal which is used as the interrupt signal for the periodic interrupt process described above. The period of a third counter is dynamically programmed to

15 be twice the desired pulse rate when the phaco module is in pulse mode. The output of this counter provides the pulse rate interrupt signal. The following routines are included in this module: "ptinit" which initializes the counters; "setnpr" which programs a new period in the

OΛ third counter (new pulse rate).

Pulse Rate Interrupt Module

As mentioned above, the purpose of this process is to alternately turn the phaco module power 5 output on and off at the proper rate when operating in pulse mode. This process runs as a result of an interrupt generated from a timer whose period is set to exactly twice the desired pulse rate period. The code here checks for a pulse rate change (from the periodic 0 interrupt module) and modifies the timer period if necessary. It then tests whether the module is in pulse

5 mode and returns from the interrupt if not in pulse ~ mode. If in pulse mode, the power is toggled from an en state if it's turned off, or, to an off state if it's turned on.

^"-' Periodic Interrupt Module

This module is executed 50 times per second as a result of an interrupt signal generated by the second counter of the programmable interrupt timer IC. The process starts conversion of A/D channels 0-3;

"^■" increments the interrupt delay count (pincnt); resets the watch dog timer; counts down the power OK delay count and if zero, and sets the power OK signal to the processor module true; waits for the A/D conversion to complete; reads the power setting value from the

^~" processor module; reads the phaco variable DC supply voltage; reads the mean squared hand piece current; starts conversion of A/D channels 4-7; if not in test mode (state 4), converts the 8 bit power setting value to a 12 bit value, and outputs to D/A; waits for the A/D

- " conversion to complete; reads the pulse rate value from the processor module; reads the average power to the hand piece; reads the mean squared hand piece voltage; if not in test mode (state 4), convert the pulse rate signal to an integer. If different than the current

^5 pulse rate, store it for the pulse rate interrupt routine; and, exits from the interrupt.

The electrocoagulation process

The bipolar module 20 is an electrosurgical ^^υ module which provides electrocoagulation typically used to stop bleeding after incision in the sclera by

35 delivering high frequency electrical energy to tissue captured between the tips of bipolar forceps 20'. The electrical current coagulates and cauterizes bleeding from small vessels in the sclera. Funct : =.^' ietai.. of

^• du l - ^' '. can be found in co- f -, - -: T aoD-- -- _.i ion for which priority is based ' on u.s. s/n oθ/330,9₂5 assigned to the -same assignee of the instant invention and the disclosure of which is incorporated by reference herein.

Briefly, the Bipolar module 20 operates by developing a pulse train of high frequency electrical

Λ energy which is coupled into the forceps by a transformer which is part of an amplifier circuit and which additionally functions to limit current leakage and isolate the patient from the system ground so that electrical energy is constrained between the tips of the

- forceps. A control signal turns the energy on and off and is transmitted through the amplifier. The bipolar Module 20 has settings for variable percentage of total power and the percentage of power transmitted through the amplifier is controlled by the system

^ microprocessor.

The bipolar 20 can be controlled with either a modified footswitch 17 (Fiσure Kb)), as described in

. , co-filed PC" appl--atι:r -o for which priority detail in _{is based on} u.s. _s/_{n 08}/330,925 assigned to the same assignee or tne instant invention

²5 and the disclosure of which is incorporated by reference herein, or, the currently existing peristaltic footswitch. The modified footswitch has several features which are not available on the peristaltic footswitch. As explained in greater detail below, the system 10 automatically determines whether the modified footswitch or the peristaltic footswitch is installed.

5 Figure 5 illustrates the bipolar control settings on the CRT 19 touch screen display. The bipolar icon 21 indicated in Figure 5 is selected through the CRT Touch Screen Display 15 (and buttons on the remote) . The percentage of power transmitted through the amplifier is controlled by the system microprocessor and adjusted by the user by pressing the power up/down control icons 22 on the CRT Touch Screen Display 15. The user selected power setting display 23 is shown in Figure 5 as a bargraph and numeric display on the CRT touch screen. The generator indicator 24 displays the actual (real time) power value and is shown in Figure 5 as matching the preset power setting value displayed by bargraph 23.

System fiber optics

The Fiber Optic Module 60 is easily integrated into the microsurgicai system 10 to permit precisely controllable posterior segment illumination. It operates to supply a cold light source for use in vitrectomy or other posterior segment surgery where supplemental illumination is required. If a bulb burns out during a procedure, the fiber optic module 60 is capable of automatically switching to the spare bulb by use of an electronic sensor in the Fiber Optic Module, thus, eliminating any inconvenience of manual switching or system shutdown during surgery. Functional details of fiber optics module 60 can be found in co-filed PCT application no. for which priority is based on U.S. s/n 08/330,922 assigned to the same assignee of the instant invention and the disclosure of which is incorporated by reference herein. Briofiy, the fiber optic module 60 includes a ^* high intensity light bulb which gives off light in ail directions. There is a reflector behind the light bulb which reflects the light in a forward direction. The reflected light strikes a lens which refracts bent light rays into straight light rays. These straight light rays then pass through an infrared filter which filters out infrared radiation (the heat portion of light). This "cool" light then passes through another lens which narrows and focuses the light rays onto the fiber optic

7 connector. Finally, the light passes from the connector and through a fiber optic cable and illuminator (indicated as element 60' in Figure 2) and into the eye. As explained in detail in the above-mentioned copending application, the module 60 utilizes DC power ^" supplied through the system and the bulb consumes preferably about 150 Watts. The system 10 is capable of detecting a non-functional bulb even before the Fiber Optic Module 60 is used. The CRT Touch Screen Display will warn the user that the bulb is not functioning and

^~ " should be replaced.

The Fiber Optic Module 60 is electronically adjustable through the CRT touch screen and remote control user interfaces and Figure 6 illustrates the fiber optics control settings on the CRT 19 touch screen 5 display. The fiber optics icon 61 indicated in Figure 6 is selected through the CRT Touch Screen Display 15 (and buttons on the remote). As indicated by the alternate bulb display icon 62, the system 10 is capable of automatically switching to backup bulb; or, the user can 0 set a preference to allow manual switching through the CRT Touch Screen Display 15 or buttons on the remote.

5 - 4 -

light intensity control is adjustable by the user by ^~ pressing up/down arrow icons 63 on the touch screen 15.

The infusion,^'aspiration process

The I/A pumps module 50 is integrated into the ' microsurgicai system 10 as shown in Figure 2. The I/A pumps module 50 may utilize either a peristaltic pump (I/A peristaltic module), utilizing a flexible piece of tubing filled with fluid that is constricted at one point, wherein the constriction is moved in one

^~" direction by the rotation of the pump head rollers, pushing fluid along with a milking action. The milking action creates a vacuum that aspirates fluid and tissue from the eye through the handpiece 50' as indicated in Figure 2. As the pump head rotates, it forces a

"' constant quantity of fluid through the segment of the line that it contacts.

With a I/A peristaltic module, when the aspiration port of the handpiece is unobstructed, there is negligible resistance and, consequently, low vacuum.

~" However, flow through the line is relatively rapid and constant. The vacuum level builds only when the tip of the handpiece is occluded by placing it against the tissue to be removed. Aspiration flow into the tip then ceases, while the pump wheel continues to try to force

^{~ J} fluid through the line at a constant rate. As the volume of fluid in the line diminishes and the walls of the flexible tubing resist collapse, negative pressure (or vacuum) gradually builds in the system. When the vacuum level is sufficient to draw the occluded tissue ^ through the tip, there is a surge in the flow rate

5 ^■ I D -

accompanied by a drop in vacuum, and the system returns to its constant rate of flow.

The peristaltic pump I/A module 50 operates by forcing a constant quantity of fluid through the line at a given rate of rotation of the pump head rollers (not

-* shown); therefore, the only controllable pump parameter is flow rate. Since the pump head and tubing are constant and identical, only the rotational speed of the pump affects the flow rate. The I/A Module peristaltic module 50 has a pressure sensor element (not shown) to i _ sense vacuum level and reflux is accomplished by a vent solenoid that is held open in response to the footswitch user interface.

A disposable cassette 6 for collection of fluids and tissue and shown in Figure 1(a) as mounted on

^ receiver block 6' of console 5, is installed. The receiver block is the same as in existing perstaltic pump modules and incorporates the same spring-loaded pinchers and solenoid electronics for infusion control. As explained in detail below, software will control the

^ analog and digital electronics that are similar to existing electronic control of the motor and solenoid devices.

Aspiration in the I/A peristaltic module 50 will be accomplished by the same peristaltic pump system 5 as in prior art designs and use the same collection bag. Additionally, venting is accomplished through spring- loaded pinchers and retract solenoids.

As discussed in further detail in co-filed PCT application no. for which cricπty is . , . ..

on -U,.Sc. s/,n „0-8-/,3,3--0-.,9--2-.5,- assigned to the same assignee of the instant invention and the disclosure of which is incorporated by reference herein, an I/A rotary

5 vane module 50 may be installed in system 10. This module utilizes a rotary vane pump which serves to pump air out of a collection jar via a series of air compartments of variable volume. When the rotary vane pump is turned on, these compartments become larger during the suction portion of the cycle, drawing air into the compartments from the inlet port. During the discharge portion of the cycle, the compartments become smaller. The flow rate produced by the pump, and consequently the vacuum level in the collection jar, are adjusted by controlling pump speed. The vacuum created in the system range may range anywhere from 0 - 500 m Hg and vacuum may be shut off by solenoid pinching of the aspiration line. Additionally, venting is accomplished through a solenoid valve in the rotary vane I/A module i = to allow atmospheric pressure into the aspiration line. It is understood that a different cassette for fluid and tissue collection is to be used depending upon whether the I/A peristaltic or I/A rotary vane module is installed.

The system 10 interprets the footswitch 17 to control delivery of power to the surgical components of the system. By using the footswitch control, the surgeon may turn on and operate the various surgical handpieces and infusion/aspiration pumps of either the I/A peristaltic or rotary vane modules 50 of the surgical system. The I/A module functions are additionally controlled through the CRT Touch Screen Display 19,^' buttons on the system remote control, in addition to user actuation of the footswitch 17. As 0 shown in Figure 7(a), the vacuum level is user selectable and is preset by pressing adjustable bargraph

5 and up/down arrow icons 56 on the CRT touchscreen 15 (or "*^■ remote control button). The preset vacuum display is shown in Figure 7(a) as the bargraph and numeric display 51. During system setup, selection of the numeric units of vacuum, i.e., mm-Hg, in-H₂0, or in-Hg, is made and - the choice is displayed on the CRT touch screen 15 as numeric display 58. The actual vacuum indicator 52 displays the actual (real time) vacuum level value and is shown in Figure 7(a) as below the preset vacuum level displayed by bargraph 51.

The aspiration flow rate is user selectable through the CRT Touch Screen Display 15 (or remote control buttons) by pressing adjustable bargraph and up/down arrow icons 53. As will be later explained, the flow rate is then controlled via the footswitch 17. The -^~ aspiration flow rate display is shown in Figure 7(a) as the bargraph and numeric display 55. The cassette mounting "load/run/unload" functions are selected either during system setup, or, by the selection of a LOAD/RUN/UNLOAD icon 54 as shown in Figures 7(a) and -^Z 7(d). When the infusion mode "CLOSED/OPEN/AUTO" icon 57 is selected, the CRT display 15 will reveal a screen, as shown in Figure 7(c), to allow the user selection of the CLOSED/OPEN/AUTO modes. When the fixed/linear aspiration flow rate, icon 59, is selected, the CRT -5 display 15 will reveal a screen, as shown in Figure 7(b), to allow the user selection of fixed or linear aspiration flow rates.

As shown in Figure 8(a), when the Rotary Vane I/A module is installed in system 10, the vacuum level is ^ user selectable and is preset by pressing adjustable bargraph and up/down arrow icons 51' on the CRT touchscreen 15 (or remote control button). The preset aspiration flow rate display is shown in Figure 8(a) as the indicator bargraph and numeric display 53'. The aspiration indicator 54' displays the actual (real time) aspiration flow rate and is shown in Figure 8(a) as below the preset vacuum level displayed by bargraph 53'. As shown in Figures 8(a), when the fixed/linear aspiration flow rate icon 55' is selected, the CRT display 15 will reveal a screen, as shown in Figure 8(b), to allow the user selection of fixed or linear aspiration flow rates. As shown in Figures 8(a), when the infusion control option icon 52' is selected, the CRT display 15 will reveal a screen, as shown in Figure 8(c), to allow the user selection of OPEN/CLOSED/AUTO control options.

The cutting function

The Cutter module 40 for the system 10 is designed to satisfy all the requirements of both anterior and posterior segment surgery. It operates surgical hand-held cutters such as the prior art designs that include rotary, guillotine, and three microscissors that fit quickly and easily into the power handpiece 40' as indicated in Figure 2. The cutting speed can be varied from 0 to 500 cuts per minute to suit the particular procedure, and there is a choice of three cutting modes. As shown in Figure 2, the cutter module is incorporated into the same metal shell as the I/A module resulting in an I/A-Cutting Module. However, the I/A and cutting function remain independent and separate. In the preferred embodiment, the cutting function utilizes the same disposable cassette used for inf sion/aspiration.

Briefly, tho microsurgicai system 10 regulates the electrical power to a motor in the power handpiece to thereby control and monitor cutting speed. The power handpiece 40' (Figure 2) has a DC motor and gear train that converts electrical power from the cutter module into mechanical power to operate the cutting tip. Through the CRT Touch Screen Display 15 or buttons on the remote, the user can select cutting speeds from 0 to 500 cuts per minute (cp ) in increments of 50 cpm.

The system processor module also ensures that the cutting tip always stops in an open position so that tissue is not trapped in the tip. A switch in the power handpiece 40' closes once per shaft rotation to indicate that the cutting tip is open and that no tissue is trapped. The system 10 uses the signal from the switch to ensure that cutting tips stop in the open position. The system processor measures the time period between successive handpiece switch closures and will then use this value to compute the actual speed in cuts per minute. Based on this measured speed, voltage to the motor in the modified power handpiece is either raised or lowered to achieve the user's selected speed. The cutting module 40 will be adjusted through user interfaces (CRT Touch Screen Display 15, buttons on the remote) and additionally controlled via user actuation of the footswitch 17.

Figures 9(a) and 9(b) illustrate the cutting function control settings on the CRT 19 touch screen display. The cutting function icon 41 indicated in Figure 9(a) is selected through the CRT Touch Screen Display 15 (and buttons on the remote). The cutting mode operating conditions (rotary, guillotine/scissors, rotary oscillating) is selected by a series of icons 42 as illustrated in Figure 9(a). As shown in Figure 9(b), -^? icon 42 has been selected to reveal the rotary mode. Cut rate control is adjustable by the user by pressing adjustable bargraph and up/down arrow icons 43 on the touch screen 15. The user selected (preset) cut rate setting is shown in Figure 9(a) as a bargraph 47 and numeric display on the CRT touch screen. The bargraph indicator 45 displays the actual (real time) cut rate in cuts per minute value and is shown in Figure 9(a) as matching the preset cut rate value displayed by bargraph 47.

-^L-' Since the cutting function utilizes a power handpiece having a different connector, the system 10 allows the modified cutting function to detect when a power handpiece is installed and directly senses the position (open or closed) of an internal switch, which ensures the cutting tip stops in the open position. Icon 44 on the CRT display will display a warning message when it is determined that the cutter handpiece is absent. In the preferred embodiment, the system processor will provide closed loop control of cutter

²5 speed to minimize variations between handpieces.

The modified (ATXR) footswitch

As mentioned above and in view of Figure 2, the system 10 can be controlled with either a modified footswitch module 17 described in detail in co-f.- r:τ applicatio no. for which priority is based on U.S. _s/_n 08/330,925

35 assigned to the same assignee of the instant invention and the disclosure of which is incorporated by reference herein, or, currently existing peristaltic footswitch. The system 10 automatically determines whether the modified footswitch 17 or a peristaltic footswitch is installed. As described in the a.- - ionec riled

PCT application no. for which rr lty is based

modified footswitch 17 has several fea. res «nιch are not available on the peristaltic footswitch. Briefly, as illustrated in Figure Kb), the modified footswitch includes a foot pedal 171 which is mounted for pivotal movement on a frame within housing member 173. The rotatable foot pedal includes first and second sideswitches 175,177 which may be invoked by the surgeon while the foot pedal 171 is depressed. The modified

15 footswitch 17 also includes accessory switches 178,179 which are used to invoke preset patterns or operating characteristics of the surgical instruments, as desired by the surgeon. Housing member 173 also includes a non- slip heel rest 174 to secure the heel against inadvertent slippage. A multipin connector 176 is provided to connect the footswitch to a corresponding multi-pin connector on console 5 for communication with processor module 8.

The system 10 interprets the footswitch 17 to control delivery of power to the surgical components of the system. By using the footswitch control, the surgeon turns on the operates the various surgical handpieces and infusion/aspiration pumps which make up the surgical system.

As described in the above-mentioned co-filed PCT application no. for which priority is based on

U.S. s/n 08/330,925, the footpedal and

^•-.= switches send signals to the microsurgicai system 10. The system processor module then converts these signals to functional commands (e.g. aspiration, cutting mode, etc.). The footswitch 17 has five controls. The user depresses these controls for module functions: The Footpedal turns infusion, aspiration and phacoemulsification on and off and provides linear control of aspiration and phacoemulsification. The two bar switches 175,177 are provided whereby one side bar switch controls cutting and bipolar functions, and the other side bar switch controls the power reflux function. Two stand-alone switches 178,179 are provided whereby the user depresses these to select preset preferences and operational modes (i.e. vacuum presets).

The footpedal of the existing and modified footswitch, will control infusion, aspiration, phacc, bipolar and cutting. Phaco, bipolar or cutting will be activated when the pedal is depressed to position 3, depending on which module is selected on the CRT touch screen display. Additionally, the modified footswitch will control both the Peristaltic and Rotary Vane Systems I/A systems. The modified footswitch utilizes tactile feedback and the user will be able to disable this feedback. The system 10 will receive a signal that feedback is disabled and will display a message to the

25 user on the CRT touch screen display 19. Functional operation of the fσotpedal will remain the same whether or not tactile feedback is engaged.

System remote control

D -^> As shown in the diagrams of Figures 1(c) and 15, the remote control unit 13 is a handheld keypad which

5 transmits information to the system 10 by an infrared ^' light signal 216. The keys 215a-215j on the remote control 13 correspond to function selections and preset level adjustments as described for the CRT Touch Screen Display. The remote control buttons have the same icons and legends as their respective screen buttons and controls. The Remote Control can be used to control such functions as turning the modules on cr off, adjusting preset values, etc.

Pressing the appropriate remote control keys will cause the same responses from the machine as touching the CRT Touch Screen Display 15. The system control and display responses to remote control interaction will be identical to the same CRT Touch Screen Display actions.

The remote control unit 13 communicates in either of two ways. In wireless use, the user has a standard infrared remote control, similar to the type used for consumer television control. From many locations, operating room personnel can point the remote control at the CRT Touch Screen Display 15 and touch the remote control buttons to activate functions or change settings. The infrared detector/receiver 13' for transmitted information in this mode is located in or on the top of the CRT Touch Screen Display monitor 19 as shown in Figure 1(a).

25 When a surgical operation is to be performed in an obstructed environment, the remote control unit may be configured for wired operation. In wired operation, a fiber optical receiver cable 217 is installed in a remote control fiber optic connector 218 of the remote ^ control unit, as shown in Figure 1(c), for connection with a suitable fiber optic connector indicated as

-55 element 118' in the system 10 console as shewn in Figure 1(a). A fiber optic receiver/demodulator is provided for receiving fiber optic transmission and this receiver communicates with the system processor module 8. When the fiber optic cable 217 is installed, transmission of "^' the infrared light is automatically rerouted from the remote control unit fiber optic connector 218 which also functions as a fiber optic transmitter, to the fiber optic connector in the system 10 console. This cable is used when the Remote Control is positioned in the ^{~ ^} sterile field or any other position where the line of sight to the CRT Touch screen display 15 is obstructed.

Figure 15(b) illustrates the transmission and mode selection circuits within the remote control. Depression of keys 215a-215j on the key pad matrix 215 ~ are detected, encoded, and amplitude modulated by the key encoder 221. The modulated signal 223 is received by mode selection circuitry 226 and signal 232 is output. If no optical fiber 217 is detected by the fiber installed sensor 227, the mode selector circuits ^~" delivers the signal 232 to the infrared transmitter circuit 231. If an optical fiber is installed in the fiber optic connector 218, the fiber optic sensor 227 generates sensor signal 233 for receipt by mode selection circuitry 226 which selects the fiber optic ^ transmission circuitry 238,239 for transmitting the modulating signal through the installed fiber optic cable to the system 10.

Real time system control

30 As mentioned above, the control system of the instant invention is designed to provide a graphical

5 user interface ("GUI") for employing various pull-down menus and dialogue boxes on the CRT for interaction with a user or operator. Thus, the system is provided with on screen graphics capability for displaying graphics objects such as push buttons, icons, slide bars, etc., - representing various functions and σperatng parameters. In a preferred embodiment, the microsurgicai system requires a CRT having a minimum resolution of 640x480 by 16 colors with RGB component control. It is understood that the type of CRT monitor 19 used is a design choice. A 386 PC based microprocessor is provided in the processor module 8 of system 10 with memory and I/O capabilities necessary to send and receive commands to the bipolar, phaco, cutter, fiber optics, I/A pumps, remote control unit, and footswitch modules to enable ~ real time monitoring and control thereof. The state- driven real time operating system ("RTOS") provides the immediate processing of input to provide optimum performance of each hardware module as well as the overall system. All software code may be written in a

^~" high level language, for e.g., Pascal, ANSI C, etc. and uses a compiler on a PC platform. The software architecture description provided hereinbelow is described in a C language convention.

The RTOS is a multi-tasking kernal which is a

~5 design methodology in addition to a set of system calls and associated code. Embedded in this concept is a software architecture partitioned into "objects" (real and virtual) wherein each object mirrors its respective hardware operation. Thus, the touchscreen task "object"

3^ is responsible for detecting and validating the user input. The associated code that is executed by each "object" is implemented directly from a previously defined state-diagram which describes the object's singular behavior. As will be described in greater detail below, each object in the partitioned system consists of two parts: 1) a task (object), which is analagous to a virtual processor for maintaining the state of the object and 2) a process, which implements the task's behavior and represents the state machine code implementation of the task object. As mentioned above, the preferred software language is ANSI C, and the description hereinbelow will use C language conventions. One skilled in the art may desire to use other higher level languages.

All tasks within the system 10 have identical structure and are declared in the RAM array variable: struct task_def task[NUM_TASKS] which defines five fields:

1) a Ctrl field which provides bit encoded status and control bits for the task.

Included in this field is a first bit representing the active/inactive state of the task. For e.g., if the bit is logic 0, the task is inactive and will not be run by the program executive (EXEC) function.

A second bit represents the resume active state of a task as set or cleared by particular system calls.

A third bit, the timer request bit, when set, informs the system timer task that a specific task has an outstanding timer function request.

A fourth bit, tiπ-er_wa)ceup, is set to inform the system timer task that a specific task which requests the timer function requires a wakeup( ) upon reaching a - -. / -

If this bit is not set, the task remains active throughout the requested time function.

A fifth bit, ready, is used to indicate the status of seme requested action.

2) a ps-state field which stores the current primary state variables which are used as indexes into a system look-up table containing the primary state function pointers for each process, and, secondary state variables which are used by the task itself in any primary state, to provide sub-state switching. These state variables are accessed via system calls next_state, wake_me_up( ) , tsend( ) , and get_sec_state( ) .

3) a resume_ps field also stores primary and secondary state variables. When a primary state sequence is entered from two or more other primary states, and each of these initial primary states indicate the exit conditions after the common state sequence completes, then the final state of the sequence retrieves the exit primary/secondary states for proper resumption of the state machine.

4) a timer_count field of the task definition contains the equivalent count of timer interrupts to achieve a specific time value. A task will call either start_my_timer( ) or wake_me_up( ) which loads this field with the specified argument time value. The system timer task, upon checking the timer request bit, will decrement this count and take appropriate action if the decremented value is zero.

5) the remaining field of the task structure is an array of preferably three general purpose counters which may be used to store buffer indices, counts, etc.

^= -43-

As will be described in further detail below, all tasks are defined as TASK_XXX.

System processes implement the task's behavior and represent the state machine code implementation of the task object. These processes are single (C language) functions for each required primary state and are entered into a system look-up table (LUT) prior to compile time. The EXEC will execute a task's primary process function based on whether the task is active and the value of the task's primary state is variable. As will be described in further detail below, all processes are defined as PRCC_XXX in a one-to-one correspondence with a particular task.

System Calls (available to the module coding implementation of the system 10) provide access to the task structure so that the fields of the task structure never have to be accessed directly from any module. Embedded within the system calls is the access to the current task global variable maintained by the EXEC, and this is the mechanism by which the RTOS knows which task is calling system functions.

The System Calls that are implemented in the control system of the invention include:

Timer functions such as: start_my_timer( ) which starts a task's timer with value passed as argument; stop_my_timer( ) which stops a task's running timer; chk_my_timer( ) which returns a boolean TRUE if the task's timer is still running and FALSE if otherwise; and, wake_me_up(W_TMR, . . ) which is used to achieve fixed delay and will ensure that a task is inactive until terminal count is reached.

Inter-task messaging functions such as: tsend( ) which sends a message and parameter to the receiver task. The sender task remains inactive until the receiver task acknowledges the message with a clr_msg( ) ; send_msg( ) which sends a message without going inactive or waiting for acknowledgement; get_msg( ) which is used by receiver tasks to check for messages from specified sender; get_parm( ) which returns message parameter as sent from sender task; and, clr_msg( ) which sets message value to zero and which constitutes an acknowledgment from a receiver task. The RTOS provides efficient inter-task communication through the use of pipes which are unidirectional channels which connect sender to receiver. An array 'struct pipe_def' is accessed via the system calls 'tsendU', 'get_msg()', 'get_parm( ) ' , and 'clr_msg()'. Whenever these system calls are used, a 2-dimensional lookup table (not shown) is accessed to determine which pipe number connects the source and destination task pair. This table contains source and destination task pair and contains *NO_PIPE's for all unnecessary connections, but uses the PIP_src_dst value for all defined connections.

Flow-control functions such as: next_state( ) which is used by a task to specify its next primary and secondary states; get_sec_state( ) which returns the current secondary state value of the calling task; set_exit_state( ) which sets up exit conditions from common state sequences; resume_exit_state( ) which sets primary and secondary states to the states that were specified with a previous call to set_exit_state( ) when exiting the last state of a common state sequence; inact( ) which forces the current task to go inactive. The task can then only be activated with a wakeup( ) ,..,

WO 96/13216

^• 50 -

which activates the specified task; and, next_task( ) - which specifies the next task to be run by the EXEC. General purpose counter functions include: set_rr.y_cr.tr( ) which initializes the specified counter to specified count; get_my_cntr( ) which returns current ^" contents of specified counter; inc_my_cntr( ) which returns the incremented value of a specified counter; and, dec_my_cntr( ) which returns the decremented value of a specified counter. Status/querying functions such as: chk_rdy( ) which checks the ready/busy status of

-° specified task; set_busy( ) which is used by the task to set itself busy (TRUE) or ready (FALSE); set_status( ) which is used by the task to set general purpose status value (0-7); and, get_status() which is used to check general purpose status value of the specified task.

- Although not shown, inherent in the microsurgicai system 10 is a system executive which provides the execution function (EXEC) for the virtual processor tasks. In the main program (explained below) the EXEC function loops through all tasks and executes their - primary state functions if the tasks are active.

Additionally, the EXEC checks for timer interrupt events and runs the system timer and interrupt circuitry 4 (Figure 2). The EXEC task accesses a two-dimensional array of primary state pointers by using the loop 5 variable, system task's process index, and the task's primary state variable as the second index. The process function is then executed by the following statement:

task_st_tab[proc_indx][proc_state]) ( ) ; 0

5 Figure 3 is a general diagram of the ¹ microsurgicai control system 100 illustrating the software architecture and the tasks and lines of inter¬ task communication and data flow. Described below are brief descriptions of each task's responsibilities and each of the following tasks will be described in greater detail hereinbelow.

The TASK_AT_CTR , hereinafter control task 110, maintains the overall state of the system by receiving user input from the touchscreen 15 and remote control -" unit 13 and by dispatching messages via a built-in, inter-task messaging system (not shown) to lower level drivers/tasks that interface with the hardware components to effect to required action.

The TASK_IR_REM, hereinafter remote task 113 -"- receives encoded button press/release data from the Remote Control Unit 13, and forwards messages to the Ctrl task 110.

The TASK_TS_DRVR, hereinafter ts_driver task 115, is an interrupt driven receiver for Touchscreen data ^■" generated by the Touchscreen 15 and signals the

TASK_TOUCH, hereinafter touch task 125, that either a "touch" (with position data) or "untouch" has occurred.

The TASK TOUCH, hereinafter touch task 125 receives touch/untouch signals and coordinate data from the TS_DRIVER 115 and determines which, if any, valid screen object has been selected. This task determines which graphic object (push button, window icon,, or slide bar),' if any, is affected and then forwards messages to the control task 110 for further action. 0 During different states of the system, the control task

5 110 must indicate to this task which screen objects are available for touch and untouch.

The TASK_FTSW, hereinafter footswitch task 117, interfaces the footswitch hardware 17 and maintains variables associated with switches and the linear ^ potentiometer.

The TASK_BIP, hereinafter bipolar task 120, provides the hardware interface to bipolar unit 20. This task maintains the real time (actual) values for screen display bar graphs.

The TASK_PHACO, hereinafter phaco task 130, provides the hardware interface to the phaco module 30 and maintains phaco actual values for screen display.

The TASK_CUTTER, hereinafter cutter task 140, provides the hardware interface to the cutter module 40 ^~" and maintains actual values for display.

The TASK_IA, hereinafter I/A task 150, is responsible for driving either the PERISTALTIC or ROTARY VANE I/A Cutter assembly 50 in the system. This task additionally maintains actual values for infusion and ^{~ ~} aspiration for display.

The TASK_FIB_OPT, hereinafter fiber optics task 160 provides the hardware interface to the fiber optics module 60.

The TASK_AUDIO, hereinafter audio task 111, pς

' controls the PC speaker 11 for all audible feedback and alarm condition audio.

The TASK_GUI_DIS, hereinafter display task 119, is responsible for all activity associated with screen objects to be displayed on the CRT display 19 including push button press/release, mode switching, help screen

35 o ^■

display, etc. This task receives instructions from the control task 119.

The TASK_WARN, hereinafter warning task 109, monitors all identified alarm scenarios associated with individual modules and system operation and sends messages to the control task 110, AUDIO task 111, and

DISPLAY task 119 to put tasks in appropriate alarm/warning state.

Other tasks, not explicitly illustrated in Figure 3, include:

The TASK_NV_RAM, hereinafter nv_ram task, maintains all variable data associated with system configuration through power-down and subsequent power- ups. Data includes 'preference settings', user passwords, touchscreen calibration information, etc.

The TASK_ADC, hereinafter adc task 105, contains all of the functions relating to the eight channel ADC (analog to digital converters).

The TASK_DAC, hereinafter dac task 107, contains all of the functions responsible for continually writing the DAC (digital to analog conversion) values to the proper DAC channels.

The TASK_EXT_232, hereinafter ext 232 task 108, is responsible for handling received remote control unit key codes, validating codes and sending a message to the remote control task 113.

System timer

All tasks have the option of utilizing service from the system timer which are timer interrupts occurring every 50 s. The occurrence of these timer interrupts is checked by the EXEC which in turn calls a - 54 -

function that decrements ail outstanding timer counts of registered tasks.

Tasks requiring timer service must be known at compile time and are entered into a ROM lookup table

¹timer_tab[ ] ' which is scanned by the system timer

-¹ function to determine which tasks it must check. If a task has an outstanding timer request this function will decrement the task's timer value, an if necessary, wake up the task. A task utilizing the system timer uses system calls wake_me_up(w_TM , ...) which puts the task

^~" inactive for the specified time, and start_my_timer( ) which keeps the task active with its timer running in the background. The start_my_timer( ) call is used to check that a task action occurs or completes within a specific time. ^ The system timer does not operate as an operating system task, but instead is handled by the combination of the timer interrupt service (ISR) and a function call

'do_sys_tmr( ) ' directly from the EXEC within the 'main' program. From within the EXEC, the call 'do_sys_tmr( ) ' p -" accesses a table 'timer_tab[ ] ' which contains a list of tasks known at compile time that may require system timer service. As mentioned briefly above, the processor module 8 contains two (2) 8254 Counter/Timer devices, one of which is programmed for a free-running 5 rate-generator which generates interrupts at a 50 ms rate. The system timer interrupt service routine simply sets a flag signalling the executive to call the system timer function 'do_sys_tmr( ) ' before running the next task within the executive. As each interrupt occurs,

30 the executive is flagged (sys_flags.timer_intrpt = TRUE;). In addition to calling 'do_sys_tmr( ) ' , the executive will also call 'rd_lm_adc( ) ' to read the LineMaster footswitch linear value, if necessary, every 50 ms.

Additionally, as shown in Figure 17, the system timer IΞR also flags the executive to sample ADC channels: each interrupt for the existing (LineMaster) linear channel (if enabled), and any ether channel (except Phaco actual power) every fourth interrupt for a 200 ms rate.

Description of state diagrams

All systems described herein are described as being in a unique state at any point in time. The tasks were designed using state diagram techniques as known to ones skilled in the art and familiar with C language programming and with real time operating systems. In each state diagram, a state is depicted by a numbered/labeled state 'bubble'. State transitions occur when a particular event/condition occurs. The state transition is depicted by an arrow from the current state to the next state bubble and some textual description of the event or condition that affects the state change.

As shown in each task's state diagram, each state transition arrow is labeled with an (input condition/output action) description. This 'i/o' description may use any symbology to convey that the system remains in the current state until (condition or event) occurs which results in (output action) AND a transition to the next state. Input conditions and events often require logical operators to express compound conditions such as ^~A AND B' or (A OR (B AND - . O '

C) ) for e.g. The state diagrams use a "." (dot) to -¹- represent logical AND, and a ^~v' to indicate a logical CR. A logical NOT is depicted using the standard cverscore. If no output is required in a specific state transition, a "-" (dash) is used. ^" The state diagrams described use either textual description or 'C'-like descriptions of the input/output pair. Input conditions and events are implemented in 'C by the 'if(cond )'. Output action is implemented by single line C statements. The next state specifier is i ^ implemented by some form cf the following system call: 'next_state( primary state, secondary state)'. The following example illustrates typical state transitions.

if ((condition A &-. condition B) " condition C) r

I

If output_action_l; output_action_2; next_state(next_pri_state, next_sec_state) ; } or 2^ if (event_flag) { event_flag = FALSE; output_action_l; next_state(next_pri_state, next_sec_state) ;

} else

25 { if ( icond A)

{ next_state(next_pri_state, next_sec_state) ;

} }

3 -¹

35 The system EXECUTIVE function

The main program, 'main( ) ' , of the system 100 contains the system initialization code, the RTOS executive, and all the RTOS system calls. The first part of 'main() ' initializes the interrupt vectors and sets all task variables to their initial states. At this point, all tasks are inactive, except control task which is responsible for waking all other tasks in its state 0.0 as shown in Figures 11-13 and 17-28(c). Subsequently, execution resumes with the RTOS executive (EXEC) .

The executive, EXEC, is a 'while(l)' loop that cycles round robin through each of the tasks. If the task is active, the executive executes the task's primary state function found in the 2-dimensional array ' task_st_tbl[NUM_TASKS] [ 16 ] ' which is a table containing up to sixteen (16) primary state functions for each of the defined tasks. For those tasks where the process is implemented in less than 16 primary states, the task table entries are filled with 'null_funct' to provide table symmetry.

Prior to executing a tasks 's primary state function, the EXEC checks whether or not a system timer interrupt has occurred. If so, the flag is cleared, and the 'do_sys_tmr( ) ' function is called to service those tasks with outstanding service requests. Additionally, - the *rd_lm_adc( ) ' function is called at this time to read the footswitch ADC channel. Additionally, prior to executing a task's primary state function, the executive checks a flag which indicates that the remaining ADC channels must be read. This flag is set every fourth ^■ o -

system timer interrupt to provide ADC service every 200 ms.

A table 'task_tab_indxι'NUM_TASKS] [ ] is accessed directly by the EXEC to determine which process is associated with each task. As mentioned above, there is a one to one correspondence of TASK_XX to PROC_XX. Since more than one task may use the same process, the second element of the array may be used to specify task- specific data (array index) to be used by the process code.

The heart of the RTOS execution unit is the table task_st_tab[NUM_PROCESSES) [MAX_STATES_PROC] ) ( ) which is accessed by the EXEC upon executing each task's primary state function. Each task's process index is obtained from 'task_tab_indx[ ] ' and used to index into the first dimension of this table. The second array dimension index is the task's primary state variable (0-15) which now completely specifies the index of the primary state function to execute.

Detailed description of control task

Figure 11 illustrates a general block diagram of the control task power up procedure. Upon power up, indicated at step 175 in Figure 4, the EXEC (or main program) ensures that all tasks are initialized to a their respective initial states (hereinafter state 0.0) after first waking up the control task 110. Each task wake-up sequence is then performed and all graphics display objects and user settings are initialized. Control task 110 is responsible for starting surgical procedures from either the module push buttons or the pull-down mode menus. It is also responsible for the non-surgical procedure processes of setting user

' preferences and responding to information requests.

This is accomplished by messaging the display task 119 to.display the desired screen, and then to handle the user input. Almost all activity performed between the

- control task 110 and the other tasks is performed through the above-mentioned system call 'tsendU' utilizing the messaging system. At step 177, the display task is awoke and a system logo will appear. The next two steps 181 and 183 set the two window screens

~~ for the GUI display as well as the main menu comprising icons for performing a desired task.

As mentioned briefly above and illustrated in

Figures 3 and 10, the control task 110 maintains the state of the system by receiving user input and messages

-' from touch task 125 (and/or remote task 113). Thus, control task 110 will execute a single function for a

PRESS message 201 or RELEASE message 202 received from touchscreen task 125 (or remote task 113) and will send appropriate messages to the display task 119 and other tasks to perform the user requested action. The

'ctrl_state' variable contains the current state of the control task 110 and this variable is used to index into a first look up table 210, 'ctrl_state_tbl[ ] ' , which contains constant data relevant to each of the many *~ t- -¹ particular machine states. Among the data is a pointer to a second LUT 220 which contains a list of screen objects (indexed by OBJ_XXX) that are "touchable" for the current control state. This second LUT is available to both the touch task and remote control task for

30 messaging the control task upon ^"touch/untouch' (for

5 ^■o J-

touch task) and for mapping remote keys to screen objects (for remote control task).

The control task 110 uses the 'set_system' function to start a requested surgical procedure and will set up the procedure using default or current user's preferences. The information relevent to each surgical procedure is contained in a LUT (not shown).

Each task's state driven processes are implemented in C language files. For instance, in the preferred embodiment of the contrtol task, one file is ι created that contains the execution state logic for detecting messages and executing the PRESS and RELEASE functions upon receipt of touch and release messages from the touch task or remote task. Additional support functions that are responsible for effecting a control ^ state change (for e.g., execution state) and for setting up a selected surgical procedure are contained in another file. A group of files may be created that contains all functions that are executed upon the PRESS and RELEASE of a particular screen object. It is

~- understood that one skilled in the art may desire to incorporate any number of the above-mentioned and hereinafter described functions in a myriad of equivalent ways.

-5 Description of display task

The display task 119 provides for the display of all screen objects. At power up, this task initializes the graphics adapter for VGA 640 x 480 16 color mode, initializes the RGB values, and sets the palette for the

3° IDLE mode. Thereafter, as shown in Figures 10 and

28(a), it receives messages from the control task 110 to

5 change the screen display for a specified user request. "^• If no message is received, the display task updates certain parameters currently displayed at a 0.5 second rate. These parameters include the "actual value" bars, described above, and those parameters which indicate some system value (for e.g., phaco energy). The display of screen objects itself is based on a list of objects which describe each object's type, table index, and palette color. The array Obj_list'[] of structures provides the necessary information for the display task -~ 119 to reference other look-up tables that provide type- specific parameters such as screen position, text font, icons, etc. The type index field of 'obj_list[ ] ' is used to index into the 'type table' where detailed attributes of the object are found. These include ^~ screen coordinates and any additional other pointers needed. Each object type has a corresponding function that is executed to build and display that object type in its current state.

Most object types have different states at any -- given time that affect the way they are displayed. These object states are contained in an 'obj_state[ ] ' array and are updated primarily by the control task before a message is sent to the display task to update that object. Most objects can be controlled by the ²5 'do_obj (obj ) ' function which in turn calls any of

*do_text()', 'do_icon()', "do_pb()', and so on, based on the object type.

In the VGA graphics mode used, only 16 colors may be displayed at a time. To achieve optimum color ° control, each of the 16 colors per palette points to one of the 48 RGB color entries which is initialized by the

5 DISPLAY task at power up. Preferably, each of the different system modes has a unique palette associated with it. This lookup table of palettes uses defined constants (PAL_xxx) to index the required palette. This method of color control is transparent to the DISPLAY ' task and only indirect references to each object's color are required by this task.

An important data structure lookup table is used by the DISPLAY task 119 to provide overall control of the screen for all modes. The 'surg_proc_data[ ] ' structure array provides all necessary information for the DISPLAY task to manage both screen windows.

The CRT display 19 is implemented as a layered series of screens. Messages are received from control task (state 1.1 in Figures 28(b) and 28(d) indicating in

I ^J which layer to place a specific screen. Control task 110 will then sequence through its process states to paint the objects for the specified screen. Screens are defined as to which objects and text appear in each window, palette information, and other ancillary data Λ ^w~ required to properly paint the specified screen on the specified layer. The state diagram implementation of the display task 119 is illustrated in Figures 28(b) through 28(d). The state diagram of Figure 28(e) describes the process of painting a real time bar graph

²^ on the CRT display.

This task also receives messages from the warning task 109 as shown in Figures 3 and 28(a), to display a warning panel and to restore the previous screen.

0

5 - _n * -

Description of touch task ^{^} The process code for touch task 125 will now be described. All screen objects touched result in an ^"object pressed' message to the control task 110. Likewise, all object ^"untouches' result in an ^"object - release' message to the control task. This display task is responsible for taking coordinate information from its interface driver ts_driver task 115, determining which object, if any, has been touched or untouched, and forwarding a message to control task 110.

This code lists all objects that are valid touch objects for the current state of the screen display. Control task is responsible for maintaining a pointer to a table which contains a subset of screen objects to be scanned by the touch task 125. ^{1 Ό} Figure 12 is a state diagram of the TASK_TOUCH process code. After initialization, i.e., state 0, TASK_TOUCH remains in a first state (indicated as state 270) as long as there is no touch. Upon detecting a touch, which sets off an enable flag, a determination is made as to whether the data obtained is valid, i.e., whether a valid object (for the current screen state) was touched, and if so, forwards a message to TASK_AT_CTRL and resumes execution in a third state indicated as state 290 in Figure 12. If the touch pc

^J occurred where no valid object exists, no message is forwarded to the control task and execution resumes in a second state indicated as state 280.

In the second state, if an untouch occurs, execution resumes to the first state 270 where it waits 3° for another enable signal. If, however, the user

^"drags' the touch onto a valid object, a ^"press' message

5 will be forwarded and execution resumes in the third state 290. If touch coordinates continue, but not from a valid object, this is handled as a ^'release' of that object, and a message is forwarded to task control and execution resumes in a fourth state indicated as step 295 until an untouch is sensed.

Bar objects are handled in the third state 290. While in this state, and as long as the object touched is a present bar, ^"press' messages are continually sent to TASK_AT_CTRL to update the preset bar display. i

It should be understood that the section of code supporting the touch task will additionally support mouse operation if a touchscreen is not installed on the display. The state driven code is identical, except that touch/untouch information is obtained from calls to mouse routines instead of from TASK TS DRV.

Description of ts driver task

As mentioned briefly above and in view of Figure 12, the ts_driver task 115 is the driver interface between the Touchscreen Controller connected to COM1, which is an RS-232 serial communications port 116 and the touch task 125. The driver code for performing the ts_drive process simply provides, as an output to TASK TOUCH, information indicating if the touchscreen 5 coordinates are available, and if so, whether the coordinates supplied are for a touch or untouch.

Figures 13 and 14 illustrate repective state and data flow diagrams between the touch screen driver task and touch task. As shown in Figure 14, the ELOGRAPHICS 0 Touchscreen Controller 15' interfaces to the microsurgicai system through COM1. The controller will

5 - . . -

rovide continuous coordinates (12-bit) for both X and Y - while sensing a touch (or drag). The ts_driver task is interrupt driven as is shown by the presence of interrupt service routine 118 in that the controller will forward touch coordinates during a touch. Each ^~ received packet 104a contains (2) bytes of raw data representing both X and Y coordinates. This raw data is stored in the array 'xy[4]' for subsequent conversion from 4095 (X) to 640 and from 4095 (Y) to 480 to match the display resolution.

This task must also provide untouch data which is not directly provided by the Touchscreen controller. This is implemented by starting a (0.1 s) timer upon receiving touch data as shown in the state diagram of Figure 13. If the timer times-out without receiving ^■■-^■ another touch data packet, it is interpreted as an untouch at the last touch coordinates.

In interface with the touch task 125, ts_driver task 115 provides a flag 106b to indicate that touch data is available and whether the data applies to a -~ touch or an untouch. The coordinates available are translated to ts_data.ts_x and ts_data.ts_y coordinates data 104b translated from the raw data 104a into the appropriate screen resolution of 640 by 480.

² Description of remote control task

The TASK_IR_REM, hereinafter remote control task 113, receives messages from a TASK_EXT_232 (described below) to indicate that a key on the remote control unit 13 has been pressed. This remote control task forwards 0 a message to control task 110 in the identical message format as touch task 125, thus, simulating an Object

55 ^■ o o -

touch'. Control task 110 responds to these messages ^* identically regardless of the source (touch task or remote control task).

Figure 15(a) illustrates the remote control keys 215a -215j that are provided on the remote control unit ^" 13. Remote key codes are defined and the task 113 filters these key codes as received from ext 232 task. Based on the current surgical procedure, the task 113 determines the validity of the remote key, and if appropriate, forwards a message to control task. The task 113 supports REPEAT remote key functions for the two (2) arrow keys 213,214 used to increment or decrement presets. Surgical procedure remote keys function differently than manual touches on the Touchscreen because the keys do not act as toggles as -^ the touches do. To change preset values for the current procedure using the remote control keys, the procedure (module key) must first be pressed followed by either arrow key 213,214.

Upon receiving a remote key code from the ext 232

P^c-' task, the task 'illuminates' the remote control push button on the CRT display to visually indicate remote key detection. The task also handles low battery codes and contains line-of-sight-obstruction logic.

The process state diagrams, illustrated in

²5 Figures 16(a) through 161k) shows that upon detecting one of the modules key codes (keys 215a-215j of Figure 15(a)), arrow keys 213,214 are enabled to increment or decrement the presets associated with these modules. Once a module key code is received, a four (4) second ° timer is started during which the arrow key codes are enabled. If no arrow keys are received within this

5 time, i.e., EOT signal is received as shown in Figure

1

~ 16(k), no action is taken for the specified module. The remote module push button (MOD_4) is illuminated upon receiving remote key codes. This module push button is illuminated during the four second delay while waiting -' for subsequent key codes for the time the unit is in state 7.2 as illustrated in Figures 16(a) - 16( j ) . This module push button is released after the four seconds if no additional arrow keys are received.

State diagrams of Figures 16(a) through 16(j ) ^~" show the state logic implementation of remote control task 113. For instance, the selection of remote control unit key 215j in Figure 15(a) enables remote control of the bipolar module as illustrated in the state diagram of Figure 16(a). Selection of key 215g in Figure 15(a) -- enables remote control of the phaco module as illustrated in the state diagram of Figure 16(b). Selection of key 215f in Figure 15(a) enables remote control adjustment of phaco pulse mode as illustrated in the state diagram of Figure 16(c). Selection of key

PO

215ι in Figure 15(a) enables remote control of the cutter function as illustrated in the state diagram of Figure 16(d). Selection of key 215c in Figure 15(a) enables remote control of the infusion/aspiration module as illustrated in the state diagram of Figure 16(h),

-^ while selection of keys 215d and 215e enables remote control of infusion flow and vacuum adjustment respectively, as illustrated in the state diagrams of Figures 16(f) and 16(g). Selection of keys 215a and 215b enables remote control of the fiber optics module

3° respectively, as illustrated in the state diagram of

5 - . 3 -

Figure 16(i). State diagram illustrated in Figure 16( ) represents the arrow key control logic.

As illustrated in each cf the state diagrams, each remote control task idles in standby state 1.0. As a remote key is pressed, the key code message is filtered in this state and further processing occurs in other states, i.e., state 2.0 for bipolar state, state 3.0 for phaco, state 4.0 for the cutter, state 5.0 for the I/A, state 6.0 for the fiber optics. State 7.0 is used for EOT (end of text) and repeat key processing.

Description of the A C task

As shown in Figure 15(a), the adc task 105 is responsible for determining which channels need to be sampled based on the current surgical procedure and

15 simply sets a bit flag to indicate which channels need to be sampled. All channels, except the Phaco actual power channel, are read at a 200 ms rate. The sampling of these channels is controlled by the system timer interrupt (ISR) rate of 50 ms. Thus, every fourth

2°" interrupt flags the executive to sample the required channels. The LineMaster footswitch channel, if enabled, is flagged to be read every 50 ms.

The Phaco Power Monitor channel is read on demand by the phaco task. Its value is used to display the

^5 Phaco Actual bar graph and to display Joules of power delivered to the handpiece. The Phaco actual power channel is conditioned on a signal sourced in the Phaco Module which indicates if the ADC channel is valid during Pulse mode operation. If valid, the channel is

3° read 'in-line' within the Phaco task. All other channels are read by the executive when flagged by the

35 .9 -

syste timer interrupt. Sampling a specific ADC channel requires setting an analog multiplexer to the desired channel, waiting for multiplexer settling time, starting the ADC conversion, and waiting for results.

This task is also responsible for maintaining the ADC device gain and offset based on values sampled from the Vref (8.192 volts) and the ground channel.

The process code for the adc task 105 contains all functions relating to the eight (8) channel ADC. Most of the functions are used by the task, although

IC some functions are called directly from the RTOS executive and from phaco task. The analog multiplexer switches in one of eight (8) analog sources for 12-bit conversion by the ADC. The eight sources include: the Linemaster (existing) footswitch, the phaco power 5 monitor, the vacuum transducer, ground reference, and Vref. Reading the ADC involves selecting the source by writing a 3-bit pattern (0-7) to select the channel and utilizing 'read_adc()' call. A short delay is required to allow the multiplexer to stabilize. The conversion 0 is started by performing a write to one of the out ports. After a fixed delay, the conversation value can be read as MSB and LSB.

As shown in the data flow diagram of Figure 17, the LineMaster (existing footswitch) channel is 5 scheduled to be read every 50 ms. This is accomplished by the system timer 4 interrupt service (ISR) flagging the executive which in turn calls 'read_lm_adc( ) ' . If the displacement of the LineMaster footswitch must be read, it will be read at this time. The Vref, GROUND, 0 and the vacuum transducer channels are processed by the adc task. If these channels need to be read, they are

5 enabled by this task, read directly by the executive every 200 ms, and processed within this task.

At system power-up, adc task initiates an ADC calibration sequence. This enables the reading of the Vref and GRND channels 205, and upon completion, calls ^ 'adc_cal()' which checks that the respective channels are within allowable limits, and if so, establishes new ADC gain and offset values. ADC calibration is also performed approximately every 30 minutes in the background by the adc task. If calibration fails, a

¹ fatal system warning is flagged.

All ADC channel data, raw and post-processed, is stored in 'adc_data[ ] ' . This structure includes a (3)- element raw data buffer, an average value field, and a normalized value field. As each channel is sampled, the

-^ _raw data is stored in the raw data buffer. The three (3) values are averaged, and the resultant average is normalized and also stored in 'adc_data[ ] ' . The raw data is then shifted for subsequent reads of that channel. This post-processing is performed by the

^ functions ' dc_proc_data( ) ' and 'adc_avg_shift( ) ' .

Description of the DAC task

The dac task, is always active and is responsible for continually writing the DAC (digital to analog 5 conversion) values to the proper DAC channels. All tasks assigned a DAC channel output need only to set their values in an array, and this task will handle the actual writing of the DAC channel values. This task does not determine the values because the values are set

3° by their respective tasks. Each task is responsible for loading its respective array element of

35 dac val.DAC CHAN XXI'. The DAC channels are as

- f; llows:

0 - DAC-CHAN FO INT Fiber Optic Intensity

1 - DAC CHAN MOT SPD PERI/RV motor speed

2 - DAC CHAN CUT SPD Cutter speed

" 3 - DAC CHAN PROP VLV RV proportional valve

4 - DAC CHAN PHACO PWR Phaco power

5 - DAC CHAN PHACO PLS Phaco pulse rate

6 - DAC CHAN AUD VOL Audio volume

7 - DAC CHAN BIP PWR Bipolar power

These channel assignments are used internally only and do not correspond to the hardware DAC channels.

As shown in Figure 18, the table 'dac_adr_tbl[8] ' contains the high and low byte addresses for the internal channel assignments. The hardware port addresses for each channel are previously defined as DAC_(XX)_H and DAC_(XX)_L. Dac task 107 is designed as a two (2) state system. As shown in Figure 18, in state 0, the output value array (dac_val[]) is initialized to all zeros. The task counter 1 is initialized to (0) and is used to perform modulo-8 counting of the channels. Execution resumes in state 1 wherein the dac task outputs the value for the channel number contained in counter 1. Counter 1 is then incremented for the next pass to output the remaining channels on subsequent passes from the executive. After writing the last channel (7), a dummy read is performed to latch the output values for all channels.

Description of ext 232 task

The TASK_EXT_232, (external RS-232 task) is responsible for handling received remote control unit key codes, validating codes and sending a message to the remote control task 113. The process contains interface ^• driver code for external devices connected to a channel of a serial communication controller (Zilog - SCO contained in the processor module. As shown in Figure 19(b), received characters from the remote unit 13 generate a received character interrupt from the SCC. The task, including the interrupt service (ISR), validates the received characters and forwards them, via an inter-task message, to the remote control task for further processing.

Th ext 232 task, is a simple state machine driven by the ISR on received characters. As shown in the state diagram of Figure 19(a), state 0 initializes the SCC Channel A for receive only, at approximately 10400 baud. In state 1.0, the task waits for a received character as flagged by the ISR

(sys_flags.rem_key_avail) . The character is validated through a switch statement, and if valid, simply forwards a message to remote control task 113. This task is additionally used to simulate module hardware events by allowing the keyboard to generate events/values to test a variety of responses to the normally hardware-generated events.

Description of footswitch task

The footswitch task 117 contains all routines associated with both the existing and modified footswitch types. As shown in the state diagram of Figure 20(a), state 0.0 detects, at power up, which of the two footswitch types (Linemaster or modified ATXR), if any, is connected to the system 10. If the existing (prior art) footswitch is connected, execution resumes in states 1,4,5 and 6, indicated as element 198 in Figure 20(a) and 20(b). If the modified footswitch 17 is connected, execution resumes in state 2, indicated as state 199.

All states verify that the indicated footswitch continues to be connected, and if not, flags a warning to the user. If no footswitch is detected upon power- up, the footswitch task 117 will transit to state 7 (indicated as 197) where it continually scans the ~~ footswitch status for re-connection of either type of footswitch. It should be mentioned that all mechanical switches are debounced, using a debounce count.

The existing footswitch states scan the status byte to determine switch states and provide the " necessary debouncing to effect transitions to other states as shown in Figures 20(b) and 20(c). The linear potentiometer is connected between position (3) and full depression. As mentioned above, this analog signal is connected to an ADC channel which is read every 50 msec.

The modified footswitch 17 provides five (5) mechanical switches, only one of which is position related (top, or full release switch). Of the remaining four (4) switches, one is used for Reflux; the remaining three (3) are reserved for special function initiators.

Oζ

^~-' The modified footswitch position information is obtained from an optical encoder (not shown) which provides 12- bits of position data over the full range of motion. Both footswitch types utilize a single output data structure (struct ftsw_info footswitch) which is

3^C maintained by ftsw task 117 and read by all other tasks dependent on footswitch operation. Among the fields of the data structure is the normalized value of linear range (position 3 to full depression for the existing footswitch, positions 2 to 3 and 3 to full depression for the modified footswitch)). Other fields include booleans for enable/disable, connect/disconnect, type, and discrete positions (1,2 and 3).

The modified footswitch discrete positions are not signalled by switches, but rather by the optically encoded linear displacement value read through dedicated ports. These 'position counts' are defined and are used to compare the current position count to determine if the position flags in 'footswitch (.pos_l,2 and 3)' need to be set. This can been seen in state 2 of Figure 20(c). The modified footswitch also provides a signal indicating that the DETENT feature has been engaged. This signal is read through the status byte and causes the DETENT position counts to be used. Footswitch operation is enabled only when required and this task is controlled by control task 110 via the 'footswitch.enable' flag which is scanned in state 1 during full release.

Description of the bipolar task

As shown in Figure 21, the bipolar task 120 is responsible for controlling the bipolar cautery module 20. The module hardware is enabled by bipolar task upon the control task setting 'sys_flags.bip_en" to TRUE. The bipolar task 120 scans the footswitch structure to apply power at position 3 or the side switch for the modified footswitch 17. The Bipolar Module 20 responds to the desired power setting through its assigned DAC channel. This value on this channel will - i 0 -

be either zero or a value representing the preset. There is no 'surgeon' mode equivalent. TASK_3IP uses the LUT 'bip_dac[]* to select the DAC value for the given present value. This table includes DAC values for each percent of power (0 through 100).

The bipolar cautery module hardware provides internal faults and flags them in the status byte read by TASK_BIP. TASK_BIP continually monitors this status byte and, if any error is reported, disables the module and generates a warning to inform the user. Upon acknowledgment by the user, the module pushbutton is disabled and 'X' -out indicating the faulty bipolar module.

The cautery procedure uses the equivalent of 'panel' mode of operation in that when power is applied at footswitch position 3 (or side switch), the full preset power is applied. Actual power, as shown in the actual bar, reflects the preset power. There is no power monitor signal used for 'actual' power applied to the forceps.

The Bipolar Module 20 provides internal fault detection and signalling through its status which is continually monitored by TASK_BIP. If an error occurs, as reported by the status, TAS _BIP will shut down the module and disable the Module Pushbutton. The failure will be indicated by an 'X' through the module icon.

Description of phaco task

As shown in Figure 3, the phaco task 130 contains all primary state and support functions to interface to the Phaco Module 30, control task and warnings task. The state diagram for the phaco task 130 is depicted in Figure 22. The Phaco Module 30 contains its own -'^■ microcontroller (HC11) to handle all hardware operations once the module is invoked by the task i30. Interface signalling occurs through standard port I/O and includes module enable, status, and mode information. Power ~ settings, pulse rate and actual power delivered to the handpiece are analog values assigned on DAC and ADC channels respectively.

The phaco task 130 is structured to detect proper phaco handpiece connection, and prompts the user to ^l ~ initiate a required handpiece tuning test to find optimal operating frequency. It is also for driving the Phaco Module in both the Panel and Surgeon modes. User changes to the mode, pulse rate and preset power are all implemented within this task. ^ Additionally, task 130 also monitors the accumulated duration of energy delivered to the phaco handpiece for display purposes.

The Phaco Handpiece test (states 1.1 - 1.5) is initiated the first time the Phaco procedure is selected from power-up state 0.0 in Figure 22. This test is also initiated if the handpiece is removed and subsequently re-connected. (The system assumes a different handpiece has been installed. )

The Phaco Module internal processor (not shown) ^5 also monitors handpiece disconnect and flags this task (through the status byte) to indicate that a handpiece test is required. The user is informed of all handpiece exceptions through display panels managed by warning task 109. The handpiece test is initiated by driving a 3° bit in the Phaco module interface. This task will start a 30 second timer limit to complete the test. If the

35 handpiece passes the test, the normal Phaco screen is ^{^} displayed, and this task enters state 2.0 to go online and wait for the footswitch to be depressed to position 3. while online (states 2.0, 2.1 and 2.2 in Figure ^~ 22) the Phaco task 130 continually monitors the

'handpiece connected' status as well as 'module fault' as reported by the Phaco module through the status byte. Both events result in warning panels to inform the user of these exceptions.

In state indicated as State 2.0, the system waits for the footswitch to be depressed to position 3 before delivering power to the handpiece. Upon sensing position 3, phaco task 130 transits to either state 2.1 for linear/surgeon mode, or to state 2.2 for panel mode, ¹5 and sets either PULSE or CONTINUOUS mode as necessary. Execution continues in those states until footswitch position 3 is no longer sensed. Power out is set by a DAC channel.

Pulse rate may be changed by the user only when ²⁰ the footswitch is not depressed. In state 2.0, the pulse rate is continually updated by calling 'set_pls_rate( ) ' . This function sets the DAC channel assigned to pulse rate to a value interpreted by the Phaco Module processor to be between 1 and 15. The ^ equation used to set this value is:

DAC value - ( ( 2 * Pulse Rate) - 1 _ * 128 For pulse rates of 1 through 15, the DAC value will have a value in the range of 128 to 3712. The Phaco microcontroller (not shown) will perform the inverse of 30 this equation to acquire the pulse rate (1-15). ' a -

Actual Phaco power delivered to the handpiece is " available at one of the ADC channels. This value is always valid in CONTINUOUS mode. In PULSE mode, the Phaco Module provides a status bit which indicates if the current value is valid. Because PULSE mode uses a 50% duty cycle, average power delivered is the ADC value divided by 2. Actual power delivered is used for the display of accumulated energy (JOULES) and elapsed time. This process is performed by the functions 'get_phaco_pwr( ) ' and chk_time_energy( ) ' .

The Phaco actual power bar display 34 in Figure 4(a) does not represent actual power. Instead, this value ( 'phaco_act_val' ) represents the percentage of maximum power applied to the handpiece and is a function of a preset in Panel mode or a present AND the ^-5 footswitch displacement in linear mode.

Description of the cutter function

The cutter task 140 contains all functions that controlling the interface to the Cutter hardware and -^~ handpiece located in the I/A-Cutter Assembly (modules

40,50). Three (3) modes of operation are supported which reflect the direction of rotation of the cutting tip:

GUILLOTINE (CCW), ROTATING (CW) and OSCILLATING (reverse direction every 350 ms). As mentioned above, the user ²5 may select a preset value for cutting speed (cpm) for

GUILLOTINE and ROTARY modes. The preset value for the

OSCILLATING mode is fixed at 400 cpm.

Speed control is provided by a PID-type control algorithm that compares the actual speed versus the 30 desired speed in cuts-per-minute (CPM). Actual cutter speed is registered through two (2) 8254 counters (not

5 shown) which count at a fixed rate (1 kHz) during alternate rotations. This task controls and monitors these counters to obtain speed control to within ± 10% of the desired preset cpm value. A single DAC channel is used to output the desired cpm value dynamically to the Cutter module 40.

This task also monitors the connection of the handpiece 40' and will flag a warning to the user if the handpiece connection is faulty or lost during operation. Since it is imperative that the cutter handpiece be in

10 the homed (open) position whenever idle, the task 140 controls the proper homing of the handpiece upon release of the footswitch position 3. Cutter task 140 contains state-driven logic to drive and to stop the cutter in this open position. If correct homing is not achieved -' after three (3) successive attempts, this task flags a warning to indicate a failed handpiece.

As shown in the state diagram of Figure 23, cutter operation begins in state 1.0 where the 'cut_enable' flag indicates that the user selected p )

Vitrectomy. TASK_CUTTER confirms that a handpiece is connected and then proceeds to home the cutter shaft. It then waits in state 1.1 for 'footswitch.pos_3' to start cutter action.

Cutting modes ROTATING and GUILLOTINE are

~5 processed in state 1.2 (Figure 23) where speed is controlled by an algorithm. This algorithm is invoked at a fixed sample rate (CUTR_CTRL_SMP_RATE * 50ms) and calculates the speed error (preset - actual) and adds or subtracts an offset value from the preset to obtain a

3° 'corrected cpm' value to be output to the cutter speed DAC channel. The offset increases each pass of the

5 - S O -

algorithm and is range limited to preferably 0-400. Once the actual speed reaches a window of +/- 3% of the desired speed for (CUTR_CTRL_WINDOW_CNT) counts, a new preset multiplier is calculated and used for subsequent values output to the DAC. This multiplier is the ratio of corrected cpm value to desired cpm value and dynamically adjusts itself based on the current load conditions.

The OSCILLATING mode (state 1.6 in Figure 23) uses a preset speed of 400 CPM and cannot be adjusted by ι n the user. In this mode, the cutter shaft must reverse its direction every 350 ms (7 system timer interrupts). There is no speed control used in this mode.

Actual cutter speed is obtained through the use of (2) 8254 counters that count a fixed 1 kHz clock rate during each shaft rotation. Only one counter counts during any shaft rotation and the system timer ISR will read the 8254 counter device during each cutter shaft rotation to determine the cutter's actual speed. The other counter holds the count of the last rotation. Each counter counts-down from 32767. The number of kHz pulses counted during any shaft rotation is converted to C(R)PM and this value represents the actual speed used for display and speed control purposes.

If the cutter is in the oscillating mode, the ^s; cutter direction must be reversed every 350 ms. Therefore, if required, the timer ISR will effect this direction reversal every seven (7) interrupts.

The timer ISR is also responsible for reversing the direction of the Cutter rotation every 350 ms if the 0 cutter is in the OSCILLATING mode. This is flagged to the system timer ISR by 'sys_flags.cutr_osc' . If the

5 Cutter is operating in either the ROTARY or GUILLOTINE - mode, a flag will indicate that the Cutter actual speed must be read by the system timer ISR. This is flagged by cutter task 140 through 'sys_flags.mon_cutter_cpm' .

The ISR will respond by calling functions the task ~ process and provide some filtering of the values read from the cutter speed counters.

This process code for this task contains many short routines used to set cutter direction, speed, run or stop, as well as to check cutter status indicating ^^■ handpiece connection and index state.

Description of I/A task

The I/A task 150 is responsible for driving either the PERISTALTIC or ROTARY VANE I/A-Cutter modules

^ (40 and 50) in the system.

A system configuration requirement allows for a ROTARY VANE pumping system only with the modified footswitch 17. The peristaltic I/A pumping system is allowed with either footswitch type (modified or exisitng type).

Operation differs between I/A ONLY procedures, versus I/A operation in conjunction with Phaco and Cutter procedures, only when the existing type of footswitch is installed. Surgeon Mode (linear control) 5 of I/A is only available in I/A ONLY procedures with the existing footswitch installed. Phaco and Cutter procedures permit only Panel Mode I/A in order to reserve the linear range of the existing footswitch for control of Phaco or Cutter. 0 The I/A task 150 is also responsible for controlling solenoids for either pumping system. It controls four (4) solenoids in the ROTARY VANE - configuration: Reflux, Vent, Aspiration and Infusion. In the PERISTALTIC configuration, only three (3) solenoids must be driven: Vent/Reflux, Cassette Unlock and Infusion. Special timing is required in the ^" PERISTALTIC configuration when activating the

Vent/Reflux solenoid. This is accomplished by using one of the 8254 counters to provide a 17 ms delay after closing the infusion solenoid. The vent solenoid is then activated for 250 ms. - The user may select one of three (3) infusion modes during any procedure which uses I/A. These modes are Infusion OPEN, CLOSED and AUTO (activate/de-activate at footswitch position 1).

As mentioned above, the PERISTALTIC pumping ^ system involves controlling the flow rate of fluid away from the eye. This peristaltic action is part of a motor assembly whose speed is a function of the user selected Flow Rate preset which is assigned a DAC channel. A pressure (vacuum) transducer is continually ² monitored by this task to ensure that the developed vacuum does not exceed the vacuum preset value. The ROTARY VANE pumping system involves controlling the speed of a motor that directly develops a vacuum as fluid is drawn from the eye. Again, the ^ ^y pressure transducer is monitored by the IA task 150 to ensure that the developed vacuum does not exceed the preset vacuum value.

Each ROTARY VANE pumping system has its own response curve (vacuum vs. control voltage). A piece- 30 wise linear algorithm is used to achieve precise vacuum based on data points unique to each pump motor

35 3 3 -

installed. These data points are stored in the I/A PROM ^""^" (not shown) which is read at power-up by the I/A task 150. These points are used to generate an expanded (DAC value vs. desired vacuum) lookup table which is used to output the required analog voltage to the ROTARY VANE " pump.

The Rotary Vane proportional valve is used to control vacuum at levels below 100 mmHg. I/A task 150 will load a LUT with proportional valve values based on 2 data points contained in the serial number PROM. ⁰ I/A task 150 uses the flag

'sys_flags.cnf_rv_peri' to determine whether to drive the Rotary Vane (RV) or Peristaltic (PERI) pumping systems. (Functions are named 'rv_' or 'peri'_ that are unique to either system) . 5 The 'footswitch' structure variable signals all positions, linear displacement, and reflux switch states.

For the RV system, the DAC output value accesses the 'v_vs_p[]' lookup table to obtain the DAC value required to achieve the desired vacuum. (See 'rv_vacuum( ) ' . )

The RV system also requires a DAC output to the proportional valve (primarily used at low vacuum levels.) TASK_IA generates the required DAC value for 5 the proportional valve.

The PERI system requires a DAC output to drive the peristaltic pump motor to achieve the desired flow rate. This value is calculated directly as a function of flow preset and footswitch pedal displacement. ° As shown in Figures 24(a) - 24(f) the I/A_task supports both the Rotary Vane and Peristaltic pumping

5 -34

systems and is implemented as a state machine. An I/A procedure may be invoked by the user as a single procedure or as part of either vitrectomy or phacoemulsification. If I/A is the single procedure, this task will start the infusion/aspiration process at footswitch position 3. If I/A is utilized as part of either vitrectomy or phacoemulsification, infusion/aspiration starts at footswitch position 2. This task also supports all solenoid activity associated with the infusion/aspiration process. t

As shown in Figures 24(a) and 24(d), upon power- up, i/a task 150 (whether Rotary Vane or Peristaltic) initializes all solenoids to their inactive states (state 0). In state 1.0, indicated as state 151, this task waits for an I/A procedure to be selected by the 5 user. (sys_flags.ia_en) . When the user selects I/A, I/A_task 150 sets the module hardware enable signal, and if the infusion mode is OPEN, activates the infusion solenoid and continues in state 2.0, indicated as state 152. 0 In state 2.0, I/A task 150 looks for messages from control task 110 that requests Cassette load/unload. Priming 153. If no messages are received, I/A task looks for either the Reflux switch or position 1 from the status byte (states 7.3, 7.4 in Figure 24(a) and state 8.0 in Figure 24(d)).

As shown in Figures 24(a) and 24(d), further depression of the footswitch will cause I/A task 150 to cycle through states 3.0, 4.0 and 5.0. Upon closing the infusion solenoid, the vent solenoid will be activated 0 17 ms later, for a duration of 250 ms, as shown in Figures 24(e) and 24(f). This is accomplished by calls

5 ^• 35 -

to ' start_17ms_int( ) ' which sets up CTCO to interrupt in i ¹ 17 ms. The 'vent_isr()' function is the Interrupt service routine that opens the vent. State 6.0 senses the ISR event, starts a 250 ms timer, and state 7.0 releases the vent solenoid.

Description of fiber optics task

The Fiber Optic control task 160 is responsible for determining the integrity of both bulbs A and B upon power up and thereafter and contains the primary state

10 functions and support routines relevant for controlling and obtaining status from the Fiber Optics hardware module 60.

The fiber optic control process is structured as a state machine as shown in Figure 25. This process

- supports bulb selection, intensity setting and background diagnostics that check bulb integrity, switching bulbs if one of the two (2) bulbs fails. As described above, display icons reflect the status of the

Fiber Optic system. The task 160 is also responsible pn for switching between bulbs A and B upon user request or upon detecting a failed bulb. Intensity control is accomplished by outputting an analog voltage which controls the dilation of an iris. A DAC channel is assigned to this output control voltage.

²5 The Fiber Optic system is totally independent of any surgical procedure and may be activated at any time. As shown in Figure 25, upon power-up (state 0.0), fiber optics task 160 goes 'busy' until the shuttle is positioned at a known good bulb (A or B) . The default ° position is A; however, if a continuity check on A fails, bulb B is selected by the code. If bulb B is

5 - a d -

also fails continuity, the fiber optics task 160 goes to the error State 2.0 (Figure 25) and remains inactive.

When the Fiber Optic module is ready for use (One of the (2) bulbs is good, and the shuttle is positioned at that bulb), the task removes the 'busy' flag which indicates ^~ to control task that the task 160 has completed its multi-state power-up sequence.

The Fiber Optic hardware module provides status indicating bulb continuity. Additionally, status includes a photo-sensor output signal indicating that

TO the illuminated bulb is in fact ON. This status is continually read in the background to determine the integrity of each bulb.

Bulb selection is accomplished by either the user selecting A or B (fib_optics.sel_ab) , or by the task -^L- code determining that the current position bulb is bad, and the other is good, resulting in an automatic shuttle to the good bulb. In either case, switching bulb positions involves removing the module enable output which disables bulb illumination, selecting the bulb -° position, delaying for shuttle motion, deselecting both bulbs, re-enabling the module to obtain status, and finally, selecting the bulb to illuminate.

Bulb intensity control is accomplished by varying an iris. Iris control is an analog signal assigned to a -5 DAC channel. As shown at state 1.1 (for bulb A ) and state 3.1 (for bulb B) in Figure 25, the user may change intensity only while the Fiber Optics is ON.

The fiber optics task uses the data structure 'struct fib_opt_def fib_optics' to maintain relevant 30 flags and operational values. These include bulb status (.a_ok and .b_ok_) , error flag and code (.fo_err and

5 .err_code), bulb selection (.sel_ab) and intensity

1 ( .intensity) .

As mentioned above, as the Fiber Optic bulb's status changes, there are corresponding changes in the displayed Fiber Optic icons.

Description of warning task

The warning task 109 is responsible for processing all types of conditions that involve notifying the user (through pop-up warning display r- panels) of any system exception that may be detected in any of the various tasks. These range from fatal operating system errors to simply prompting the user to Continue or Cancel a Phaco handpiece test. The warning task is always running and handles only one condition at -' a time. All conditions detected and flagged to the user by displaying a 'warning' panel on the CRT display 19 which states the exception condition to the user, and, are accompanied by a short, two (2) tone audio burst. Once the condition is cleared, this task restores the

P display via a message to display task 119. All exception conditions are defined by type to accommodate differing degrees of severity and action to be taken.

As shown in Figure 26, the warning task is state driven as are all system 10 tasks. This task in its

^5 "normal" state scans an array of warning flags that are set by the respective "detecting" task. Specifically, when an exception is detected, the detecting task sets 'warn_flags[condition] ' to TRUE. When the exception condition is cleared, the detecting task must clear the

3° 'warn flags[]' element to FALSE.

5 The flags in 'warn_flags[ ] ' match a 'warn_tbl[]' structure which defines the attributes of the particular exception condition. These include type, user action push buttons, etc. (The 'warn_flags[ ] ' structure is previously defined, as is the 'warn_tbl[]' structure.) The warning task 109 accesses this table to determine how to process the condition. All warnings are previously "typed" to determine the action required by the warnings task in order to properly process the condition. This structure easily supports additional warnings at any time. The method by which the warning task 109 processes a particular warning "type" is by simply switching to another state and waiting for the "type" condition to be removed and normal system operation to resume accordingly.

Specifically, as shown in Figure 26, when in state 1.0, the warning task scans the 'warn_flags[ ] ' array, one element per RTOS (EXEC) pass. If a flag is set, the condition type is determined from the 'warn_tbl[ ] ' , and a message to display task 119 is sent to display the specific warning display panel for the user. In state 2.0, warning task 109 sends a message to audio task 111 to sound the two (2) tone alert burst, and execution resumes in either state 2.2 or 2.3.

Description of the audio task

The process code for the audio task 111 provides the primary state functions and the audio task state diagram is illustrated in Figure 27. As described briefly above, this task receives messages from the warning task 109 whenever a system exception condition exists and a warning message is displayed to the user. The message is accompanied by a two (2) tone burst

T ^ emanating from speaker 11 (Figure 2). This task is also responsible for sounding continuous tones at one (1) of four (4) pitches based on the current vacuum actual value (as a percentage of a preset value) and utilizes the 'sound(freg) ' and 'nosoundU' utility functions (provided by Borland's library routines). These functions, along with 'wake_me_up( _TMR_CNT, SEC_XX_XX, ...)', provide the timing of the tone bursts.

As shown in Figure 27, at state 2.2, if I/A is enabled, audio task 111 continually compares the actual vacuum value with the calculated percentage values of the vacuum present value. Tones begin to sound at 20% above the preset value. The tones then sound at different frequency for each of the remaining 20% ranges (20-40%, 40-60%, 60-80% and 80-100%). If the actual vacuum value exceeds the preset value, a four (4) tone burst sounds. This is followed ty a continuous tone for the maximum range. The volume for all audio output is fixed; however, the hardware supports variable volume through an assigned DAC channel.

Although shown and described in what we believed to be the most practical and preferred embodiments, it is apparent that departures from the specific methods and designs described and shown will suggest themselves to those skilled in the art and may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

WHAT IS CLAIMED IS: 1

1. An object oriented control system for use by a surgeon in ophthalmic surgery, said system comprising,

(a) a plurality of modules for controlling the ^r tasks of a plurality of micro-surgical instruments, each of said modules responsive to a data control signal to control the operation of its respective instrument,

(b) an electronic display system for displaying a plurality of sets of control parameters, each of said

^*"" modules having an associated set of control parameters to be displayed by said display system,

(c) a plurality of computer program objects, with each of said modules having a computer program object for implementing the tasks of the module, each task having one or more executable state functions and a control field,

(d) a surgeon controlled input device for entering control commands during surgery to control the operation of one or more instruments, ρo

(e) a computer control means for receiving said control commands from a surgeon and invoking one or more of said computer program objects, said control system periodically polling the control field of each computer program object to determine the status of each selected

^5 task and enable or disable the execution of said one or more state functions in accordance with the polled status to thereby generate data control signals to control the operation of said instruments.

2. An object oriented control system for

3° ophthalmic surgery as claimed in claim 1, wherein said display system further comprises an input means for

35 receiving predetermined operating parameters from a surgeon.

3. An object oriented control system for ophthalmic surgery as claimed in claim 2, wherein said control means receives said predetermined operating ^r parameters from said display input means and stores the same in the associated computer program object.

4. An object oriented control system for ophthalmic surgery as claimed in claim 3, wherein said display system provides a simultaneous visual display of a preset operating parameter for an instrument and an actual operating parameter for said instrument resulting from one or more control commands from said input device.

5. An object oriented control system for

^ ophthalmic surgery as claimed in claim 1 , wherein said input device is a surgeon controlled footswitch having at least one variable input control.

6. An object oriented control system for ophthalmic surgery as claimed in claim 3, wherein said 0 control means further selects one of said modules and its associated instrument and computer program object as an active task, and displays preset operating parameters and actual operating parameters relating thereto on said visual display. 5 7. An object oriented control system for ophthalmic surgery as claimed in claim 1, wherein said system further comprises an infusion/aspiration module having a variable speed vacuum pump for aspiration of fluids from an operating site. 0 8. An object oriented control system for ophthalmic surgery as claimed in claim 7, wherein the

5 computer program object associated with said

T

~ infusion/aspiration module includes at least one preset operating parameter.

9. An object oriented control system for ophthalmic surgery as claimed in claim 8, wherein the

^" speed of said variable speed pump is controlled by said computer program object in response to signals received from said input device.

10. An object oriented control system for ophthalmic surgery as claimed in claim 9, wherein said

T ) input device is a surgeon controlled footswitch having a variable input control for operating said variable speed pump.

11. An object oriented control system for ophthalmic surgery as claimed in claim 10, wherein said - control system further comprises a vacuum bleed port, and said associated computer program object regulates aspiration of fluids throughout a first range by varying the speed of said variable speed pump, and regulates aspiration of fluids throughout a second range with said

- vacuum bleed port.

12. An object oriented control system for ophthalmic surgery as claimed in claim 1, wherein said system further includes a phaco module for phacoemulsification, said module having a separate

-5 control processor for receiving data control signals from said control means.

13. An object oriented control system for ophthalmic surgery as claimed in claim 12, wherein said separate control processor further includes a program

3° control routine for determining the optimum frequency

5 for a phaco instrument when said instrument is connected to said control system.

14. An object oriented control system for ophthalmic surgery as claimed in claim 13, wherein said phaco module further includes a variable frequency

5 generator for sending a variable frequency signal to said instrument, and a detector circuit for detecting a resonant frequency for said instrument.

15. An object oriented control system for ophthalmic surgery as claimed in claim 12, wherein said visual display generates a display representative of the actual power supplied to said phaco module during operation thereof by a surgeon.

16. An object oriented control system for ophthalmic surgery as claimed in claim 15, wherein the

^±- computer program object associated with said phaco module includes at least one preset operating parameter.

17. An object oriented control system for ophthalmic surgery as claimed in claim 16, wherein said visual display further provides a simultaneous display

²^ of said preset operating parameter and the actual power supplied to the phaco instrument.

18. An object oriented control system for ophthalmic surgery as claimed in claim 2, wherein said visual display system further comprises a touch screen 5 as said input means.

19. An object oriented control system for ophthalmic surgery as claimed in claim 2, wherein said system further comprises a remote control device as said input means. 0 20. An object oriented control system for ophthalmic surgery as claimed in claim 19, wherein said

5 remote control device sends signals to said control system via a modulated infra-red beam.

21. An object oriented control system for ophthalmic surgery as claimed in claim 20, wherein said modulated infra-red beam is transmitted to said control system via a fiber optic cable.

22. An object oriented control system for ophthalmic surgery as claimed in claim 5, wherein said footswitch further includes a plurality of surgeon actuable switches for generating control commands for said control system.

23. An object oriented control system for ophthalmic surgery as claimed in claim 22, wherein said control system further invokes a plurality of program control objects, and assigns separate task controls to separate switches of said plurality of surgeon actuable switches in accordance with a surgeon preset assignment pattern.

24. A method of controlling a plurality of surgical instruments used by a surgeon during ophthalmic surgery, said method comprising,

(a) controlling the tasks of a plurality of related micro-surgical instruments with a plurality of sets of data control signals, each set controlling the operation of an associated instrument,

(b) generating a plurality of computer program objects, with each of said instruments having an associated computer program object for implementing the tasks of the instrument, each task having one or more executable state functions and a control field having status bits for each task. (c) entering control commands during surgery

T

' from an input means, said control commands indicative of a desired operation of one or more instruments,

(d) receiving said control commands from said input means and invoking one or more of said computer

' program objects,

(e) periodically polling the control field of each computer program object to determine the status of each selected task and enable or disable the execution of said one or more state functions in accordance with

T f-

-~ the polled status to thereby generate data control signals to control the operation of said instrument,

(f) displaying a set of parameters associated with said instrument, each set having at least a preset parameter and an actual parameter representative of the

^" present state of the instrument.

25. The method of controlling a plurality of surgical instruments as claimed in Claim 24 wherein prior to step (c), said method further comprises the step of entering control commands from said input means, said control commands indicative of predetermined operating parameters.

26. The method of controlling a plurality of surgical instruments as claimed in Claim 25 wherein said method further includes the step of receiving said

²5 predetermined operating parameters from said input means and storing the same in the associated computer program object.

27. The method of controlling a plurality of surgical instruments as claimed in Claim 25 wherein said ° input means includes first and second input means and said method further includes the steps of entering a

5 plurality of predefined control parameters from said "^■" first input means, and entering real time control commands from said second input means.

28. The method of controlling a plurality of surgical instruments as claimed in Claim 27 wherein said

^D second input means generates a variable control signal, and said control system varies the real time control commands for one or more instuments in response to said variable control signal.

29. A system for use by surgeons in ophthalmic

]1 . . . surgery, said system comprising;

(a) an infusion/aspiration module having a variable speed rotary vane pump for generating a variable pressure in an aspiration line in response to a variable control signal from said module, -' (b) a phaco module for generating a variable electrical signal for driving a phaco instrument for ophthalmic surgery;

(c) a programmable footswitch having a pivotable pedal thereon for generating a variable control signal;

^C (d) an input/output display system for receiving input control commands and for displaying real time operating parameters;

(e) an object oriented control system for coupling a plurality of modules of the system for

^5 ophthalmic surgery, said control system having a separate computer program object for each module to implement tasks assigned to the associated module, said control system responsive to input control commands from said input/output display system to invoke one or more

3° computer program objects and responsive to variable

35 control signals from said footswitch to vary one or mere real time operating parameters.

30. A system for use by surgeons in ophthalmic surgery, as claimed in claim 29 wherein said infusion/aspiration module further includes a variable bleed valve and a module control means, said module control means generating one or more variable electronic signals to alter either the speed of said rotary vane pump or the operation of said variable bleed valve to vary the pressure in said aspiration line.

T .-.

31. A system for use by surgeons in ophthalmic surgery as claimed in claim 29, wherein said system further comprises a cutting module for generating a variable electronic signal to drive a cutting handpiece.

32. A system for use by surgeons in ophthalmic 5 surgery as claimed in claim 29, wherein said system further comprises a bi-polar cauterization module for generating a variable electronic signal to drive a cauterization handpiece.

33. A system for use by surgeons in ophthalmic surgery as claimed in claim 32, wherein said control system varies a data signal supplied to one or more modules in response to said variable control signal received from said footswitch.

34. A system for use by surgeons in ophthalmic 5 surgery as claimed in claim 33, wherein one or more of said modules vary an electronic signal generated by the module in response to said data signal.

35. A system for use by surgeons in ophthalmic surgery as claimed in claim 34, wherein two of said 0 modules simultaneously vary their respective electronic signals in response to said data signals from said control means.

36. A system for use by surgeons in ophthalmic surgery as claimed in claim 35, wherein said control system further varies data signals generated by it in

- response to an angular orientation of said pivotable footswitch as a function of predetermined data parameters entered by a surgeon on said input/output display means.

37. An object oriented control system for a

T f) phacoemulsification device used by a surgeon in ophthalmic surgery, said system comprising,

(a) a phacoemulsification module for controlling a task of said phacoemulsification device, said module responsive to a data control signal to control the

^" operation of said device;

(b) an electronic display system for displaying a plurality of control parameters for said device, said electronic display system including an input means for receiving said predetermined operating parameters from a

20 surgeon;

(c) one or more computer program objects, said phacoemulsification module having a computer program object for implementing a task of said device, said task having executable one or more executable state functions

P

'--' and a control field having status bits for each task,

(d) a surgeon controlled footswitch device for entering control commands during surgery to control the operation of said phacoemulsification device;

(e) a computer control means for receiving said 30 control commands from a surgeon and invoking one or more of said computer program objects, said control system

35 periodically polling the control field of each computer

T program object to determine the status of each selected task and enable or disable the execution of said one or more state functions in accordance with the polled status to thereby generate data control signals to "^■ control the operation of said phacoemulsification device.

38. An object oriented control system for a phacoemulsification device as claimed in claim 37, wherein said control means receives said predetermined operating parameters from said display input means and stores the same in the associated computer program object.

39. An object oriented control system for a phacoemulsification device as claimed in claim 38, l^ς^ wherein said phacoemulsification device draws power from said module.

40. An object oriented control system for a phacoemulsification device as claimed in claim 39, wherein said predetermined operating parameters includes O

^" a value representing power to be supplied by said module to operate said device.

41. An object oriented control system for a phacoemulsification device as claimed in claim 39, wherein said power is supplied to said device in a

-^ variety of waveforms.

42. An object oriented control system for a phacoemulsification device as claimed in claim 41, wherein said device operates in a pulse mode, at least one of said variety of waveforms is a pulse signal.

3°

43. An object oriented control system for a phacoemulsification device as claimed in claim 42,

5 - 1 J 0 -

wherein said said predetermined operating parameters ~ includes a value representing the duty cycle of power to be supplied by said module when providing power to said device in said pulse mode.

44. An object oriented control system for a ^" phacoemulsification device as claimed in claim 39, wherein said display system provides a simultaneous visual display of a preset operating parameter for said device and an actual operating parameter for said device resulting from one or more control commands from said input device.

45. An object oriented control system for a phacoemulsification device as claimed in claim 40, wherein said visual display generates a display representative of the actual power supplied by said phaco module to said phaco device during operation thereof by a surgeon.

46. An object oriented control system for a phacoemulsification device as claimed in claim 45, wherein said visual display further provides a simultaneous display of said preset operating parameter and the actual power supplied to the phaco device.

47. An object oriented control system for a phacoemulsification device as claimed in claim 37, wherein said phaco module includes a separate control processor for receiving data control signals from said control means.

48. An object oriented control system for a phacoemulsification device as claimed in claim 47, wherein said separate control processor further includes a program control routine for determining the optimum ^■ i i. ^■

frequency for said phaco device when said device is

^•- connected to said control system.

49. An object oriented control system for a phacoemulsification device as claimed in claim 48, wherein said phaco module further includes a variable

⁷ frequency generator for sending a variable frequency signal to said device, and a detector circuit for detecting a resonant frequency for said device.

50. An object oriented control system for a phacoemulsification device as claimed in claim 40,

-° wherein said phaco module generates a display representative of the total amount of energy supplied to said instrument during operation thereof by a surgeon.

51. An object oriented control system for a phacoemulsification device as claimed in claim 40,

---' wherein said phaco module generates a display representative of the elapsed time said instrument is in use by said surgeon.

5

0

5