Back to Home Page
Do No Harm
Museum workers (and volunteers) frequently handle or work on artifacts of considerable rarity or even one of a kind or the last of its kind.
A goal of Computer History Museum is to "preserve and present artifacts of the computing age" - for say at least 500 years -
Clearly, special care is required.
Each major restoration presents a plan to implement this "preserve" goal.
from John Best, Sept 30, 2011
Actually, part of the whole restoration story is how little stress we did put on the thing while testing the controller. I was so paranoid about damaging the machine that we put multiple levels of protection in both the hardware and software to prevent damage (in addition to the mechanical interlocks that are inherent in the original design).
The clutch driver outputs are fused at a low enough current so that the clutch coils canít be fried even if the driver shorts or the software goes nuts. These fuses did blow several times during development, until we understood what was glitching the outputs on shutdown.
The hardware logic for the clutch control shuts off clutch power if the disk to disk seek limit switches are closed. It also prevents loading the head if the detents are not in a reasonable state. The first of these has never been triggered and the second isnít needed because we donít load the heads during operation.
The software is full of checks and timeouts so that it shuts off the power to the actuator if it even suspects that the servo is going out of control. When it fails to finish a seek properly, it is always one of these safeguards being tripped that causes it to abort, not the servo actually going out of control.
The exception to this was when the set screw on the bellows connecting the tachometer to the actuator drive shaft was loose. The bad tachometer feedback drove the servo system nuts. This was the only time that we got it to buzz with an oscillation. The safety code kicked in and it shut itself down before it ever got very violent, so it didnít get close to causing any damage.
Very early on, I did manage to hit the track seek crash stop reasonably hard exactly twice. In both times, the power to the clutches got automatically shut off by the software long before the carriage hit the end of travel, so it didnít even come close to damaging anything. I canít remember why it did this.
What is amazing is that the servo feedback interrupt routine pretty much worked correctly the first time we tried it on the machine. It needed lots of tuning, but it never did anything bad. Of course, it took me 6 months to write about 200 lines of code, so it should have been pretty correct. I was paranoid about messing up the integer arithmetic and getting overflow conditions, so wrote the same code in Matlab for the PC and then passed a bunch of test cases to both the Matlab code and the running code on the controller (without the clutches powered) to verify that both returned exactly the same numbers. We spent several weeks testing by capturing position and velocity data and running it through the servo estimator algorithms while only open loop pulsing the actuator. This also verified that the algorithms were working right and that sensor noise would not be a problem.
We are still learning new things. A little oil three weeks ago in places we had never lubricated before solved the biggest remaining cause of failed seeks. I donít think we had a single error while running for about an hour this last Wednesday. We had put some test routines into the code to time the motion of the switches detecting all of the pneumatically actuated detents. These enabled us to nail down the cause of sticking track detents. We now run those timing tests every week to make sure things donít drift around. Before solving the problem, we also added to addition tweaks to the code that reduces the thermal stress on the track detent pistons and the pneumatic valves. That also seems to help.