Advertisement

Blog

Case Study: Medical Laser System; Part 1: Stabilizing a Laser Feedback Control Loop

This is a case study of an actual engineering project in the Irvine Spectrum area of southern California, a 2-mile strip of land in south Irvine with a high density of medical instrument companies. A medical laser company was having some technical problems with their NdYAG (neodymium yttrium aluminum garnet) laser development. This is a laser that can output 5 W of optical power. Protective goggles are worn when working around these lasers. Over a kilowatt of electrical power was required to operate the laser, and with the electrical-to-optical conversion inefficiency, the thermal design was substantial, with heat exchangers and a water cooling system.

Upon arrival, I immediately encountered various consultants working on different parts of the system. (I was brought down through the laser developer in Vancouver, WA.) Two digital engineering partners were doing the microcomputer hardware. It contained three microcontrollers, each a commercial single board product. One controller ran the main functions and commanded the other two. One was the user interface and the third controlled the laser system. The interfaces between the slave controllers and the main one were via serial ports, run through RS-485 interfaces on a motherboard. At power-on, the system would sometimes become catatonic; the user interface would be unresponsive. The software engineers could not find any clues to the malfunction in their programming. The hardware design partners would repeatedly test each of the controller boards and they performed flawlessly. By swapping in different controller units, the behavior would change, but the starting problem did not go away.

The fact that power-on behavior was not repeatable was the key clue. Each of the controllers worked correctly and each had their own power-on, power-off circuitry. However, the controller power-on reset timing had some variability among controller units. This is unavoidable and normally it is not a problem if a controller takes t versus t + Δt μs to negate the reset waveform to the controller after the power-on threshold has been crossed by VDD . This variability will mainly be caused by the varying threshold voltage values in the controllers.

In this case, it was essential that the main controller not start sending commands to the slave controllers before they were properly initialized and ready for commands. By placing a start-up delay in the main controller, variations in reset times among the controllers would be accounted for by making this delay long enough to ensure that the slave controllers were always ready and waiting for a serial-port command string. The software delay quickly solved the problem after the hardware designers had been wrestling with it for some time. I chuckled to myself when one of the partners grinned as he said to me: “Beginner's luck.” I was new to the project.

In the medical NdYAG laser, the laser flashlamp currents were commanded to control the output power of the laser. The system-level loop is shown below, scanned from my project notebook.

Feedback was accomplished by using a dichroic mirror. Most of the power reflected from the mirror into the output optical path, but a small, fixed fraction went through the mirror. This was sensed by a photodiode and amplified by a photodiode amplifier (PDA). The problem that arose was that of maintaining a stable feedback loop over the power range of the laser. At low power, the accuracy was lacking but if the loop gain was increased, then at high power, feedback-loop instability resulted.

The key to the problem was in characterizing each of the functional blocks in the feedback loop. One of these was the flashlamp-laser combination. Upon examination, it was found to have a nonlinear light output as a function of current. The transfer function was parabolic (“square-law”), as shown below from data taken on a prototype unit for two commanded levels of output power. The loop-gain increased superlinearly with flashlamp current and laser output power.

To fix this problem of varying loop gain with power setting, a square-root circuit was introduced in the loop, in the forward path after the error amplifier. The (slightly) simplified circuit is shown below.

By introducing a function that was the inverse of the flashlamp-laser transfer function, the loop gain became relatively constant over the dynamic power range of the laser, with similar loop-gain error and stability margins over the power range.

The square-root circuit is based on the translinear principle discovered by Barrie Gilbert. A CA3086 IC of 5 matched NPN BJTs was used to implement it, as shown. The basic equations of its operation are as follows, where subscripts correspond to CA3086 pin numbers.

The coefficient of 2 follows from having two p-n junctions in series – the b-e ¬ junctions of BJTs with base pin numbers 4 and 6. Then reducing the equation,

When simplified, and for matched junctions with the same values of IS , this leads to

As a voltage amplifier, vI = iI x Ri and vO = Rf x iO . Substituting, the voltage gain of the square-root circuit is

