return to main page

Continuing Maintenance

Table of Contents
- Introduction
- "Up-Time" improvements
- Storage of Tools & Parts
- Various Adventures
- Carl Claunch's "State of the 1401 Data Center" series


Frank King & Joe Prescot, June 2014
The 1401 machines were being informally demoed in 2009. However, the museum was occupied designing and creating R|EVOLUTION from the contents of old Visible Storage and othere resouorces. The unit record and 1401s have been basically in maintenance mode ever since.

Restoration is long over, maintenance mode continues. Unfortunately, the old hardware is not as reliable as it was 50 years ago :-(( There is a higher than expected card failure, and the relays and rollers in the 1402 reader/punch continue to cause machine outages at an unexpectedly high rate and longer mean time to repair.

"Up-Time" improvements
Two tasks have been started to improve "up-time".
- Aided Circuit Card Testing
- Aided Relay Testing
I'm using the word "Aided" to help avoid unrealistic expectations.

Aided Circuit Card Testing
Actually, Grant Saviers started designing and drumming up support for an SMS card tester system since about Spring 2005 when we finally got adequate 50 Hz power. Support was slow in coming.
  1. - cards were being adequately repaired by Tim Coslett
  2. - many people (especially Ed Thelen - me - ) remembered many cards being shipped to sites as "repaired" or "no problem found" that were defective. These people wished a "perfect" card tester, including verifying voltage tolerances, ability to drive rated loads, perform at rated speed, functional temperature range and maybe even vibration sensitivity.
So Grant continued designing with little moral support. Likely he figured that good, but not perfect, was better than nothing at all -

Then Tim Coslett moved to Montana, and Jim Hunt took over fixing SMS cards.
Then Jim got a day job and was not available.

So, in 2014 George Ahern linked up with Grant Saviers and started fabricating Grant's designs.
See Towards Fixing SMS

Aided Relay Testing
The 1402 card reader/punch is a wonderful machine, when new and/or working. Our machines have been run for many years, and the rollers aren't what they used to be. In addition, the plentiful relays are tough to test.

So several approaches are being developed

a "relay extender" analogous to a card extender

a microprocessor based relay tester

Relay Read Out Lamps

Storage of Tools & Parts
The previous single work and demo room have been superceeded by
  • The Demo Room with audio/visual closet
  • The adjacent room with Leibert cooling, 50 Hz power, Main Switches, and storage
  • A separate work and storage room near the loading dock.

Various Adventures
Ken - Tape Drive Intermittent Aug 14, 2019
- Ken - Card Reader Clutch Sept 25, 2019
- Ken - Card Reader Clutch Sep 18, 2019
- Ken - Card Reader Clutch Aug 7, 2019
- Ken - Card Reader Clutch Sept 25, 2019

Ken - Tape Drive Intermittent Aug 14, 2019
Subject: (Unofficial) report on Wednesday's restoration
From: Ken Shirriff
Date: Wed, Aug 14, 2019 6:07 pm
The tape drives on DE had an intermittent problem when running the exerciser test. Michael was looking into it and can provide more details. I scoped the signals from the tape drive and found that the C bit signal from tape drive on the left looked very bad, but all the rest of the bits from all the tape drives were fine. Yellow is the bad signal below:
As far as we can tell, this is unrelated to the exerciser error. But this should probably be investigated. Maybe a bad preamp card in the tape drive? I ran out of time to investigate.

The second problem turned up just before I left. The CT card reader partially fed one card, went into reader stop, and wouldn't do a NPRO. Turning the computer off and on cleared the reader stop, but it came back after trying NPRO again. It seems pretty unusual for NPRO to not work at all.


Ken - Card Reader Clutch Sept 25, 2019
Subject: Re: Notes on 1402 card reader clutch problem
From: Ken Shirriff
Date: Wed, September 25, 2019 8:37 pm
Another update on the CT card reader problems.

Today we had different symptoms. First, Carl ran powers-of-2 and the card reader operated perfectly. I attached an oscilloscope probe (carefully) to see the brush timing, and then the card reader started malfunctioning. Each time I tried to load, a card would move to the first position (halfway out of the hopper) and then hit a Reader Check. I.e. before it had reached any brushes. I had to hit Check Reset on the 1401 a couple of times to clear the fault, which was strange. This problem happened many times and we couldn't make it go away, even with power-cycling. Carl looked at some relays, but I'll let him describe what he found.

Then, the problem suddenly reverted to the original intermittent problem, where the card reader would fail to clutch at all and no cards would move. This problem persisted until we had to leave because of the demo.

Details on the clutch problem: I started scoping INLK STOP (C12, continuing from last week. Last time, it seemed that INLK STOP wasn't getting cleared by the reset key, but this time it did. There's a pulse from the Load key (pin F), clearing output P. So this seems to rule out the INLK STOP theory from last week.

We moved on to READ FEED ( and confirmed that it's getting INLK STOP correctly. We started to look at the PROC FEED signal (pin A) which provides the pulses to the READ FEED trigger. These seemed to be missing, which would cause the problem. We also looked at the PROC FEED signal output from the integrator (C08 pin F) and that seemed stuck too. So our current hypothesis is the PROC FEED signal from the 1402 is not correct.

The CE Manual has a good discussion of the various relays and their sequences, starting at page 4-1. In particular, PROC FEED depends on relays RC5, R7-2T, R6-3N, R11-3N and R11-2N, so that path would be worth checking.

For some background, here's my blog post from a year ago when the DE 1402 had Reader Check on NPRO, due to a bad relay #4. (The current problem appears unrelated, but my blog post discusses some Reader Check circuitry.)


Ken - Card Reader Clutch Sep 18, 2019
Subject: Re: Notes on 1402 card reader clutch problem
From: Ken Shirriff
Date: Wed, Sep 18, 2019 6:48 pm
The intermittent problem with the CT card reader failing to clutch showed up again today. Carl and I did some debugging but didn't come up with anything conclusive. It seems like the INLK STOP trigger is stuck high, which blocks the READ FEED trigger from generating the clutch signal. INLK STOP should be cleared by the load key, but apparently it isn't. We don't have a root cause. The problem is intermittent and went away when we turned the 1401 off and on.

We started with the read feed trigger ( It's supposed to generate the read clutch signal on E, but nothing showed up. The problem appears to be the signal on B doesn't go high. (Carl found a weird voltage level of 2.5V on input F but that happens when the reader is working too. The PROC FEED signal from the 1402 showed up on A, but the signal on B was missing.)

We looked at the gate generating the B input. This gate will output 0 if all inputs are negative and -12 otherwise:

In the bad state, the inputs were (A) positive, (B) negative, (C) negative, and the output was negative.
In the good state, the inputs were (A) positive -> negative, (B) positive -> negative, (C) negative, and the output was negative -> 0. (Transitioning when the load started.)

Input A comes from the INLK STOP trigger output P(

When things are working, INLK STOP looks like this:

The bottom trace is NOT GATED LOAD KEY (into F); a pulse there triggers the output E (top, yellow) to fall. So INLK STOP responds to the load key, when things are working. But when things are bad, INLK STOP seems to be stuck.

The second difference was the B input to the gate. This comes from NOT READ SCAN COMP ( from the READ COMP trigger. We didn't have time to investigate this trigger.

Interlock stop is on ILD page 88:

If the problem shows up again, we'll do more investigation to verify if INLK STOP is indeed the problem and why it's not getting cleared on a load.


Ken - Card Reader Clutch Aug 7, 2019
On Wed, Aug 7, 2019 at 9:09 PM Ken Shirriff wrote:
The CT card reader has an intermittent problem where the clutch doesn't activate on Load, so no cards get read. I did some measurements today to see what the signals look like when it is working correctly.

On the card reader side, the schematic shows RC171 -T PROC FEED goes to the 1401, which then returns the RC 170 -T READ CLUTCH signal to activate the read clutch magnet and feed the card. Note that this signal goes through cam RC 5.

When things are working, the signals look like this:

The yellow load signal indicates when the Load button is pressed. The cyan -T Process Feed signal goes from the 1402 to the 1401. It triggers the purple -T Read Clutch signal from the 1401 to the 1402, to trigger the clutch and read a card.

This trace seemingly makes no sense because the clutch signal is before the feed signal that triggers it. The cause is that one side of the read clutch magnet is connected to this signal, and the other side is connected to cam RC 5. So as RC 5 opens and closes, the line swings up and down. Thus, you see pulses in the Clutch signal even though these are not genuine pulses and have no effect on the clutch. (Note that the pulses speed up as the motor starts up.) If there's one thing to remember from this message for future debugging, it's that the Clutch signal has these "fake" pulses in it.

Ignoring the RC 5 pulses, you can see four feed pulses from the 1402 causing four clutch pulses from the 1401 to the 1402. There are four clutch cycles because I read two cards; it takes 3 cycles to read the first card.

Now let's look at the 1401 side. shows the READ FEED trigger that generates the READ CLUTCH signal. A is the set pulse input, and B enables the set input. G is an asynchronous set. C is the reset pulse input and D enables the reset pulse. F is an asynchronous reset.

The signals look like:

Note that B goes high and A pulses to trigger the clutch feed. B is an And/Or of interlocks and FEED RELEASE CLUTCH. A is the -T PROC FEED from the 1402 (i.e. the bottom signal), Or'd with -T CF OPR. When the clutch isn't triggered, my theory is there is something wrong with A or B.

On the reset side, C is GATED READ SCAN (the circuit breaker signal for reading a row) and D is TIME 000-030 (i.e. the clock). F is And/Or of various signals. As far as I can tell, F is inactive, and the row circuit breaker C resets the clutch.

To wrap up, this shows what the clutch signals look like when things are working. If the clutch problem shows up again, hopefully this will help debug the problem.


Page start July 7, 2014
Updated Oct 11, 2019