We ran the demo on DE. Other than a couple of Reader Checks and Reader Stops on the DE1402, the hardware ran fine.

After the demo, we tried running on CT. The Restoration Team has been doing a wonderful job because we were able to load card decks on the CT1402 with I/O Check Stop in the normal ON (Up) position. This is a huge improvement -- apparently all read brushes and check brushes were working correctly. Big THANK YOU shout-out to the Restoration Team.

With hopeful optimism, we tried running actual software (instead of the TAU) on the CT 729 Tape Drives. Drives #1, #2, and #3 would not run on the Tape Exerciser (Ron 2.1). Drive #4 ran until it reached the end-of-reel marker and then hung.

We still hope eventually to try Tape-resident demos. To try this, we need CT with at least one (1) 729 Tape Drive which will run with software. Ron 2.1 is a good test for this.

Jack Ghiselli
jghiselli@sbcglobal.net mobile 1-408-839-105

Details: I found two intermittent problems with the CT 1402. First, relay 11 #1 CL DELAY was giving bad or truncated feed signals, probably due to dirty contacts. Replacing the relay fixed this. In this picture, the yellow signal (NOT PROC FEED) should match the cyan signal (PROC FEED), but you can see that the yellow signal is messed up:

The second problem was that LOAD caused a single clutch cycle ending with a READER STOP. Checking the various stop paths showed that the clutch check circuitry was triggering the READER STOP erroneously because relay 10 CLUTCH CHECK wasn't holding. David suggested that diode RD19 might have too much resistance to activate the hold coil. I tried to clip the scope on RD19 and the probe went right through the lead, which had fallen apart from corrosion! David soldered the diode back together and LOADs worked successfully.

Remaining issues with CT 1402:

1. The check brushes cause a lot of errors and need to be adjusted so the card reader can be used reliably. Next week I'l take a look at the data coming from the brushes to see what I can determine.
2. The "chugging" behavior is not consistent with DE. It is unclear if this is a real problem and if so, how important. It is possible that the problem with relay 11 was covering up another problem.

Ken

Summary: we found and fixed two 1402 problems, but the unit is still exhibiting its same old card munch and Reader Check problems.

The first problem we fixed was the corroded RD19 diode lead in series with the hold coil of Relay 10 as Ken described. The second problem we fixed was to reconnect the "mystery" wire associated with the continuous cams. This wire has been suspiciously disconnected for several months, but until today we did not know if it was a bug or merely an artifact of the machine's solar cell conversion. We were able to trace the wire to find that it is the connection from Cam 6 to PKT-9 thru PKT-11. This signal is associated with the stacker (which we never use) so its repair didn't affect the usual problems.

After these repairs we tried the 'NPRO with card in throat' test and sure enough the card was munched as usual. So we are still not out of the woods with this issue. I still think that the single-cycle response to an NPRO with CL1 actuated is correlated with this fault, and that the hold of Relay 6 (and possibly relay 13) are involved. So some future scoping of those coils is in order.

The other problem is the chronic Reader Checks, which we believe are due to poor connectivity or alignment in the Check Brush system (brushes, roller, common brush, etc.). But because with careful deck hygiene, CT can still read cards without munching them, we think the Reader Check problem is more threatening to the demos than the card munch problem. So fixing the Reader Checks is the highest priority effort. Ken is working on an analysis method that decodes 1401 core signals to reveal Reader Brush failures, so that repair effort is now the main focus. Fixing the munching problem is still imperative, but is priority #2.

DC

One of the smaller motors in one of our 729 tape drives in the 1401 Demo Lab died/smoked last weekend. (Photo below)

Is it possible that Marc Verdiell (cc’d) could drop by next week (say Weds?) to extract a replacement from one of our donor 729s in Yosemite? It shouldn’t take more than 15 minutes or so to get it out.

I understand that you’re quite busy these days, but hoping you might be able to squeeze in this short visit. :--))

Thanks(!),

- Robert

Frank King, his daughter Carla, and Ken Shirriff lamenting the poor thing’s end of life. :--))

Surprisingly, vacuum pump itself was spotless – as in squeaky clean spotless – and ran smooth as butter.

Then Ken reminded me that this is the pump that suffered a similar smoke incident 5 years ago. I had worked on it at the time, found it clogged by dust and debris, and its bearings were shot. I had replaced the bearings and cleaned it thoroughly – and apparently completely forgot about it. The windings must have been damaged in that previous incident and finally gave way.

It’s a 3-phase motor rated for European 220V/50Hz.

