Playing with Motors

Electric Motors; image purchased from stockfresh.com
Electric Motors; image purchased from stockfresh.com

Computers can move things? Wow, this was going to be a fun summer! These thoughts crossed my mind as I began a summer job with the National Bureau of Standards in 1982.

My introduction to computer languages came in high school when I took a class on BASIC. Mr. Chapman, a math teacher, had acquired several TRS-80’s for the school and offered a class. We created loops to do calculations, sorted a list of numbers and coded other introductory programs. In college I typed up FORTRAN IV and then FORTRAN 77 programs on a key punch machine and prayed that I didn’t make a typo! We primarily programmed algorithms to compute things. Now I was going to program algorithms to MOVE things.

As a summer intern I had an opportunity to program motors controlling parts of an ellipsometer measurement

Ellipsometer Auto angle source, image from jawollam.com
Ellipsometer Auto angle source, image from jawollam.com

system. Ellipsometry enables measurements of dielectric properties of thin films. I worked with the scientists, Dean and George, who had been assigned a project to build one. They had all the components on an optics grade table. Such a table prevents vibrations from disturbing the instruments set up on the table. At one end of the table a metal holder aimed a laser at a specific angle at a sample at the other end of the table. Prior to hitting the sample, the light went through a polarizer. The light bounced off the sample and passed through another polarizer prior to hitting a detector. The motors controlled the angle of the polarizers.

Having only programmed computations, I had fun making things move. The DEC VAX-11 computer had electronic cards installed that enabled communication to the motor, which controlled the polarizer position and to the detector to query its state. I used specific commands that the cards would translate into movement of the motors. To make the fundamental ellipsometer measurement, a null state needed to be found, which meant that no light would be detected. Hence, the program needed to search for the null state. One could take a brute force approach and start at position zero and work towards 360 degrees, one degree at a time. I vaguely recall that I used this approach first to learn about the whole process. During my course work in computer programming I had learned about binary searches. While typically prescribed for finding a value in a sorted array, this approach made sense for finding the null polarizer angle value. The search looked like this:

  1. Move the polarizer to 180 degrees. Check detector.
    1. Null–stop
    2. Less than Null–move to 270 degrees
    3. More than Null–move to 90 degrees
  2. Let’s assume c occurs, move the polarizer to 90 degrees. Check detector
    1. Null–stop
    2. Less than Null–move to 135 degrees
    3. More than Null–move to 45 degrees

The computer program implemented the above algorithm until the null condition was found to the required precision, i.e. the smallest degree value. I recall creating subroutines to make the detector readings and to move the motors a prescribed value. While it has been decades since this work experience, I remember two things: the fun of making something move, and the exploration of algorithms.

Have a productive day,

Anne Meixner

Dear Reader–what memory or question does this piece spark in you? Have you found using your training in a different application? Have you had to implement a search algorithm? Please share your comments or stories below. You, too, can write for the Engineers’ Daughter- See Contribute for more Information.

Leave a Reply

Your email address will not be published. Required fields are marked *