Continuing Maintenance

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 36.02.11.2), 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 (36.10.11.2) 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

We started with the read feed trigger (36.10.11.2). 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:

Inputs are A: NOT INLK STOP, B: NOT READ SCAN COMP, C: PR INLK RD.
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(36.02.11.2):

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 (36.01.31.2) 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

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. 36.10.11.2 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.

Ken