We probably don’t have another one of these, but Stan told me that the CT tapes had motors with ratings fairly close to that. Then Ken showed me on the schematics that Stan is right, at least some of the CT tapes should have 230V/60Hz vacuum pump motors in them (although I looked at CT#4, and it had a 208V motor of a different construction). The 230V would be close enough if we have one spare in Yosemite.

So, we should first try to see if we have a replacement in Yosemite before trying alternate revival methods. Robert is already working with Aurora to try arranging a visit.

So DE#3 will be out for a little while. It is turned off, and the terminator has been moved to DE#2, so DE can be demoed safely with tapes 1 and 2 in the meantime.

I also found CT#3 marked as out of service, but I could find nothing wrong with it, so I put it back in service. All 4 CT tapes appeared to behave.

Marc

After cleaning the punch one of the die was very difficult to install and immediately jammed solidly. I was not able to clean out the die using my tools.

On Weds Fank and Arda modified a burnishing tool to it could be used to clean the surfaces of the die and stripper.

This has fixed the operation of the #3 die, however now the #9 punch is sticking. Both David and Mark had some excellent suggestions as to how to proceed.

This week I will modify the burnishing tool so it fits into the #9 hole better and see if that punch can be cleared. The next level of repair involves removal of the die-stripper pair, and I may start his process by learning on a verifier this week.

John

We started the day by carefully examining the rat's nest of wiring behind the relay panel, focusing particularly on Relay #6 which was implicated by the QSpice model. It is potentially involved in the one-and-done clutch behavior we suspect is related to the card mangling problem. We did not see any problems specific to Relay 6, but did find one disconnected wire associated with the punch unit relays. After some probing with an ohmmeter, we found the proper destination for this wire and restored its connection. We also discovered that several of the punch relays had been improperly installed into their sockets, so we fixed that as well. None of these changes affected the reader's problem.

We next turned our attention to carefully examining the relays visually while they were operating. We noticed that the machine's behavior had changed from prior weeks in that it would single-cycle even if Card Lever 1 was not actuated. We eventually traced that to a bent contact in one of the relay sockets, a problem we likely introduced ourselves whild debugging. We fixed that and inspected all of the other reader relay sockets. We found no other problems. The machine was now exhibiting the same single-cycle behavior as we've seen for weeks, and it did not respond to any flexing of the relays or their wiring.

We did notice that when Relay 10 was manually picked by forcing its armature, the machine responded to CL1 correctly. So while we did not manage to find the root cause yet, it seems we are inching closer to finding the problem.

Next up is to use the observations we gathered this week to gain further insight using the QSpice model.

DC

I added a qualification to the latch signal to play the role of the 1401's interaction. We believe the 1402 sends -T_NOT_PROC_FEED to the 1401 which returns -T_READ_CLUTCH with negligible delay. -T_READ_CLUTCH is an PNP emitter that provides the ground return path for the -20V clutch drive signal provided by the cams. Because both the cam drive and ground return signals are needed to energize the clutch solenoid, a logical AND is needed to simulate them. So I added an AND gate as shown here:

The OR gate just gives a way to override -T_NOT_PROC_FEED for offline mode.

The resulting simulation for an NPRO in Online mode with Sync off and Card Lever 1 active is shown here. Notice that the clutched shaft (red trace, second panel from bottom) halts for 120 degrees before latching again at the next opportunity. This is exactly the "chugging" that Ken observed on the DE machine.

This is a pretty cool validation of the QSpice model, and is a good confirmation that DE is working as-designed, at least under these special conditions.

It will now be fun to try to break the model to simulate CT's misbehavior.

I will push these changes now.

DC

Best regards,

Tom

Powers-of-Two demo deck completely loaded, to Last Card, in CT1402 No card crunching.

CT1402 Front Panel shows Reader Check and Validity Errors. I/O Check Stop was OFF, so load continued to Last Card.

CT1401 Front Panel is nuts. Lots of error lights and random displays. CHECK RESET came on with 1402 Validity error. The demo deck must have loaded enough good data for columns 40-71 to execute, but the executable object program in columns 1-39 probably was garbage. No time to investigate further. We just quit using CT and went to DE.

Jack Ghiselli
jghiselli@sbcglobal.net mobile 1-408-839-1051

I was also wondering: Was the DE1401 panel displaying any other red lights besides READER?
      (When you have this failure in future, could you please snap a photo of the panel?)

> Reader stop and read check issues sometimes resolved by powering off/on but later nothing could be run.

Sam and I have also seen that behavior. After about four attempts, the DE 1401 eventually complied.

Thanks,

— Robert

p.s. Hopefully what you saw wasn’t the cacophony of red lights we were getting earlier (now hopefully fixed by replacing the bad CQZV card):

We’ve still occasionally seen this light display:

I didn't realize that the Duo relays in our unit are 4PDT instead of DPDT, so I added two extra sets of contacts to its model and recreated the hierarchy symbol. And instead of just using the Duo relay symbol for the operator switches (NPRO, etc.) I made a proper DPDT module for them. I also found that the Hold coil for Relay #4 (READ STOP) is not ground-referenced like the others. Fortunately, it is referenced to the -20 volt power supply (logic "1" or +1 volt in the model) , effectively inverting its behavior. So I just added an inverter to drive that signal. I plan on working on it more today and will try to push an update to GitHub tonight. My first goal is to get the main motor to turn on when NPRO is pressed.

DC

Ken

> Maybe an intermittent contact in the inductor?

Definitely looks that way.

Putting it on the I-V curve tracer and gently rocking it shows the current chaotically jumping between a near open circuit (perhaps around 400k ohms) and a doggy attempt at 2.6 ohms, per this 6-second video:

Entropy: +1

Cheers,

— Robert

p.s. One could dissolve its encapsulate to see frail or corroded wires inside?

     The type number plate from our punch is 001-10003-JPN
     The parts catalog title is 01-51 Mechanical Punch & Verifier.

The recent document from Peter answers the question about the historic use of the X key! It can function as a tab. The mechanical logic makes sense now, there is a mechanical OR function at the escapement pawl. The X key OR the Release key can activate the escapement. All our machines use a non-skip bar which performs no added function, consumes a significant number of unused parts, and adds another mechanical escapement adjustment.

HUGE thanks to Peter.

John

Although the X-key is not present in our “001,” it sounds like you see mechanics in our unit that support it?
     (i.e., “The mechanical logic makes sense now, there is a mechanical OR function at the escapement pawl.”)

          The parts catalog title is 01-51 Mechanical Punch & Verifier.

The 1987 listing of all IBM products appears to reclassify it as “0051," consistent with their bone-dry 4-digit nomenclature.
The listing shows introduction sometime in 1910 and also shows several of its “Verifier” siblings, the 0059 introduced as last as 1966!

Perhaps someone in IBM product marketing bucked the naming rules with the two-part "01-51" designation? (at least it’s 4 digits. There is no “0151” in the listing.)

The “001" was sanctified as a 4-digit part number with another leading 0, as in “0001”, and was manufactured up until 1953!

     The type number plate from our punch is 001-10003-JPN

Ah, good to know it’s an actual 001.
I presume "10003-JPN” implies serial #10,003 and that it was manufactured in Japan (JPN was Japan's ISO abbreviation)?

Cheers,

— Robert

I have added the cams and clutch, PM and Duo relays, and the Card Lever switches. I also put in a few connection nets. I think this should be enough for the basic modeling of the card transport. Now we have the real work of adding all of the interconnection wires...

If you want to play with it, you can download it from GitHub. Unzip everything into one folder, then open the top level schematic. Simulate it, then open the top level plot configuration file and you should see a result similar to the one I posted yesterday.

BTW, if you look inside the underlying relay models, you'll see that each switch terminal has a 10Meg pull-down resistor. This is to suppress floating net warnings, plus it gives every node a definitive voltage. Everything else is pretty self-explanatory.

DC

I figured out why the “bad" CQZV card is actually bad (causing the DE1401 to occasionally seize) —it’s a faulty inductor.
  We were led down the garden path positing our normally dodgy transistors and diodes. And it’s not a bad ohmic contact on the card edge connector or a backplane socket pin.

Here the device tester couldn’t grok what the bad inductor actually is, showing a question mark (?), versus a good 50-microHenry (.05 mH) inductor:

My digital multimeter could not settle on its resistance, but my analog VOM measured about 400 kOhms (vs. 2.6 ohms for a good one):

Background story: After the I-V curve tracing I did last week (which showed all good transistors), this week I brought home a good CQZV card to compare against and a backplane socket receptacle to see if a sketchy card edge pad or possibly a backplane socket interaction might be the culprit.

Lowering the input voltage all the way down to about 0.086 V was the only way to get an output near -6V to -8V; i.e., what you saw last Wednesday in the DE 1401. This was true for both the good and bad cards.

Since such a low input current caused the low output voltage, that got me thinking that perhaps one of the discretes in the collector pull-up path (resistor or inductor) could also be limiting the output current (and thus the low voltage). That led me to testing the resistor and inductor. Bingo.

Whew,

— Robert

p.s. This might make one fret about the hundreds of inductors in our 3000 SMS cards. This is not the first time we’ve had an inductor fail on us:
https://ibm-1401.info/Sched2005November.html
https://ibm-1401.info/TimsInCircuit.html

While it's all setup, I'll measure the output speedup the inductor is purported to have on the rising output signal.

I arrived early to test the CT1401 and DE1401. CT1401 didn't crunch cards but just gave me validity checks and reader stop checks, yet it still didn't load the deck so I turned it off. Before the demo I tested the DE1401 to successfully run the BigPrint after trying a second deck. I planned to preload the program during the demo so that we wouldn't have any issues.

It turned out Larry and I didn't communicate about how we would like to run the program before the demo. He re-ran the BigPrint again during the demo and the deck loaded but it didn't print out anything. Larry told me he would like to take a look and let me continue the demo. Lesson learned that I shall tell my demonstrator to join me for the rest of the demo instead of digging into debugging the deck himself. While I kept passing over the props and collecting them back by myself with Larry running the deck several times beside me, the audience irritatedly switched their attention to the live debugging instead of the demo. I had to pause and check with him about the progress. Then I firmly asked him to join me to demo the CPU together and we could give the deck a look after the demo. (After the demo I communicated it with Larry and he agreed that it was not wise to keep debugging while the demo was on as well as we shall preload the deck if it worked at first before the demo:-)

After the demo Larry figured there was no issue with the deck but the date card was bad, mostly frilled. He made a new one and we were able to do some printouts for our visitors staying after the demo. I was surprised how soon a newly typed date card could be broken just after a second run, the first run was done by me before the demo for testing. Lesson learned again that we could prepare two same date cards if they are so easy to be frilled and not be able to be read through by 1401.

The sorter worked fine and all the three keypunches worked well. The tape drive worked fine. Mic #1 had some intermittent cutout.

• DE 1402 not working well. Restoration Team: can you please help? We'd appreciate it.
• BigPrint decks need attention

Question/Issue?

Found 4 vials of core ferrite in the demo box. Didn't we have 5?

I did a few tests on Saturday, 2/3 to identify the source of issues with the BigPrint Decks and/or DE 1402.

Summary

• There are 3 good BigPrint decks that can be used for demos
• VOBJ shows inconsistent results on suspect decks
• 2 of the BigPrint decks encounter reader stop issues for reasons TBD

The decks labeled as Deck #1, #2, and "Frank King" seem to be usable. Use caution with Deck #1 since the edges appear worn. Deck #3 encounters a reader stop after card 94, 95. Deck #4 stops loading on card #87 (even after duplicating) as previously reported by Jack

Method

I ran VOBJ using the "Frank King" deck as the known good deck since the program ran successfully and consistently.

Results

The table below shows that on card 50, there are card mismatch errors although the code matches exactly. However the Frank King deck can still be run successfully. Card mismatches occur on other cards in Deck #2 but the specific card that is flagged as a mismatch is neither repeatable nor consistent, as evidenced by repeated trials on Deck #2. The mismatches appear within the first 20 columns.

See attached PDF for pictures of the printout from VOBJ.

Unresolved questions: Why does:

1. Card #50 show a mismatch when the code is exactly the same between 2 different decks?
2. BigPrint run successfully despite #1 above?
3. The VOBJ report show different card mismatches when deck #2 is run repeatedly?
4. The mismatch seems to occur within the first 20 columns of the deck. Could this be indicative of an area of the card reader that might have a hardware issue?

Next Steps

I plan to run VOBJ but if I continue to get similar results, is it possible to get a clean fresh copy of BigPrint on good cardstock? Since the card punches on the 1402's aren't working, is there a golden copy stashed away somewhere that I could duplicate manually and use it as a secondary standard?

I'd appreciate your collective intelligence and suggestions.

Larry

I wanted to confirm that, for program decks (e.g, BigPrint), you're not using the new blank “Name” punched cards. The Name cards are not made with genuine IBM-spec'd paper stock, so we should limit them to onetime-to-low usage. To me, the newly manufactured cards (from TimeCardsUSA/SignalSystems, the last vendor standing*) feel smoother/slipperier than the period/genuine cards. What do you think?

A single box of Name cards resides in the A/V closet and they populate the 026 keypunches. The remainder (of the last order) are stored in several drawers in the back room, on the right side, where they’re rigidly compressed to reduce bowing/bending. The period Vintage cards (for program decks or other high usages) are on the left side, per this photo:

We have a stash of about 200,000 Vintage cards still in the Yosemite warehouse.

Cheers,

— Robert

p.s. Also note this earlier email from Frank King back when we were adjusting the card picker knives:

If someone would like to delve into the characteristics of the material that they used for our part number I will be glad to turn over the role of interface to to Helwig Carbon Products to that person. Personally, I don't know enough about making carbon brushes to carry on a dialog with them about their business. Let me know if you would like contact info.

If I were interested in following up on this, I would want to know if the brushes that seemed to be wearing excessively were really the Helwig or the home made ones.

Dave Bennet

Oh it’s that old? That was one of my first heroic repair. Time flies by! Maybe it’s normal wear then. Asking if they have harder material, or something they recommend for riding on copper is probably worth it.
Marc

>> Recently a parts catalog for an IBM 001 keypunch machine was located

Did you mean to type “parts catalog for an IBM 010 keypunch”?

Thanks,

— Robert

So I've been experimenting with logic simulators and have some results.

After watching Marc's video about LogiSim, I downloaded it and gave it a try with the goal of simulating the clutch & cam system. I set up a pair of counters representing the clutch and unclutched shaft angles (in 1 degree steps, modulo 360), and got them to synchronize to each other in response to a clutch latch signal. I was also able to model all of the clutched and unclutched cams. I only crashed the simulator four times! But then I realized that the software is totally incapable of analyzing its own simulation results: its "oscilloscope" has a memory depth of only 30 samples, and its "chronogram" cannot zoom at all, making inspection of multiple 360 degree machine cycles virtually impossible. And it doesn't store its chronogram parameters, so you have to set them up from scratch each session. It is a real pain!

So then I looked at QSpice. QSpice is the next generation of analog simulators from the guy who wrote LTSpice, so I have high confidence in its accuracy and stability. It has some unique features that might make modeling the 1402 (or at least parts of it) possible:

• It allows circuit modules to be written in both Verilog and C++. This will make the cam generation really easy.
• It has a voltage-controlled switch primitive, which will make the modeling of our dual-coil relays easy. This gets around a major stumbling block for using a traditional digital simulator for relay logic, since we often can't tell which direction the "logic" flows across relay contacts. With actual switches, we don't need to know.
• It supports hierarchical design, and seems quite at home modeling digital circuitry. Many of its example files model complex ICs (switching voltage regulators, for example) that have a mixture of analog and digital circuitry inside.

So I am currently working on a clutch/cam module with the guts written in Verilog. I am VERY rusty on Verilog so I may need to lean on your expertise if that is okay with you. I'm envisioning a Verilog block that accepts an input clock (one tick per degree of machine rotation), a "power" input that corresponds to the AC motor that drives the unclutched rollers, and a clutch latch input that trips the clutch at the proper angle and activates the clutched cams. This module will also have boolean outputs for each of the cams. Those booleans will in turn drive switch primitives that will get interconnected to the relays.

I'll post results as I make progress. But I may need to bug you in case I get stuck.

Cheers!

DC

The trouble with making an abstracted behavioral model of the 1402 is that we (or at least I) don't actually understand how it is supposed to behave. So for me, the purpose of making a close model is to help me understand how the thing is supposed to work. And to be clear, the model I'm working on is not the complete machine, but rather only the card handling logic on the reader side. That's because that is where the machine is currently having problems.

I made progress on a QSpice model yesterday. I have a Verilog module (attached) that models the continuous and clutched cams plus the Solar Cell. Please have a look at the file to see if I have made any rookie blunders. The plot below shows the simulation results (note that I have added DC offsets to the signal plot expressions to separate them vertically from each other in the display.) The two sawtooth plots represent the angles (0 to 360 degrees) of the continuous and clutched shafts. You can see when the clutch latch signal at the bottom becomes true, the clutch latches at the correct 315 degree location. The clutch shaft turns and the clutched cams operate. If the continuous shaft gets to 315 degrees with the clutch latch signal inactive, the clutched shaft stops and stays at 315 degrees. The cam angles should be correct, but they could use a good checking.

Next up is the modeling of the PM relays with their pick and hold coils. I believe that all of the 1402's relay coils are ground-referenced, so I can use simple logic to represent their coil drive signals. If I encounter a relay coil that is not ground referenced, I'll need to figure out how to "float" the ground terminal of its logic drive.

DC

Keypunches were all fantastic. Microphones worked well, although maybe it's just me, but it seems that there is distortion and drop-outs with Mic #1. I tried to reduce the volume, but I can't seem to get the microphone itself to move further back so as to avoid the distortion/clipping effect.

Tape drives on DE all worked well. Sorter worked great. It just so happened that BigPrint wasn't pre-loaded and it worked well, as did Powers of Two.

Museum attendance was light, so we only had about 35 guests with 20 or so before and after. David Hoyt came in last-minute as we were shutting down with a very interested group of 8 or so people. I was able to provide them with a condensed demo which they were absolutely thrilled about.

Robert and I were cleaning up later on and there was a ton of paper I tossed out/recycled. We sure do go through a lot of paper!

That's all for now folks,

~Samuel Plainfield

David noted that the schematics for the reader punch device call out two different types of 4 pole permissive make relays, highspeed and low speed. Our relay testers do not check the pick and dropout timing, so we may not have the correct relay configuration in the machine. It is possible this could be causing our high error rate. I checked into this situation.

The FE Manual Chart 2-33 is a table of “Permissive Make Relay Characteristics.

Relay Part	Coil part and type	Pick ohms	Pick ms	Drop ms
719003	719009 High Speed	70	2.5	2.5
719005	719010 Normal	126	3.3	2.5

We have 1 Normal relay and 7 High Speed relays in stock.

John

Early in the mornin' Frank and I set out to check the DE1403 ribbon to get that fixed for the day's demo. We tried to run a Lincoln deck but as previously noted, some of the Lincoln decks were messed up, missing cards and/or out of order.

Due to the weather, museum attendance was light and we didn't want to use up too much time fixing card decks given the large amount of issues we wanted to get fixed. Fortunately, Larry Hara came by and saved the day ~ fixing up all the decks with Jack's brilliant VBOJ program. Thanks Larry!

The problem decks revealed that the left error bulb on DE1401's STORAGE ADDRESS is burned out. Low priority item, but we'll see that it gets fixed one of these days, I'm sure :)

So, back to the printer. We ran the Christmas Pi deck and to our surprise it printed perfectly. Frank suspects that the ribbon failed to advance at some point, resulting in a large worn-down inkless spot. The ribbon was replaced; Frank and I thoroughly checked the oil as well and it is in tip-top shape!

Back to CT1402 card munchin' ~ we isolated the problem down to a repeatable set of behaviors that indict a relay (or relays) responsible for an erroneous hold operation. It was further identified that a few relays in the system were of the low-speed variety (719011/719010) and should have been the high-speed (719009) type.

Naturally, we swapped 'em out with the high-speed type and. . . no change in behavior.

Using the LED circuit checker attached to various relays/cams, we noticed some aberrant/erratic/latent holding behavior and so it was theorized that perhaps the relay #6 socket itself was to blame since that was recently an issue on the DE tape drives which Marc fixed.

(#6 socket before adjustments to the lower-right pick/hold connectors)

Using my favorite dental tool (actually called the spring tool), I attempted to adjust the connectors but they were pretty solid and in-place. Frank went a step further to increase the spacing between the protruding metal on the relay itself with his handy pocket knife. That's how the pro's do it:

For those of you wondering just what exactly the back-side of the relay wiring looks like. Well, wonder no further...

https://www.youtube.com/shorts/YKUx4KWv9rw

I looked at each pin and the connections looked solid. So, further tracing continued; I'll wait for David to explain further on that since it was a lengthy process and he will likely recall the order of it at all much better than I can.

Demo

The 1/31/2024 3pm demo went just fine. I was lead and Scott Stauder was Operator for the day. Duane Sand came in to help out as well.

Keypunches were all fantastic. Microphones worked well, although maybe it's just me, but it seems that there is distortion and drop-outs with Mic #1. I tried to reduce the volume, but I can't seem to get the microphone itself to move further back so as to avoid the distortion/clipping effect.

Tape drives on DE all worked well. Sorter worked great. It just so happened that BigPrint wasn't pre-loaded and it worked well, as did Powers of Two.

Museum attendance was light, so we only had about 35 guests with 20 or so before and after. David Hoyt came in last-minute as we were shutting down with a very interested group of 8 or so people. I was able to provide them with a condensed demo which they were absolutely thrilled about.

Robert and I were cleaning up later on and there was a ton of paper I tossed out/recycled. We sure do go through a lot of paper!

That's all for now folks,

~Samuel Plainfield

We burnished the right vacuum switch contacts (both upper and lower, as both are involved in tripping the tape up clutch), but that did not help.

We then checked the current going through the right up clutch while in operation, thanks to a CE panel on the front right of the tape that I didn’t even know existed. It was very low when the failure occurred.

I then checked the carbon brushes on the up clutch and found both worn, with one worn to the point of making intermittent contact. These are the “new” brushes that we had remade, so our new carbon material might be a bit too soft and wear out prematurely. They were also riding askew on the races, which might have hastened the wearout.

Anyhow we replaced the brushes with new ones, realigned them properly, and all is good. CT tape 3 is back to operational.

Marc

Thank you, Marc for the report. I have attached the relevant photos of our efforts.

Kind regards,

Arda

A few weeks ago I found that the CQZV card in 01B4 E23 was causing the persistent punch checks on DE. Replacing the card fixed the punch checks. However, when I tested the card at home it worked fine. Robert tested the card as well and found that it worked fine. Robert and I swapped the good and bad card a few times. With the good card, a T input of 4.4 volts yielded a good U output of -11.8 volts. However, the bad card produced an output of -5.4V which is very wrong for a U signal (should be -12 or 0). While watching, the bad output changed to -8.4 volts. I installed the bad card on an SMS extender so I could probe the signals on it. Suddenly the card started working fine! My conclusion is that a contact on the card is probably bad. There was some discoloration on the gold contacts which is suspicious.

Card image project. When a card is read, for each row, the 80 signals from each set of brushes are written directly into special cores in parallel (the RD1 and RD2 planes). After a row is read, the 1401 iterates through the 80 columns and checks if a hole is present. If so, it adds the row value to the corresponding character position to build up the character, row by row. At the same time, it updates the two hole count bits for that column, the bits that are used to catch misreads and generate a reader check.

Key point: a row from the card reader goes into the cores in parallel. The 1401 processes each row sequentially, column by column.

My idea was to use an oscilloscope to log the hole signals coming out of the cores in the 1401. This means we can look at 2 signals instead of 160 signals, which is much more practical. I wrote a program to process this data and convert it into a card image and the corresponding data. If we run this on the CT machine, we can see what card data the 1401 is processing and determine why it gets reader checks. If the data coming out of the cores is wrong, then we can see exactly what errors there are and then determine what is going wrong between the 1402 and 1401. For now, I'm running this on DE to get the process working.

Here's a photo showing the hole pattern for one row, for the two read positions. This is the hole data being read out of the cores sequentially, not the data directly from the brushes.

Here's some output from my program, generating a card image and determining the data on the card:

................................................................................
....................................*......*....................................
***.*..**..*..**.**..**..**..**..*...******.****.*.....................***......
.....*..........................................*.........................*.....
.........**.*.....................................*.............................
*......*......*.*..*.*...*...*..*..*............................................
.......................**..*....................................................
......*........................*..*.*......*....................................
.............*.....................................*............................
....................*...........................................................
*..*...*......*......*...*...*..................................................
............................*...................................................
,008015,022026,030037,044,049,053053N000000N00001026                   0001

Once the CT card reader stops crunching cards, I can run this on CT and see what is causing reader checks. This program will show exactly which hole is getting read incorrectly.

Ken

I noticed something puzzling about the card reader and how it drives the cores, regarding the full-write and half-write current.

There are two different circuits for how the brushes can flip the hole cores in the 1401: the full-write circuit and the half-write circuit, based on how much of the current goes through the brushes.

The 1402 Card Read-Punch CE Manual of Instruction says that the solar cell machines provide full write current through the brushes to the cores. The circuit breaker machines provide 1/2 write current through the brushes while a second path provides 1/2 write current to all the cores. Either way, the core will flip when a brush detects a hole.

The CT card reader uses the solar cell, while the DE card reader uses cams. As I checked earlier, DE machine has 180-ohm resistors, while the CT machine has the 330-ohm half-write resistors. So the CT's current through the cores from the brushes will be approximately half of DE's.

The point of this is that the manual says that cam machines use the 1/2 write circuit and the solar cell machines use the full write circuit. But our machines are the other way around. The cam machine (DE) uses the full write circuit and the solar cell machine (CT) uses the half write circuit. As far as I can tell, this is intentional and the CT 1402 had an EC to add the solar cell while keeping the half write current circuit. But this is something to keep in mind when investigating card reading issues on the CT machine; it seems to be a bit of a frankenmachine.

Relevant text:

I don't have a lot to add to Sam's reporting on the CT 1402 Card crunching. The big picture is that we are attempting to explain the behavioral difference between the CT and DE machine vis-à-vis their NPRO behavior in the presence of a card at Card Lever #1. The DE machine continually cycles its clutch during a NPRO except when Card Lever #1 (CL1 is the lever switch at the throat of the machine, just under the hopper stack), whereupon it cycles its clutch on alternate machine cycles. In contrast, the CT machine continuously cycles its clutch when no cards are present, but if a card is present at CL1, it cycles the clutch once and only once. When the card is removed, an NPRO will again cycle the clutch once and only once. Subsequent NPROs cycle the clutch continuously. We believe the "once only" clutch cycle is responsible for the card crunching because it allows a card to be fed into the continuously running roller #2 which then jams the card into the now-stationary clutched roller #3.

One important new observation is that this behavior happens even when the machine is placed in Offline Mode via the rotary switch on the Dynamic Analyzer panel. Looking at the schematic, this switch effectively bypasses the 1401's involvement in feeding cards. This means that we can pretty much rule out any faulty 1401 logic for being the root cause of the problem.

Next we started looking at the states of several relays using the scope and an LED test light. Since the machine was exhibiting stateful behavior (it "remembered" that it had seen a card at the Lever 1 position), we reasoned that some device had to be retaining the saved state. Only its relays can do that, so we focused on them. We eventually observed that Relay #2 (Card Lever 1 relay) was being picked and held starting with the first NPRO with a card present at CL1, and released only after the second NPRO after the CL1 card was removed.

We also noticed some flaky and inconsistent behavior with that relay, which we eventually traced to a loose wire on one of the clutched cams. After tightening that connection, the behavior was the same but very consistent.

We tried to decipher the conditions that lead to the release of Relay #2, and it appears that our old friend Relay 12 is involved. This is the relay that I replaced to fix the problem some weeks ago, only to have the problem recur. But so far, the schematics seem to indicate that the behavior is by-design, although it is a little too complex for me to be sure. So we will want to scrutinize this circuit more carefully. There is also a pair of diodes (RD56 and RD57) that may be involved, so they need testing as well.

I had one other thought that maybe Mark could answer: would it be feasible to write a VHDL (or Verilog) model of the 1402's relay logic so we could determine what the as-designed behavior should be? I would think the challenge would be modeling the relay contacts because they don't have a specific signal direction (input vs. output), but rather only a connected vs. disconnected status. Does VHDL or Verilog have a means to model that kind of connectivity?

That's it for this week.

DC

ASTM D3363 defines a "pencil hardness test" that is used to measure the hardness of painted finishes. Pencils of different hardnesses are drawn across the test surface at a known angle and with a known force. The surface is then examined to find which pencils do and which do not scratch the surface. We could use this same technique to gauge the hardness of our brushes in comparison to the originals. If we have more brushes made, we could then stipulate he hardness we need.

DC

Yesterday Marc and Arda found that the carbon brushes in CT 729 #3 were heavily worn, per this photo:

and a document from brush vendor to Dave Bennett here

Marc —> Do we know if these are the “pure graphite” round ones (that you ordered back in Feb, 2016) and cut down on your lathe or are they the ones that Dave Bennet ordered from Hellwig Carbon Products?

Fyi, the email thread about replacing the carbon brushes is here: https://ibm-1401.info/729ClutchBrushes.html
It looks like the new brushes were installed in April 2016, so they’re almost 7 years old now.
Perhaps this is representative of their normal wear rate?

Should we contact Hellwig to see if they have a harder carbon?

Cheers,

— Robert

When I got to CHM I verified that DE was functional. Shortly after Jack Ghiselli arrived he began seeing if he could coax the CT 1402 to read cards. Instead it was munching them. He cleared one jam but the problems persisted, so we ran on DE. We did use the CT tapes #1, #2, and #4 for the tape demo in addition to all three DE tapes so that more people could see the action. Toward the end of the day the DE 1402 got ocassional reader checks, all of which went away on reruns.

Karen Sun joined us and, at my request, duplicated more "decoder" cards (with all printable characters) for us to use in explaining card code.
Thanks, Karen.

Larry Hara also stopped in between leading Revolution tours. Jack and Larry used VOBJ to fix problems in several BigPrint decks. See Jack's separate report for details.

There were peak times when all five of us were busy. Thanks to all of the helpers.

All three kepunches and the sorter ran fine. The DE 1403 ran fine most of the day. For about the last 45 minutes, the printing got progressivly more faint. During the 20 minutes before closing I just had guests punch their name cards but didn't print them because the results would have been unreadable. I tried seating the chain housing and latch more firmly, but it didn't help.

I used mic #1, which had some dropouts. It may have been battery problems. Even though I swapped in fresh batteries from the charger before the demo, I'm never sure that they are truly fully charged.

All things considered it was a fun if sometimes hectic day. As usual, big thanks to the restoration team for keeping us supplied with enough working machinery to conduct the demos for a grateful public.

Pat

As demo lead that day I was the one who wrote the numbers in the blue book. They were 90 for the demo, and 350 others. My counts reflect every person who entered the room, regardless of when theyt arrived or if the left early.

Demo count

Jack gave me a count he took at the start of the demo. I've lost what that number was. In any case, probably 20+ more came in during the demo. The room was almost full. In fact, Larry Hara took it on himself to stand by the main entrance and re-direct those who couldn't get in to the the exit door. Thanks, Larry! Inasmuch as we were running mainly on DE, that actually wasn't a bad place to be. During the recent holidays and other busy times we frequently have 90, 95, or even 100 or more there. You can go back in the blue book and see what was reported. We were almost full, so that's how I derived that number.

Drop In Count

The room was open from 10:00 - 5:00. I know, because I was there all that time. So excluding the demo time, that leaves about 6 hours. 350 visitors / 6 hours = ~60 visitors/hour = ~1/minute (average). Many times throughout the day we could see 10-15 people at the keypunches, another 10-15 waiting for BigPrints plus a few others. That's 30+ people in the room just at that instant. Those are peak times but in off-peaks we saw an almost constant lesser flow. The first 45 minutes of the day were slow. That's a good thing because it gave us a chance to fix the decks. Jack and Larry interleaved running VOBJ with BigPrints and they got much done. Thanks, guys. In the last hour there was the usual rush of people. I only got out of the room by about 5:10 because I couldn't run any more BigPrints due to the DE 1403 faint printing problem.

Note that the number of BigPrints does not = the number of visitors. I think it's less than half. A common visitor group has 2 parents and 1 or 2 kids. Usually only the kids punch name cards. Also the card veterans usually aren't anxious to punch yet another one.

Several times during the day I convened the 1401 demonstrators and asked for crowd size estimates. No definite figures were offered. In fairness, when one is as busy as we were, you really don't think of counting.

If these numbers still seem high, by all means reduce them. Large crowds of moving people are very hard to accurately asses.

Pat

The CT1402 reader had a 3-card jam at the end of yesterday's 1:00 demo. Sam Plainfield stayed late and cleared it. Unfortunately this morning CT1402 again got a new 3-card jam. I cleared out the new jammed cards, but the CT1402 still won't feed cards. So demos used DE.

The deck that got crunched was a Lincoln. So, there is a Lincoln deck missing its first 3 cards (#0001 - #0003). On card #0004, we wrote a note that the deck had missing cards, but due to ongoing demos we didn't have time to fix the deck.;

The CT1402 Reader NON-PROC-RUNOUT rocker switch works, but seems to be physically loose. Can somebody fix this before it breaks? I don't know how.

Pat Buder (Demo Lead) reported that when he came in NONE of the BigPrint demo decks worked. Using DE, Larry Hara and I ran VOBJ on some of them and found these errors:

1. BigPrint deck #1: One card caused a validity check. We duplicated the card and the error disappeared.

2. BigPrint deck #2: Card #0004 had been moved to the end of the deck, just before the final card #0111. We fixed this.

3. BigPrint deck #3: Several of the cards were upside-down in the deck, and the last card was missing. We fixed these problems and the deck now works.

4. Since demos were starting, we did not have time to look at BigPrint deck #4 nor the BigPrint deck labelled "Frank King".

Jack Ghiselli
jghiselli@sbcglobal.net mobile 1-408-839-1051

I used keypunch #1 and #2. The sorter worked smoothly. I turned on both CT and DE while I successfully ran the Big Print on CT. I tested the DE with Powers of Two and Lincoln yet it didn't load any card nor any check lights on. I turned DE off afterwards with its power on. 729 Tape Drives on the CT has #1, #2 worked. #3 had one end of the thread fall off and I flipped it Inoperable. #4 didn't start any movement no matter what buttons I pressed.

The audience was very warm and shared a lot of comments and their personal stories with me. A Japanese Revolution guide brought his tour group to the demo and after the demo he helped me punch name cards as well as tear off the Big Print. Thank you :--))

We'll be back at it again Wednesday,

~Samuel Plainfield

Pat

We investigated the issue. The hole has been repaired by simple switch of the board. Moving the square board with the hole from the walking path - to under the 2nd 026 Key punch machine out of the general walkway to the AV closet. We can thank David Clementson for coming in early to fix this issue. I’ve attached some pictures to show what was done. Thank you everyone with your help with this. Teamwork!

Let us know if you have any questions or concerns.

Thanks,

....................................
Jesse Nichols III
Museum Services Supervisor and Volunteer Coordinator
Computer History Museum

DE punch check: I measured the suspicious card in circuit. 01B4E23 pin C showed -6 volts. This is a U output so it should be -12 or 0. Thus, the card was producing a bad voltage right in the middle that would sometimes signal that a punch was happening. I swapped the card and the new card shows -12 volts as expected. The transistors all seemed ok with the multimeter but the diodes showed forward voltage drops of .292V, .309V, .330V, .358V, which is a wide range. The highest was in the bad circuit so my suspicion is the diode. Robert took the bad board for testing.

CT 729 tape #3. This was reported to not unload, and it was not unloaded. I was able to load and unload it several times, so this seems to be a transient problem.

DE console lights. Samuel and I were comparing CT and DE to see if it was normal to have a word mark on a character read from a card. (Yes, if you're using the 80/80 list, it doesn't clear the word marks out of the read buffer.) We noticed the C bit was not lighting up. To make a long story short, we replaced 4 bulbs, one of which immediately failed, but now the bits all light up. I don't know if this is a higher failure rate than expected.

029 keypunch in the back room, connected to the PC. I took a look at this and found a few problems. It is stuck in numeric mode unless you hold down alpha. The ribbon is stuck and dried up, so it doesn't print. I couldn't find which program on the PC will operate the punch. Stan, do you know the status of this machine?

CT reader checks: I talked with David, Samuel, and Robert about the reader checks on CT. David thinks that the timing looks okay so there might be a problem in the 1401. I'm thinking about what we could instrument in the 1401 to find read problems. To see the signals from the brushes, we'd need to solder wires onto the paddles under the core memory. (The DE has a few of these wires added by someone in the past.) Logging this data would give the clearest indication of what is going on. I could also look at the data as it comes out of the core memory for processing during the read, which would be easier to obtain but harder to interpret. If this raw data is right, then we'd know the problem is in the 1401. So I'll see if I can come up with a plan for next time.

Ken

CT 1402:
We looked at the Reader and Check brush timings and found that they were spot-on. The "all-fives" deck ran flawlessly after the machine had been run a bit, so we looked at the Check brushes (yet) again. We found that the interposer connector plate was a bit loose on the low-numbered column end, so we removed it for service. We found two brushes that had errant bristles, so we replaced them. We also found a good sized divot in the carbon roller. After replacing everything we still had Reader Checks. So next week I recommend we revisit measuring the resistances from each brush to the common brush, this time with the rollers spinning. We can do that with a constant current source and a digital scope, and can access the connections via the RC connector at the rear of the machine.

That's it for this week.

DC

The loose interposer board on CT1402 read check was producing consistent errors on brushes 1-10. Adding briefly to what David already said: after we fixed it up, the read checks did indeed persist, however with some improvement and differences. The read checks were consistent on brush 30, 31, 50 and 51. However, a bit later on I ran a quick BigPrint for a couple Apple execs prior to shutting everything down and it ran through perfectly with no read checks ...

Also, to note, we ran a deck of all blank cards to ensure that the read checks were real and not originating from the 1401 somehow. That test resulted in no read-checks, proving that indeed the problem is 1402-related, as Ken suspects.

The divot in the read-check carbon roller is quite egregious and hits on row 13-14, however, scope tests show that it doesn't seem to affect conductivity in any measurable way.

We also attempted to chase the loose wire on the (CT1402) cams but it *seemingly* led to the STOP button... but further testing couldn't directly connect the wires via the multimeter. So, that remains a mystery for now.

~Samuel Plainfield

P.S. - With the Apple folks visiting, don't forget to remind them that removing important connectivity like USB-A ports and headphone jacks isn't innovative, "courageous" or an upgrade, it's a downgrade.

This cabinet contains our inventory of good spare relays, it is located in the lab.

Permissive Make Relays
   8 6-Pole and 8 4-Pole relays in the cabinet
I have an additional 3 6-Pole relays in repair.

Wire Relays
   4 6-Pole and 4 4-Pole

Each repaired relay has a green identifying label on the top.

John

1. I traced the punch check issue to a bad card on Saturday and replaced the card. The card tested fine so I put it back in the machine and the punch checks are still gone. (I can't reproduce them by putting a bad value in the B register.) Perhaps the contact with the card was bad? The card is 01B4-E23 CQZV 36.22.11.2.

2. The card reader also had Reader Stop problems. It would hang up on the first card or read a few cards and then stop. Marc went through the card deck and found some marginal cards. Removing them helped a lot. He also adjusted the throat and that also helped feeding. It now feeds more reliably.

3. DE 729 #1 has been unable to load for a while. The problem was that relay 107 should drop, but it stayed latched. (Unlatching it by poking it manually permitted loads to work.) I swapped the relevant relays with no effect. Marc noticed one of the contacts in the socket for relay 111 was bent. He fixed the contact and now the drive is back in service.

4. The Go Down Time knob in the TAU panel had come completely loose. Marc fixed this while I watched :-)

Ken

I may have some troubling news: Sam hasn’t reported this yet, but late yesterday afternoon we fired up the DE 1401 (to demo it to some delightful Danish visitors*), BigPrint would not load. The 1401 panel turned red, including the PUNCH check light (and the B register). After 4-5 attempts, it finally successfully loaded (and PowersOfTwo, but not again after they left.)

I’m wondering if you might want to reinsert in the replacement CQZV card and take a second look at the (likely) faulty one? Perhaps one of its transistors is marginal or has a loopy I-V curve (hard to spot w/o an I-V trace)?

— Robert

* The Danish visitors came into the 1401 Lab after a Samsung event. They had never seen/heard of a 1960s computer and were gobsmacked with our setup. When I asked if they might guess the 1401’s memory capacity, it was beguiling to hear their first guess: 5 megabytes!! :)

