Introduction

The rotating oven at the mirror lab, has it's rotation controlled by an 8751 microcontroller, fondly known as the rotation computer. This little gem communicates with the VME oven computers via a serial link.

This little note is just the start of documentation for this project.

Hardware Overview

As mentioned, the rotation computer is based on the 8751 microcontroller. The computer itself fits on a single 3U sized eurocard. Prior to its design in this form, it was implemented as a CMOS Z80 chip (the NSC800), which was programmed in assembly language. Many aspects (some would say, too many) of the project trace themselves to this previous design.

Lights and errors

There are 4 status lights on the front panel, allowing 16 possible conditions to be reported to the curious onlooker. The codes are as follows: $ signifies the lamp is illuminated.

$ $ $ $ Trimming, speed right on!
$ . $ . Ramping (changing speed).
$ . . . Speed commanded to 0 from cpu.
. . . $ No speed command from cpu (yet?).
$ $ $ . Trimming down.
. $ $ $ Trimming up.
$ $ . . Cannot trim, last meas > target.
. . $ $ Cannot trim, last meas < target.
. $ . . Trimming at upper limit.
. . $ . Trimming at lower limit.
$ . . $ Speed error, penultimate limit.

The meanings of these codes should be clear. :-)

Error Reporting

In response to queries over the serial port, this computer responds with the current tachometer reading, scaled as RPM * 1000. RPM command values greater than 10.0 are not allowed. An error condition is flagged by adding an offset of 30000 to the reported tach reading. Errors are under on the following circumstances. The presence of an error is indicated by 30000 being added to the reported speed. The nature of the error must be determined by looking at the status lights on the front panel of the rotation computer (this may involve an exciting ride on the rotating oven).

Tach count zero when motion is expected. (encoder failure).
Tach count greater than 10000. (encoder failure).
DAC command less than lower limit. (dac lower limit).
DAC command greater than upper limit. (dac upper limit).

The upper and lower limits are somewhat nebulous things (actually they are rigorously defined in the software). The upper limit is given by the commanded speed + 10 percent. The lower limit is given by the commanded speed - 10 percent. This is a bit more complex during ramping in which case the limits are 10 percent on either side of the current are previous commanded speed.

The careful reader has noticed that we are defining the DAC limits in rpm units. This is as it should be -- the software deals with the command value to the DAC as rpm units internally, adjusting the commanded rpm as necessary to control the speed. The DAC itself is a 12-bit entity, allowing a range of values from 0-4095. The mapping from millirpm units to DAC integers is as follows:

If the commanded rpm value is less than 2.0, dac = rpm * 2/7;
If the commanded rpm value is greater than 2.0, dac = rpm * 2/9;

All of this looks suspect to me. Should this 2.0 really be 2.0 rpm, or is it in millirpm units (which is how it is currently being treated). Also notice that there is a discontinuity at this 2.0 point, which can hardly be correct. In actuality the rule being used is simply that the dac command is rpm * 2/9. The bump at 2 doesn't matter since we need to get 5 millirpm units before we command 5*2/9 = 1 dac unit. Also notice that at 10000 millirpm, we are setting the DAC to 2222, so we are only using half of the DAC range.

In any event, this coding carefully preserves the original CIM coding with all its warts and pimples, and has managed to produce a number of fine mirrors.