***

After the previous (and other) problems were solved, the laser was showing drift in output power. The drift was causing the laser to be somewhat “out of spec” (that is, not within the specification) and hard to characterize. Worse yet, it seemed rather random. Each functional block in the optoelectronic feedback loop was scrutinized in some detail, especially the feedback photodiode and its amplifier in the feedback path.

This problem was not solved during my involvement in this project but the cause of it was almost certainly identified. It was not electronic but optical. The dichroic mirror used to pick off a small fraction of the output light for the photodiode had a different transmittance through the mirror depending upon the polarization of the light. This ordinarily would not be a problem with a stable light source of fixed polarization. However, in discussion with the laser consultant it was determined that a NdYAG laser can oscillate in various modes, similar to the modes in a microwave waveguide. Furthermore, which mode of oscillation actually occurred was determined chaotically (as in mathematical chaos) and was a highly nonlinear phenomenon. The different modes had different output polarizations. No amount of electronic compensation would have been of help.

This is the kind of problem that design engineers most want to avoid: a problem in which an element of the system will not perform satisfactorily for a fundamental reason and for which there is no practical method of compensation for its limitations. I do not know what course of action the company took in response to this problem. Perhaps the specs were changed to allow for the power variations. The lesson to be learned from this problem is: be sure you understand well the critical elements of your system before embarking upon a product design that uses them.

2 comments on “Case Study: Medical Laser System; Part 1: Stabilizing a Laser Feedback Control Loop

  1. HughVartanian
    November 8, 2017

    Interesting story, Dennis, thank you.  It would be interesting to know the control loop bandwidth.  Clever solution to the non-linear power input->laser output relationship, to use the square-root circuit.  Might have been easier to run the loop in a processor and deal with this digitally, but it is an analog column after all!

    What I know about laser oscillation modes and polarization is nearly zero.  However, I was thinking that if the laser was simply switching between vertical and horizontal (polarization) modes, and the tilted partial reflection mirror was fixed and not able to follow the polarization (of course), that perhaps 2 tilted mirrors 90 deg to each other (in rotation about the long axis of the beam) each with their own detector might solve the feedback problem.  The vector sum of the outputs of 2 sensors would then be insensitive to the V/H polarization.  Of course of the beam patterns are more complex, this idea quickly falls apart.

    To the beginner's luck part of your story, with the simple delay in the master's startup fixing the random startup problem, some thoughts:  1) a serial communication scheme, particularly in a medical device controlling a laser, one thinks there ought to have been timeout/retry algorithms in place.  2) I once consulted at a place where the microcontroller systems had what was called “Crazy Ivan” behaviors where the systems would periodically go stupid and need to be rebooted.  This was accepted as a normal course of events, even though the behavior would regularly kill 3-day long experiments.  One day my sidekick, another old guy with beginners luck, was working on the code and noticed that variables in the code that were messed with in interrupt routines were not bracketed with disable/enable interrupt instructions.  It is not how easy we make the hard problems but how hard we make the easy ones!

    -Hugh

  2. D Feucht
    November 27, 2017

    Hugh,

    The loop bandwidth was less than 100 Hz, so a processor in the feedback loop could have made the adjustment. But this was in the early 1990s when the processors in use in the medical instrument were 8-bit and 5 MHz. I trust the analog circuit more than a uC and its software in this case. The square-root circuit was low-cost because an op-amp used in another package was used. (I try very hard to use all the multiple parts in such packages instead of wasting them. I didn't quite accomplish that with the BJT array.)

    Your idea to use “2 tilted mirrors 90 deg to each other” is a good one, but even with one mirror, the amount of light that got through (for either polarization) was small and to decrease it by x 1.414 would not have been received favorably for design. However, if it solved the problem, it would have been worth considering.

    The uC starting problem should have been solved by either the software or hardware engineers, but it wasn't. Actually, the uC comm links were RS-232 and one of the extra command lines indicating “acknowledged” should have been used to speed up the initialization. I was too busy trying to figure out the entire system than to bother the others with that solution!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.