I proposed to the team that we do a full-court press effort on the 1402's cams, much like we did for the relays. It's not so much that we suspect a bad cam, but if there was a bad cam we wouldn't know about it until we looked. So we set about isolating each cam in turn, carefully measuring its ON resistance, and noting its make and break angles for each lobe. We did each measurement twice to get a little bit of an idea of the cam's repeatability, and of course rechecked any value that fell too far away from the expected value.

We started using the milliohm meter, but found that its response time was rather slow which made finding the make/break events difficult. So we settled for using the ohmmeter on the blue DVM. It proved to be sufficient for finding gross contact problems.

The data are summarized in the attached spreadsheet.
SpreadSheet as .pdf
Two limit value cells at the bottom of the sheet drive the conditional formatting that highlights out-of-limit cells. The executive summary is that we found two cams with high resistance contacts, and the timing of most of the cams was reasonable. We were able to clean the high resistance contacts and bring them down to values similar to the others, so this alone was worth the effort.

Mark discovered a free-hanging wire in the cam area that looks like it ought to connect to one of the cams. We checked the actual number of connections to each cam terminal and compared them to the schematic. All wires seem to be present and accounted for, but next week we will try to trace this wire to see where it goes. Mark agreed to bring in his wire tracer, and I will bring in mine. Marc suggested that these tracers might not work well with the machine's wiring harness, but we'll give it a try. We could also remove each relay and check its socket for continuity to the hanging wire, since it is likely that if the wire really is supposed to be connected, it would go to a relay.

