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
This little note is just the start of documentation for this
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
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.
The meanings of these codes should be clear. :-)
- $ $ $ $ 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.
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).
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.
- 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 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:
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.
- 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;
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.