1042 Reader Checks:

After collecting the cam data, we ran an "all fives" deck to check the Reader brush health. Once again, brush #3 was showing problems as did one of the middle brushes. So we swapped the wires that connect to Reader brushes #2 and #3 and reran the test. The problem stayed with brush #3, meaning that the brush itself must be the problem. Since we've replaced brush #3 several times already, we had a look at the carbon roller. I tried resurfacing the roller with some 600 grit abrasive paper, under power this time. It was a little tricky avoiding having my fingers ingested by the running machine, but I was able to escape unscathed. After cleaning the roller with alcohol, we repeated the test and found that there were no errors. Hooray! So we did the same procedure on the Check roller, but unfortunately we still got Reader Check errors.

So we removed the whole Check brush assembly and took it to the workshop. We replaced/readjusted about six brushes and reinstalled the assembly into the machine. Subsequent testing gave some anomalous results, but we didn't have time to debug them.

So next week we'll look into those anomalies. And I think it would be a good idea to have a look at the brush timing using the scope. It would probably be a good opportunity to install the new solar cell code wheel for the brush timing check.

Tape Emulator PC:

Finally, the replacement caps for the Tape Emulator PC motherboard finally arrived, so I will replace them this weekend.

DC

That's it for this week.

CT1402:

After the check contact roller was complete, I/O check was turned back on and the 5's deck was tested again. The reader checks persisted but this time in a strange manner:

~ Switching to Storage Scan, the first brush that registered was 107 and CHECK RESET lit up. 107!

~ Pressing START, the second was 077.

However, pressing START again after that to see what more brushes were problematic would not work and the display would not change after 077. The CHECK RESET light stayed illuminated, preventing further data from showing. Pressing CHECK RESET would restart the 107, 077 loop.

This behavior is not standard per the manual as far as I know -- I'd like Frank to take a look, assuming this behavior repeats next week.

DE1402:

Towards the end of the day, Robert and I were doing some tests and the 1402 resumed having some punch check issues with an OVERLAP error in tandem. Eventually, all of that stopped altogether and the 1402 wasn't appearing to send any data at all over to the 1401. That is, pressing LOAD wouldn't pull cards and the OP code register would remain completely empty on the display. (Also, the rollers would stop running immediately when the LOAD key was released.)

What might cause the 1402 to not send these hardcoded signals over to the 1401?

That's all for now.

~Samuel Plainfield

Summary

• CT was funky but worked - thanks to the Restoration Team!
• Great audience engagement with questions that were great lead-ins to what was coming up (e.g., how is the 1401 connected). About 12 visitors hung around to continue to ask more questions after the demo.

Microphones: OK
Keypunches: The one nearest the closet would not feed cards.
Sorter: OK
DE: The morning crew said DE was not working, so we did not try it.
CT: Tape #1 had a problem. Tape was wrapped around the back of the hub on the input reel. The reel was removed and left on top of the unit. The bad part of the tape was discarded. Pressing the reset button would not stop the tape movement.
The unit would not unload. We set it to inoperable. Tapes #3 and #4 were inoperable, so only #2 was working.
The reader stopped reading cards sometimes, but we were able to make it work again. The printer worked OK.

Stephen H. Madsen

Details:
The symptom was that DE sometimes came up in a state with a punch check and was unusable. Pressing Check Reset on the punch would clear the check while the button was pressed, but then it immediately came back. This problem was random. Sometimes it would happen for hours, and sometimes it would go away for months.

The punch check circuit is complicated. Normally a punch check happens if the read brushe hole count disagrees with what was punched. However, there is a second way to get a punch check: the mysteriously-named "ALLOW B REG CHECK". What that means is a parity error in the B register. The motivation is that if there was a parity error in the B register while doing a PUNCH SCAN, that indicates a corrupted value, so it triggers a punch check.

This check should only happen when you're doing a punch scan, of course. But the PUNCH SCAN signal was erroneously asserted, which explains the mystery of why punch errors happened when the punch wasn't being used. I found that card E23C (36.22.11.2) had a voltage of -6.2V. I assumed this was okay, but then I took a closer look. This signal is +U so it should be -12 V or 0 V; it was outputting a bad voltage right in the middle, which was being interpreted as high. I replaced this card and the punch checks went away.

How to reproduce and clear the punch check error.
The punch check happens if the B register powers up with a parity error, which is why this problem was intermittent, but also didn't go away once it happened. However, if you load a good value into the B register, the punch check can be cleared: Steps: switch to Alter, put toggle switches to a valid value (e.g. one switch to the left), press the B AUX REG button, toggle the ENTER switch up, switch back to Run.
And if you load a bad value into the B register, the punch check returns.

The one loose end is that I couldn't find any problem with the bad CQZV card when testing it at home. I'll do more testing next week to see if I can get a smoking gun here.

Unfortunately, DE still has other problems. It sometimes doesn't feed a card (picker knife problem?) and it sometimes gets bad data in the B register which triggers the jackpot of error lights: PROCESS, READER, OVERLAP, STORAGE, and B. I thought there was a problem with the parity calculation, but I discovered that my oscilloscope's input #1 was somehow in Invert mode, so all my measurements from Wednesday are suspect. (This explains the mysterious +10 V signal from an SMS card that doesn't have any power above +6V.) So I'm unsure if parity is getting calculated wrong or if the B register has genuinely bad data.

Main lesson: don't assume that -6 volts is a correct low signal. Check if the signal is a T or a U and verify the voltage. For reference, here are the voltage levels:

Ken

Thanks for coming in today to find and shoot the nasty and tenacious DE punch check bug!!
       (I trust you might be able to sleep some now. :))

— Robert

These errors (at least 1 and 2) have happened intermittently for a long time. They showed up long enough for us to do a bunch of debugging.

Conclusions:

1. The B register was valid CB421 but showed a parity error. We traced through the complicated parity logic (35.30.21.2) and measured all the voltages. The output -T Allow B Reg Check is -5 (error). The inputs to 01B6 C17 all look correct, but the output is wrong. So either this card is bad, or something is pulling the output low. If there is a parity error, it will trigger errors in various subsystems (Process, Reader, Overlap, Storage), which is what we see.

2. The non-resettable Punch Check error showed up a couple of times. In this case, the console showed that the B register was genuinely invalid. If I used "Alter" to fix the B register, the punch check could be reset. The B register parity signal is one of the inputs to the Punch Check. (You can get a Punch Check if the brushes don't match, but also if there is a B register parity error). The logic is supposed to gate this so you only get a punch check if you're punching. So I suspect there is an additional problem with the gating logic, that trips the Punch Check if there is a parity error, even if not punching.

3. The latch for the B reg error light is behaving strangely 35.30.31.2. We see the parity error signal into the B Register Chk Latch, which should set the latch and illuminate the light, but the light wasn't illuminating. The light works sometimes, so it's intermittent. We measured +10 V on the parity error signal (01B6 C22 D), which is not a valid voltage. Then it suddenly switched to -10 V. It's possibly measurement error, but I measured +10 at several points. So this is kind of mysterious.

My conclusion is that there may be three separate, but overlapping faults, all involving the B register parity. The problem with parity computation is the most important issue. The problems are intermittent, which suggests temperature, a bad contact, shorting wires, marginal voltages, or something like that. The machine seems to start off with faults and then improve with time.

Ken

Since replacing the relays seemed to have little effect on the CT1402 card mangling problem, I thought I'd have a look at its cam timings. I used another of our Tek 2230 storage scopes to examining the cam waveforms. The scope worked fine and allowed me to capture the timings of all of the cam make/break events. They are summarized in the table below:

I used the Solar Cell to trigger the scope, then used the scope cursors to measure the time to the various make and break signals. Because I know the theoretical angular spacing between them, I used the time between the first two solar cell pulses to calculate the machines actual rotational speed, which I then used to convert the scope time event measurements into machine degrees. The "target" values were pulled from the timing diagrams in the schematics, and the Error values are the differences between target and the actual event angles. You can see that some of error values are huge whereas most are not. I think there are a couple of factors to explain this. One is that a small error in the velocity calculation can translate to a fairly large error in calculated event angle. You can see that even the solar cell pulse itself (bottom row) has appreciable error. Second, the cam signals are often qualified by other signals, either cams or relays. In fact, several of the cam waveforms show only one make/break event pair per cycle, even though they are 3-lobe cams. Without electrically isolating each cam and driving it with a steady-state bias voltage, the cam terminal waveforms do not always show the make and break events of the cam itself. So we will need to dive a little deeper into these cam waveforms, possibly adding a small bias voltage to help reveal the actual cam events. That might just warrant me getting that new scope...

Tape Emulator PC:

I found and and dismantled the PC we use for the tape emulator, and will order and install replacement motherboard caps for the ones that are obviously failing. Shmuel agreed to image the drive for safety, so I left it on the "relay" workbench.

I also had time to open the Tek 465 scope in the workshop to find out why its DM44 voltmeter option's LED display isn't working. But when I measured +12.8 volts on the +5V rail of the LED driver, I gave up. The (evidently shorted) regulator responsible for that rail is somewhere deep in the scope, so it would take more time to fix than I had available. Also, since the scope itself is working, I felt that it wasn't worth the risk of breaking it in an effort to fix the voltmeter. We have other voltmeters.

That's it for this week.

DC

Just like we have now pretty much eliminated 1402 relay problems by refurbishing and carefully testing them all, I'd like to propose we undertake a similar effort on the cams. I'm thinking that a good strategy for that would be to one-by-one disconnect and isolate each cam (with the unit powered off, of course) and use the milliohm meter to check their contact resistances, and at the same time note their make and break angles using the degree scale on the Dynamic timer. There are about 12 cams to be checked, so even with a few of us working, it will take several hours to complete the task. So let's find a time when both the machine and the milliohmmeter are free and schedule this task. I'd also recommend that we go ahead and replace the solar cell code wheel because we can, and then re-time it against the brushes. We have not checked brush timing in months. For that we'll need the digital scope. It would probably be best to hold off on this task while Ken works on the DE 1401 parity issue, since he'll need the scope for that. Fixing DE's parity is certainly a higher priority.

DC

Frank

I brought in my scope, so we can work on both problems without scope contention.

Ken

Following up on: " Shmuel agreed to image the drive for safety, so I left it on the "relay" workbench.".

Done.

1. Instrumentation: IDE to USB (pic attached).
2. As expected file system copy resulted in lacking read permissions to certain directories. Avoided any changes since would have changed the disk image, and assuming David repairs the motherboard it should just boot and work properly. (see attached PDF for file system content)
3. Created two (2) disk images:
      (a) bootable on any Windows system
      (b) Data image only (none bootable) for ability to transfer bit image to any media.

Will leave all back on the relay repair station on Saturday.

Best regards,

Shmuel Shottan

Likewise, if you can't remember the credentials, I oughta be able to bypass/crack those also,

~Samuel

Jack Ghiselli
jghiselli@sbcglobal.net mobile 1-408-839-1051

I very much like the tabular format since it makes it easy to visualize the health of the individual system components. The color coding is a nice touch! It would be even more useful to have separate cells for the DE and CT components to help us prioritize our repair work. DC

I originally had separate columns for CT and DE but thought it was cumbersome. If others like this format, I’ll redo it in to make it easier for the Lead to write and for this distribution to read with special consideration for the Restoration Team.

Not sure if we need to standardize on a format though. Could be a Lead’s choice.

Larry

All 3 keypunches were used. The printing from #2 was light.

CT was used. There were a few read checks, but I don't believe there were any other problems with the 1402. Tape drives 1, 2 and 4 were used with no problems.

Jim Maurer

IBM 026 keypunches #1 and #3 worked well; #2 printing was very light despite an effort to reverse the ribbon direction and advance it well past the initial segment. Both microphones worked reasonably well.

While setting up before the demo we found that DE tape drive #1 wouldn't load. #2 had tape jammed in the supply reel. Jack and Scott cut off the damaged tape and applied a new load point marker. We prepared two tapes on CT and Scott used them for the demo. Given the large crowd there was no possibility of moving them from DE to CT for the tape demo. I pointed to parts on a drive on DE as Scott explained them so that that half of the room could see better.

We ran most of the demo on DE. It ran BigPrint fine. For the tapes, we elected to use the CT drives. Pat

Reports from the demos continue to indicate that the CT 1402 has relapsed into its old habit of mutilating cards. So we set about to find out why.

I tried the familiar test whereby a NPRO is initiated with Card Lever #1 depressed and discovered that unlike the DE machine, CT no longer exhibits the expected repetitive clutching behavior, but instead runs one and only one clutch cycle during the NPRO. The lack of this repetitive clutch behavior has correlated with card mangling in the past, and although it is by no means a definitive test, it is all we have to go on to track down the card mangling problem. And it is a realistic expectation that the machine would need to run multiple clutch cycles in order to purge its entire card path.

We began by replacing relay after relay with ones that had been refurbished and certified using John's new milliohmmeter. After replacing all of the relays that seemed relevant to card transportation (Arda has the list,) the behavior was unchanged. So we changed tack and started looking at the clutch handshake signals at the 1401. The idea is that if we can figure out which signal actually kicks off the first clutch cycle, we might see if it is also supposed to start the (missing) subsequent clutch cycles. Arda has come up to speed on mapping the location of signal nodes inside the 1401, so he was able to put a scope on the 1401's clutch drive output signal -T READ CLUTCH, and some of the 1402 output signals we suspect instigate NPRO clutch cycles. We were able to observe activity on -T NON PROC FEED and -T RD COMP GATE, but -T READ CLUTCH showed activity before there was any activity on either of those two lines. So there must be some other signal/event that causes the initial activity on the clutch drive signal, or else we somehow missed the initiating event on the signals we looked at.
Unfortunately, we ran out of time to finish this experiment, so hopefully we can do that next week.

In parallel, I set about trying to verify the cam signals for both timing and signal integrity. However I was only able to discover that our Tek 2230 storage scope on the cart needs repair: in 2-channel mode, it adds Channel 1 and Channel 2 despite the position of the Add/Alt/Chop switch. Verifying the clutch signals almost requires the use of a storage scope, so we'll need to schedule this effort around the availability of our modern digital scope. Or maybe this is the excuse I need to buy one of the spiffy new Rygol DHO804s I've had my eye on.

Finally, I had a thought that we may be able to easily and non-invasively determine the state of a relay by probing its magnetic field. Sure enough, when I placed a SS41 Hall Effect sensor near the center of a relay's coil on the bench, it reliably indicated the state of the relay. This would be an ideal way to determine the state of a relay because it provides a fast, isolated, TTL-compatible signal compatible with modern test equipment.

In the photo you can see the sensor peeking out from beneath the orange spring clamp (the clamp being necessary because our instant glue is anything but instant.) I haven't checked if both pick and hold coil energization can be sensed, but the odds are pretty good that we can find a sensor that can. If this works, we could add sensors to all of the relays and connect the TTL signals to a conventional logic analyzer (which I believe we have). We could then record different card processing sequences, and compare the CT and DE machines' relay signatures for consistency. Similarly, adding opto-isolated metrology to the cam signals and the three card levers would allow us to monitor and log the machine's complete state. Having a complete state transition map would be a huge benefit to understanding not only how the machine works, but what is happening when it doesn't.

I also discovered that the Tek 465 scope in our workshop actually functions, although its DM44 voltmeter seems to be broken. So I put it atop the bench where John has been testing relays. And the other two scopes in the workshop are toast.

That's it for this week.

DC

I looked at the DE 729#1 failure to load. (Symptom: when you press Load/Rewind, the prolay clicks but nothing else happens.) Last year, Marc and I found it suspicious that relay 109 is non-latching, since it is latching in all the other relay 729s. I found the manual for this specific drive and it turns out that this drive has a slightly different circuit for no apparent reason and the relay is supposed to be non-latching, so the relay is correct. The problem appears to be that R109 is not getting dropped, blocking the vacuum pump from starting. It looks like R102 needs to drop, but I didn't investigate further because the punch check returned.

Punch check: DE kept getting punch check errors when reading cards. This is different from the previous punch check in two ways: First, this punch check can be reset. Second, this punch check is accompanied by lots of error lights: reader check, storage check, overlap check. So something seems to be going catastrophically wrong. I started measuring signals with the oscilloscope but didn't get too far before the punch check disappeared and BigPrint ran successfully. Hopefully DE will keep working for the demo.

Ken