While setting up for the demo I found the missing lock for the gate by the DE 1302. It was hung on the side of one of the card trays.

All of the 026 keypunches and the 083 sorter worked well. Both microphones worked well after changing batteries.

We ran on DE. We ran BigPrints successfully before the demo. Unfortunately, attempts to load it again during the demo were unsuccessful. The symptom was load failure about 15 cards into the deck. Using another BigPrint deck solved the problem.

Jack Ghiselli and Larry Hara dropped by and were also very helpful in taking care of all of the BigPrints we did after the demo.

Happy New Year to all.

Pat

DE 1402 ate the cards after we rebooted it after a reader check error. This time it had multiple lights on including reader check, reader stop and validity check. The first two cards were stuck inside and wouldn't come out even after the Non pro run out button was pressed. We opened the cover and removed most of the cards carefully. Yet still there were some leftovers pressed under the rollers. We used the CT 1402 and it worked pretty well. We used the CT 729 #1 and #2 and they worked great. ,p. Both of the microphones worked well after we changed the batteries before the demo.

We worked today to determine if there is enough hardware working now to try building a tape-loadable demo.

I tried all the 729 drives on DE, but none would run with the Ron 2.1 Tape Exerciser software. One drive wrote a few blocks, then the software hung with very strange behavior on the DE1401 front panel. Also, the IBM PC used with the Tape Emulator is not working, so we can't transfer our ROPE-assembled demo object files.

So, move to CT. According to Sam Plainfield, the Restoration Team has got the CT1402 fixed to the point where it will sometimes read cards, as long as you run with I/O CHECK STOP turned off. This setting prevents spurious READ CHECK conditions from stopping card reading. Of course, it also means that some columns in a card are actually mis-read, then incorrect data will be entered into Core Memory. However, from the test runs Sam showed me, this is relatively rare.

We were able to load the Ron 2.1 Tape Exerciser card deck on the CT1402. Tape Drives #3 and #4 (Left-most) wouldn't run. One wouldn't load and the other wouldn't switch to LOW DENSITY. Drives #1 and #2 did run under the Ron 2.1 software control.

Then we looked at tape statistics. Tape Drive #1 was able to write 4845 1000-charcter blocks before detecting the end-of-reel reflective spot. This is a reasonable number. Since we use LOW DENSITY (200 bits/inch at CHM), each block is 5" long plus an 0.75" inter-block gap, so the total length of tape used is about 2321 feet, just a little shy of the nominal 2400-foot reel length.

Error Rates: The Ron 2.1 program checks for Tape Write Errors, backspaces and re-tries three times, and for persistent errors does a skip-and-blank to avoid bad spots on the tape. Tape #1 encountered 185 write errors while writing 4845 blocks. Not great, but possibly good enough to build a demo tape.

Tape #2 was much worse, encountering 2746 Write Errors while writing 2094 blocks. (Due to retries, it's possible to get more errors than blocks written.)

It also appears that the IBM PC attached to CT is operational.

In summary, it looks like next week we could try to build a tape-loadable demo. We'll need the CT1402 (to run SERVER), one working Tape Drive, and the IBM PC and PCWRITE system. It would be good to clean the read/write heads on the CT Tape Drives #1 and #2 first, hopefully to reduce tape errors. I'm not very good at that, so I'll try to get somebody to help me with that next Wednesday.

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

- from Marc Verdieli

We are keenly aware that the tapes don’t work. I would not run Ron’s exerciser. It’s very hard on the tapes, the drives and the prolays.
Marc

Kind regards,

Arda

Arda Ugur (Left) and Samuel Plainfield	pointing out to a missing print of 5 which indicates an issue with the brush #3.
both showing complete print of 5s after swapping brushes #3 and #6

I was the lead today and Scott Stauter was the operator. Sam Plainfield and Larry Hara were backup operators assisting with punching name cards and running bigprint.

We had well over 100 visitors attend the demonstration. There were also quite a few people before and after. There were at least 50 who came in afterwards to punch a card and get the output. I do know that we had people from India and China. I apologize that we don’t have more accurate counts.

We used all 3 keypunches, and they worked fine.

We used DE for the actual demo. Tape drives 2 and 3 were used and had no problems. The DE 1402 behaved reasonably well the whole time, with only a few read checks that were cleared in the normal manner. There were no problems with the either 1403.

After the presentation there were a lot of people who wanted name cards and get their output from bigprint. Sam Plainfield and Larry Hara were of great assistance in us getting most of the crowd cleared out in about 20 minutes. Sam had loaded bigprint on CT before we started, so we used both systems at the same time. It was very loud with two 1403s running at once with their lids open! After most of the crowd was gone Larry used DE to work on some other things and we used CT for the bigprints. Everything was going fine until one boy asked me if he would be getting his card back. I told him yes, as long as the card reader doesn't eat the card. But I said that hadn’t happened so far today. So, what happened? Well, the CT 1402 ate his card! Sam fished it out and the boy punched another card. We then reloaded bigprint on DE and used it until we closed. We got the room finally closed a little after 5 pm.

Mic 1 was working fine at first, but after a while started cutting in and out. Mic 2 had no problems.

Jim Maurer

I forgot to mention something. When we were locking up we could not find the combination lock for the gate at the DE end of the room.

I started out the day hopeful to clear the CT1402 of reader checks. Performing an All 5's check, Arda and I noted that read brush #3 was still intermittently missing prints. I made a very minor adjustment by having the #3 read brush stick out ever-so-slightly more.

This improved the print significantly, but didn't cure it completely. Arda suggested we swap the brush entirely with a known working brush; so we swapped out brush #3 with brush #6 and the new printout was perfect.

With the read brushes in excellent shape, BigPrint was loaded for the 3pm demo and the reader worked perfectly fine with I/O check off for most of the day. Prior to the start of the demo, testing confirmed that read-check brushes #30, #50, and #51 remain the consistent problem brushes that need attention.

Due to the enormous crowds, both 1401's were running most of the day until 4:30 or so when the CT1402 started crunching cards again. I performed our standard N-PRO card-lever test and sure enough, the clutched roller behavior wasn't "stepping" the way it should. So, we'll need to revisit the relays.

Larry handled a huge crowd for his 2pm docent tour and kept everyone rapt:

That's about it for now folks,

~Samuel Plainfield

We used keypunch #1 for the demo. After the demo, all 3 keypunches were used but #2 did not feed consistently.

Duane ran the demo on DE 1401 and it worked well. However after the demo, there were a few reader stop and reader check errors that went away upon reset.

Tape Drives 729 #2 and #3 were used for the demo. However, #3 would not unmount and we had to power down in that state.

Post-demo, I had the unfortunate horror of dropping Powers of 2 and some of the cards are out of order. I noted this on the deck but will restore it on 12/27. I've never had this happen, even as a college student running my FORTRAN IV programs!

Post demo extra-curricular activities

I'm still working on the punchcards and will organize the bins. Will send a report upon completion.

Read-check common brush before adjustment.

Read-check common brush after adjustment. This week, despite the above adjustment from last week, the reader checks continued and the CPU insisted still that every read-check brush was causing an error. So, today, we removed the read-check brushes to give them some overdue maintenance.

All told, the brushes aren't that bad. As you can see above, it is obvious when a brush is bent under heavy magnification; I replaced six or so brushes, made myriad adjustments and burnished the edges.

After reinstalling the brushes; no difference was observed. So, we went to replace relay #12 with a known good relay. Unable to obtain a known good relay, we set out to quickly clean one. The pins look great all shiny:

Cleaned v. dirty pin.

Replacing the relay changed the behavior of the machine. It would no longer report every read-check brush as a source of error. It was, however, showing read brush errors on brush #3, still -- this has been an ongoing issue. The CPU would show the data read erroneously as either a check-bit or a word-mark where it should show a 5. Read brush #3 was seated rather oblong vertically and it is important to note that it has been replaced multiple times already...

After some extensive work checking the resistance of each brush on a makeshift contact roller, the read brushes were reinstalled and an `All 5's` deck was printed. Read brush #3 still exhibited some missing data. Good news, however, is that all the rest of the columns continue to print perfectly.

It got late, so we'll pick this back up next time.

Scott Stauter brought in a big box of vacuum tubes that we added to our collection ~ thank you, Scott!

That's about it for now,

~Samuel Plainfield

PERMISSIVE MAKE

Our 1402 uses Permissive Make relays with 20-volt coils, which are color coded Yellow. The reader punch at Yosemite, we use for spare parts, uses 48-volt coils.

Last week Marc and Arda rebuilt 4 permissive make relays, David used a 4 wire HP milliohm meter to QA that the contacts were less than 2 ohms.

Our total inventory of spare permissive make relays is shown below.

The important thing is that we probably have enough 20-volt coils (17), and there are many more Permissive Make relays with higher voltage coils that can be used for parts.

WIRE RELAYS

I collected spare Wire Relays (from boxes of many) including both good and bad.

Pages 2-2 and 2-5 of Field Engineering Maintenance Manual S225-3422-1 cover these wire contact relays. It suggests “Wire contact relay adjustments are made at the factory and have been found to be very critical. Faulty relays should be replaced and not adjusted in the field” .... “If a replacement relay is not available the following service checks may be made .....”

Yesterday I used the method demonstrated by Marc and Arda (MagneZc Tape wired relay cleaning) to clean the contact wires and contacts for 8 of them and got similar improvements in resistance. In this approach the “tension plate” is not loosened which makes replacing the contact wire more difficult.. Not changing this plate adjustment may leave other parameters OK.

Our QA procedure for these relays is yet to be determined, one idea is that a contact resistance of 5 ohms would be reasonable. Only 7 of this group of relays were above 5 ohms and cleaning them was effective.

It is my plan that this container will be used to store spare QAed Wired and Permissive relays.

While the subject of this report does not qualify as a restoration effort at any level, it is being communicated as such. This week, David and I did a little cleaning and organization in the restoration workshop. I also did a make-shift base for the lighted magnifier glass – which we hope to be a nice aid for certain bench tasks, such as cleaning relays.

Please see the attached photos.

And Happy Holidays.

Sincerely,

Arda Ugur

Frank

CT 1402 had the said consistent reader check problems so we switched to DE where we ran Bigprint successfully with Jack's magic touch to help us remove the punch error problem. The keypunches and sorter worked fine. We ran tapes on CT with the third from the left being flipped on inoperable from last time. The 1403 printer worked fine.

The 2nd mic was out during the middle of the demo and Jack did a hat trick and changed the battery on mic 2. No problems with both mics later on.

Please remember to return the 1401 Lab room key chain to the audio room drawer next time.

Re: Battery not charged.

When I started to replace the batteries in the mics there was only one set of batteries in the charger. Please do not let that happen again.

Paul

All three 026 Keypunches ran fine. The 083 Sorter ran, but Jim had to press down on the card weight to get it to load cards continuously.

After the demo, I tried to run the Ron 2.1 tape exerciser software on DE. DE 729 #1 would not load (reported previously). DE 729 #2 hung trying to write to tape. DE 729 #3 moved the tape, but got a persistent tape write error (even at LOW DENSITY).

We had some erratic problems with Microphone #2. In the middle of the demo it stopped working. Then later it miraculously recovered. We tried swapping out batteries and loading disposable AA, but that did not fix the problem.

Karen Sun was interested in learning more about the 1401 Front Panel. I sent her the link to the main 1401 reference manual on Bitsavers. If anyone else wants it, the link is https://archive.org/details/bitsavers_ibm1401A24pr62_26351623/page/n1/mode/2up The file is about 25 MBytes, so it's a little large to email.

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

Karen, Jack,

> Karen Sun was interested in learning more about the 1401 Front Panel.

Marvelous!
Fyi, Ken Shirriff authored an explanation of the control panel here (including an undocumented feature):
"The 1401 console:" https://ibm-1401.info/KensConsole-1.html
(He noted that pages 109-118 of the 1401 reference manual thoroughly describe the console.)

Fyi, Fran Underwood, the 1401 architect (and an amateur painter at home), personally designed it.
It’s one of (only two) classic computers that I know of with its data paths emblazed and illuminated on a front panel.

Here’s the panel's design history:
Evolution of the 1401 Control Panel - https://ibm-1401.info/Evolution1401Panel.html

> I sent her the link to the main 1401 reference manual on Bitsavers.

There’s also a (10.8-MB) scan on our 1401 website: https://ibm-1401.info/A24-1403-5_1401_Reference_Apr62--.pdf
Fyi, we have several original manuals in the workshop if you prefer retro paper. :) Fran autographed one of them.

Btw, the reference manual was written by Jan Barris (nee Swanson) …
https://ibm-1401.info/1950sTeamBios.html#Swanson
She’s the woman in our 2009 founders photo,
https://ibm-1401.info/1401Founders_CHM_Nov2009-.jpg
… here seated next to Fran Underwood in our 2009 "50th anniversary of the 1401” speakers dinner:
https://ibm-1401.info/Pics3/50thReunionSpeakDinRG-07.jpg
Here’s her story about authoring it,
https://ibm-1401.info/SwansonJ-The1401ReferenceManualStory.html
... and her "IBM 1401 Makes its Debut in San Francisco” anecdote (she had to quickly convert a 4K demo program to run run just 2K):
https://ibm-1401.info/OtherStories.html#SF

Cheers,

— Robert

Right before the demo the restoration team handed over the CT 1402 reader saying it might work well enough to use, and indeed we were able to load and run Bigprint. But later in the demo Sam could not get it to load another deck so he switched to DE where we ran both Bigprint and Powers of 2, and after the demo for one particularly interested visitor Sam also ran Lincoln. The keypunches and sorter were all fine. We ran tapes from the TAU on CT. The third drive from the left had a problem. The movement of the tape in the right column was erratic and after a short time it dropped all the way to the bottom of the column and the drive stopped. We unloaded it and tried again, but it behaved the same way so we took it offline. All the other three worked fine.

The audio system was great (after Sam changed out the batteries on mic #2. No problems even with both mics on at the same time.

Tim Robinson

I had noticed that once for the tape. Oxidized vacuum contact in the right vac column would be my guess.
Marc

Details: Marc and I looked at DE 729 #1 which doesn't load in various intermittent ways. Problem #1: much of the time, when you push the Load/Rewind button, nothing happens. The neon panel shows that relay R111 doesn't activate. Swapping R110 and R111 didn't help. Jumpering the Load/Rewind switch makes no difference.

The circuit driving R111 is a bit complicated. On the right, the relay coil is pulled to -48 through R110-2. On the left, the relay coil is pulled to ground through a bunch of SMS cards controlled by the Load/Rewind switch and relay R7BL. Marc measured -48 on both sides of the coil, indicating that R110-2 is closed (good), but the relay is not getting pulled to ground (bad). Relay R7 is visibily closed, but Marc cleaned and checked the contacts to make sure. We started to look at the SMS card circuitry but the problem went away and R111 started working.

So it seems like something intermittent in the drive's SMS logic, which combines 5 different signals to enable R111. Any of these could be the problem.

Problem #2: If Problem #1 goes away, Load/Rewind will activate a bunch of relays and the prolay but the vacuum doesn't come up and the load doesn't happen. Sometimes when the drive is in the Problem #1 state, pushing Reset multiple times will get it into Problem #2 state, but not consistently. Here's a photo of the neons while pushing Load/Rewind showing that a lot of relays get activated.

The problem seems to be that relay DP4 is not picking to turn on the vacuum motor. It gets turned on when R109 drops, but the neons show R109 active. According to the manual, R109 should be a latching relay, but in the 729 #1 it is not a latching relay. As far as I can tell, we don't have the exact manual for the DE #1 drive, so it is possible that they changed the relay type. Or maybe the wrong relay got put back at some point. Very mysterious.

Second topic (unrelated): the CT's half-write wiring from the card reader brushes to the row bit cores. I continued last week's investigation. CT has the 330 ohm resistors showing that it has half-write, but there isn't much documentation on how half-write works.

In the 1402's brush driving circuit, transistor T2 pulls the brush common up to ground, providing current through the brushes, resistors, and cores, which are connected to -20V. In a normal 1402, R11 is connected to -20, but in CT's 1402, R11 is connected to connector RC 190 (1/2 write) which is connected to a pin on the core plane. My two questions were where does that pin go, and what provides the other half of the write current.

My current theory is that RC 190 goes to a core wire that goes through all the row bit cores and then to -20 V. This would explain both questions. When the solar cell turns T2 on, R11 will get pulled to ground. This would create current through RC 190 and the common core wire, providing half of the write current. When a brush makes contact through a hole, that will ground that brush wire, generating the other half of the write current through the specific core. The motivation is probably as Carl suggested, that this cuts the brush current in half.

The relevance of this is that when David and team are measuring brush current, the brush current on CT should be half of the brush current on DE.

Ken

Summary:

1. Discussion with David Clementson:

   Make cleaning 1402 Card Read-Punch machine relays’ contact wires an ongoing effort with the intension of cleaning up and testing conductivity of all relay units. For more detailed information on cleaning 1402 relay wires, please see the relevant restoration report from Wednesday, December 6th, 2023.
   @David, please let us know if I missed anything of that discussion.

2. Lab microscope light bulb update:

   Last week, we wanted to inspect the relay contact pins and wires under the microscope; however, the light bulb of the microscope light source was not perfectly centered and/or broken [as I could recall]. Marc V. upgraded the light source with a very nice LED. Please see the provided photos for the upgraded unit. But I must emphasize that the photos do not do justice how bright is the new light source.
   @Marc, thank you very much.
   

3. IBM 729 Magnetic Tape Drive [DE] #1 Relay Testing

   @Ken Shirriff was working on this unit, therefore I cannot say much about the background of the main effort. However, Marc and I worked together on cleaning and testing a relay from 729. The exercise was very similar to what we did for 1402 relays. While these relays are different in structure, the pins were observed to suffer from the same kind of oxidation and the cleaning methodology was the same. Please see the attached photos.

   IBM 729 Magnetic Tape Drive in question.
   

   Relay with removed pins.
   

   An oxidized pin before cleaning. Discoloration is very visible.
   

   The relay pin shown below was cleaned using steel wool.
   

   Once all pins were cleaned using the same method as illustrated in the previous restoration report, they were installed back in the relay unit and the conductivity was tested using a multimeter.

   The below photos illustrate the pairs of pins inserted back in the relay from top and side views.
   

   @Ken and @Marc please add anything you think should be stated here.

   @Marc, I also do not remember if you did or did not clean those relay pins. Please let us know if you did so – which should be written as part of the procedure.

Regards,

Arda U.

Arda,
The relay was entirely cleaned. You removed the oxidation on the wires using steel wool, and I cleaned the contacts using fine sand paper. The relay contacts went from ~100 Ohms to no measurable resistance with my meter. However that did not change the behavior of the tape.
Marc

Thank you, Marc, for refreshing my memory and the additional comment/confirmation.
Kind regards,

Arda

CT1402 card crunching:

When we looked at the card path, we found a crumpled multi-card pileup at Card Lever #2, the same place where we were having earlier crumplings. Sam reported that turning the machine by hand felt stiffer than usual and one of the pinch rollers was not turning, but I am quite sure this was due to the stuck cards. We extracted the crumpled cards and manually cranked the machine. It felt absolutely normal. I did the quick Card-Lever-1-during-NPRO test and found it was normal. Previously, a bad relay R12 cad caused this test to fail. We ran several cards through the systems with no crashes.

CT1402 Reader Checks:

We next turned our attention to the Reader Checks. When we ran the "all-fives" deck, we saw that Read brushes #3 and #34 were still giving unreliable results. So we decided to investigate the wiring between the brushes and the RC cable to the 1401. We unplugged the RC cable at the back of the machine and did a basic continuity check of the suspect wires. We found no problems. We next devised a real-time brush ohmmeter using a scope and an external power supply. This turned out to be a very sensitive test of brush continuity. We learned that the brush resistance can be as high as a hundred-ish ohms when the roller is not turning. When the roller spins, the resistance reduces rather slowly, until it reaches a minimum after about 5 seconds of running. We tried resurfacing the roller with 400 grit abrasive paper followed by a thorough cleaning with IPA. This reduced the total resistance down to the ten-ish ohm level. But the all-fives deck still exhibited problems. A closer inspection of those brushes revealed that they were slightly misaligned laterally, meaning that they were tracking along one edge of the punched holes. Bending them back into alignment resulted in several perfect all-fives runs.

With this success, we repeated the process on the Check brushes. We resurfaced the roller, but were still getting high (> 10 ohm) resistance readings on all rollers. We removed the common brush (which was not as difficult as we had imagined) and found that its mounting was a bit loose. We cleaned the bristles and tightened the mount so that a good strong and even brush preload was achieved. We were still getting rather high resistance values, though. We were able to slip a piece of abrasive paper between the brush and the roller to polish the brush contact points. This did the trick, and the resistance values dropped. But we were still getting Reader Checks. So next week we will set up the dynamic ohmmeter again and check each brush resistance and lateral alignment. We should also replace at least one Check brush, since it has a badly bent bristle.

Relay Characterization:

While Arda and Marc were rebuilding relays last week, I was able to QA them using a 4-wire ohmmeter. The 4-wire connection technique eliminates the meter's test lead resistance from the relay contact resistance measurement. A good relay should measure about 100-200 milliohms, and it should achieve that resistance reliably on every closure. It occurred to me that a really good relay analyzer should be able resolve resistances in the 10-100 milliohm range, and be able to collect statistics. One way to realize such a tester would be to automate the data collection from the meter and to perform the relevant statistical analysis of the results.

The meter I was using was an HP3437A, which has a GPIB port. I realized that I actually have a GPIB USB interface, so I was able to download and install drivers for it on a spare Windows 10 machine. I tested it using a simple python script and it works. So I will flesh out that script to see if it can give us a more complete picture of the health of our relays. Any python experts in the group?

That's it for this week.

DC

I rolled the 029 out of the Babbage Room, and with John, plugged it in. It sounded good. I punched a couple of cards and determined the ink in the ribbon was too weak to read the interpretation.

Frank found a new ribbon and together we changed it.
Unfortunately it was really hard to get the end of the old ribbon through the slot behind the card punch where it had to come out.
There is a grommet at each end of the ribbon that triggers the direction reversal to re-use the ribbon.
It took significant hammering to get the grommet flat enough and small enough to get through that slot. Then the ribbon broke just outside the grommet, which is unfortunate, because now it will need more repair if we are going to re-ink that ribbon. Frank has the used ribbon.

I've learned how to thread the new ribbon, and it worked well, except for one character -- the exclamation mark -- does not interpret well.

One more thing was jamming some cards at the point they would register to be punched. Frank used a torn, scratch card to clear the passage.

I was able to duplicate 200 name-card-quality cards with the DUP key with no copy errors (This is for a project). But first I tried using the DUP function on a Program Card, but that didn't work -- the next blank card would skip out immediately without duplicating.
Frank suspects that no one has ever used that Program Card feature since the 029 was restored, so it probably has been broken all along.

-- Henry Strickland

Stephen H. Madsen

We had 35 visitors including one very enthusiastic visitor from Poland who was happy to see the real machines instead of on a YouTube video. The audio worked perfectly!

Unit record machines - we used keypunch #1 for the demo with no issues. The 083 worked well.

Prior to our demo, Steve and Peter reported that CT1401 had reader stop and jamming issues with the first card, so Paul and I tried a few things to get it working but to no avail. The first card jammed immediately at the front and on a second attempt, the card landed in the far left bin, crunched and with roller skid marks as shown here:

We remade fresh and clean first cards but this did not help. No surprise, we didn't use CT.

Since BigPrint was already loaded from the 11AM demo, we ran BigPrint from DE 1401 memory and did not attempt to reload the program. It ran well for the demo, although about 30 minutes after the demo, we encountered reader stop issues on DE1402. Powering down and restarting allowed us to continue post-demo runs.

DE1403 ran beautifully!

For the tape demo, we ran DE727#2 and #3; #1 was out of service. We also ran all 4 CT729s for better visibility to the visitors and it worked well.

Jim and Paul arrived early before 9:30am to test both of the 1402s. Jim successfully ran CT 1402 and we finally demonstrated Big Print for the kids using CT 1401. Paul successfully ran through the DE 1401 Big Print after rebooting the DE with quite a few reader stops and reader checks and duplicating the frailed first page of one deck. Hence we were pretty confident to have two 1402s ready before the demo. We didn't know when the group would arrive and Jim walked around to find the group in a software exhibit and brought them to the lab room.

Under Jim and Paul's support, I flipped the classroom in a new format, with those young children and their mothers being divided into two groups. I guided each of the team by lining in front of the two keypunches so that Jim and Paul could show six of them one by one to punch a name card. During these casual punch moments, the parents were also engaged to ask relevant questions about the keypunches by surrounding Paul and Jim. I designed a question related to the punch card
Question
and guided the parents and children with some basic computer knowledge, simple addition and subtraction and I was surprised they were able to come up with the right answers with hints.

Afterwards we demonstrated the sorter, printer, CPU components and tape drive with all of their attention and their great questions and feedback shared. I was amazed how well those young children could understand those ancient computers by:

• pretending three of us are great magicians that what we helped them punch earlier would show up somewhere in big letters (once we moved them from the card reader to printer, they couldn't help but whoa and take out the phone to record the printing)
• asking them to observe how a Big Print looks like and what they noticed (Big letters purposefully turned into a bit smaller to fit the whole page, there is a date on the printout, the CPU lights were flashing busily while printing, the printer hammers are striking on the page, etc.)

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

Thanks for your great report on the relay contact cleansing. They clean up well! :)

I realized that I do not have any photos of you cleaning the relay contact pins using the burnishing tool.

We had foreign visitors from Argentina, Canada, India, Japan, Sweden, and Turkmenistan.

Scott Stauter

I did a few things the week before Thanksgiving to straighten out our program cards. Here's what I did so far:

• Duplicated and verified the decks of VOBJ 2.1
• Restored the BigPrint deck # 4 that had missing and out-of-sequence cards. Verified with VOBJ.
• Labeled the actions I took - see photo below:
  

Other ideas: Some of these may already be redundant to what is in practice already and I don't know about it yet, so if it is, please let me know.

• Take an inventory of what programs we have in the trays on the demo cart, unless one exists already.
• Organize the card trays by keeping the demo programs together and label them "For Demos"
• Document a Preventive Maintenance Standard Operating Procedure
• Create a log for monthly PM

Samuel Plainfield and I were discussing how we could prevent cards from being mixed up or damaged in the first place. From a continuous improvement and broader perspective, we think it would be beneficial for us recently qualified operators and leads to spend some time together as a refresher. The "Program Execution Error Recovery Table" from the 1401 Machine Operator Manual, Developed in 2022 by CHM Volunteers Paul, Pat, and Jack, and distributed during our initial training last year is an excellent resource. If the veteran Leads (you know who you are ) are willing to, we'd love to learn from your experiences and document best-known methods (BKMs) for:

• handling the cards
• how to detect if cards are out of sequence during a demo
• troubleshooting and quick thinking during a demo for problems with the:
  • card reader, include the method to restart loading a deck if there is a reader check (or other) error
  • tape drive
  • printer

We don’t think we need or want to make this a big project or take up much more of everyone’s time. So what if we just set a date to meet in the 1401 demo lab? We could discuss the above, take good notes or videos, document as needed, and provide mini / ad hoc demos to any walk-ins since we're there.

What do you think? Worthwhile? Please let us know your thoughts.

Larry and Samuel

P.S. Late yesterday afternoon, I took a peek in the 1401 Demo Lab and saw a deck of Big Print on CT. I wasn't sure if anyone was using it or not so I left it there. But I'm concerned that cards can get damaged or out of sequence if left out in the open.

We ran on DE, which ran very well, including all three 729 Tape Drives (thank you, Restoration Team). During our demo we loaded and ran both BigPrint and Powers-of-Two. The 026 Keypunches and 083 Sorter also ran fine. The CT1403 ran out of paper, so Peter loaded a new box from the back room. We might be getting low on paper again, although both 1403s now have full boxes.

Just in case, we powered up CT, but it was not very useful. Every time we tried to load a card deck on the CT1402 we got Read Check on the first card. We tried operating the 729 Tapes via the TAU, but only Tape Drive #2 (second from left) would move.

Exciting news: Peter Chang has been working on his hand-coded one-card "Hello World" program. Today, he ran it successfully! Yay Peter!

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

Ken

Some progress today! We started the day by confirming that the DE machine does not mangle a card when an NPRO is run after the card has been manually preloaded into the throat. We were further able to confirm that this is due to the fact that the machine executes multiple clutch cycles when this test is run. This is the clutch solenoid signal for that test:

You can see that the first two waveform cycles are different because of the interaction with the Card Lever signals as the card passes. Contrast that with the prior observation that the CT machine executes one and only one cycle under these same test conditions.

We then demonstrated that during NPRO, the DE machine will transition from a continuously-clutched condition to interrupted-but-repetitive clutch cycles as soon as Card Lever 1 is activated. When we tried this same test on CT, we found that it changes from a continuously-clutched condition to a single clutch cycle after Card Lever 1 is pressed. Once that cycle is done, no further cycles occur. This behavior is similar to what happens when the test card is preloaded into the throat. So the Finger of Blame is starting to point to a logic fault as opposed to a roller fault.

Next, we looked at the relays and cams involved with generating the -T NON PROC FEED signal which is required to start a clutch cycle. For starters, we swapped relays #1 (Hopper) and #2 (Card Lever 1) between the CT and DE machines. The behavior of both machines remained unchanged, indicating that both relays are probably okay.

I theorized that CT's single cycle "one shot" behavior may be due to a relay that was picking but not holding. Since the problem involved Card Lever 1, we looked more closely at the hold coil drive on the Card Lever 1 relay (relay #2.)

I used a dual opto isolator to view #2 pick and hold coils, and found that pick signals were the same but the hold signals were different between the CT and DE machines. Relay #2 hold coil is fed through one of its own contacts (which we saw above are known good) and cam RC8. We cleaned CR8 with no effect.

Next, we went to look at some other signals in this area. Relay #12 (Feed Control) is involved with the Card Lever 2 relay and the generation of -T RD COMP GATE back to the 1401. We swapped relay #12 with a random spare from the workshop and voilà, the machine behavior changed to agree with the DE machine! We tried to force an NPRO card crunch, but could not; the preloaded card ran out correctly to the pocket. So it looks like we have at least gotten to the bottom of the card crunching issue. It also exonerates the rollers from any involvement with the card crunching bug.

HOWEVER, after trying to load a program card, the machine immediately gave a Reader Stop error. Bummer! We spent the remaining part of the day fussing around swapping relays, but the Reader Stop errors persisted. We even restored the relays to the original configuration from the start of the day, and the Reader Stop errors still occurred. So it seems we have introduced a new problem somehow.

I discovered that we are very low on our spares inventory of 20 volt relays. So the next step will be to refine the relay tester to include both pick and hold functionality, and then to use it to rehabilitate our flaky relays. I took the faulty relay #12 home for a deep dive into its contact's behavior. I want to try using a THD+N analyzer to look at the "fidelity" of the contacts when they are used in an audio attenuator circuit. In my prior life, I found this technique to be very effective for analysing relay and switch contacts.

Here is some further relay info thanks to Ken.

These are 1402's PM relays for the reader unit. Not sure what the "Type" column indicates, I will attempt to find their PN's:

Relay specs: (note that the 1402 generally uses the 20 volt pick models in sizes 4 and 6)

That's it for this week.

DC

- Update - received Dec 4, 2023

I had a closer look at the bad #12 Feed Control relay which we extracted from the CT 1402. I was easily able to detect a bad contact (#6, N.O.).

However, according to the base diagram and the relay table in the schematics, this bad contact set #6 is not used.

I checked the other contacts with both a THD+N analyzer and a 4-wire ohmmeter and they all checked okay. So it is not clear why swapping this relay changes the behavior of the 1402. It will be interesting to check this relay on John's tester.

BTW, the THD+N analyzer test puts the relay contact in the series arm of a -3 dB resistive attenuator, then measures the THD+N of the attenuated signal:

Plotting the THD over time allows the detection of any time-varying resistance, like from a flaky contact or even a bad connecting wire. Here is a plot of the bad contact (~-73 dB) compared to a good one (~-109 dB.)

The 4-wire ohmmeter is also very good at analyzing low resistances. The good contacts measured around 0.56 ohms, whereas the bad one settled at about 10.5 ohms. Note the reading differences between the Fluke DMM and HP DMM. The residual resistance of the 4-wire technique (measured with the test leads shorted) was about 0.05 ohms, which dropped to 0.03 ohms after the application of a little Deoxit to the tips of the test leads.

DC

- from Marc Verdiell -

Late report, we finished to reconnect the DE tape drive #3 with John and Arda. The newly installed tape load motor works, but on occasion it seemed that the vacuum contacts were a bit lazy.
We put a new CMOS battery in the tape emulator computer, which made it noticeably happier. We moved it in place to try on DE next week.
Marc

However, in answer to your question, Saturday morning we found a strange condition on CT 729 mag tape drive #3 (counting from the left). The tape on the feed reel was wound backwards. In the diagram below, a correctly would feed reel looks as shown on the left. That is, the tape comes out as shown, and then is fed into the drive rollers. The bad reel instead looked like the diagram on the right. When moving a tape forward, the feed reel rotates clockwise, feeding out tape. You can see that if the bad tape rotates clockwise, it actually PULLS IN tape.

I removed the bad reel and placed it on top of the CT1406 with an error tag. If this reel cannot be fixed, it should be replaced with a new tape reel. I didn't have time on Saturday, since the 1:00 PM demo was about to start.

I have no idea how this problem was created. Perhaps the tape is kinked and folded farther in? Perhaps a well-meaning operator incorrectly threaded the tape? The winding almost looks like a TAKEUP reel rather than a FEED reel. But the existing gummed labels suggest this originally was a feed reel. Duane, you mentioned the other day that you'd found a tape reel with the tape twisted so that the wrong (non-oxide) surface was up. Could this be that reel?

Since recent demos have all used DE, this problem on one CT tape does not cause problems with demos.

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

We ran on DE due to ongoing CT 1402 issues. We tested several programs before the demo, and all ran fine. My Beautiful Assistant, Jack, asked if we should demo program loading or just leave BigPrint loaded. I said that we should go for it. Fortunately the DE 1402 was feeling fine and loaded both BigPrint and Powers of 2 without incident. Tape #2 and the 1403 worked perfectly.

The 083 sorter and keypunches #1 and #3 worked fine. The printing on 026 #2 was too light to be usable. Reversing the ribbon didn't help. The A/V system worked well.

Before the demo we tried to prepare the tape drives on CT in case of failure of all DE tapes. However, we discovered that the CT tapes would not run from the TAU. We were attempting to run drives #1, #2, and #4 because #3 was marked inoperative (see Jack's email regarding a tape wound the incorrect way on that drive.). After the demo we spent some time looking at the TAU operation issue. During one attempt, I was standing by drive #2, and I heard a faint click when the TAU start switch was pressed. We then decided to test the drives individually. #1 and #4 didn't work, but #2 did. Food for thought for our fabulous restoration team.

Pat

There were 44 visitors that attended and 8 came after. There were visitors from Japan, Mexico, and Ukraine.

We used DE since it was used in the earlier demo. The only problem came near the end of processing visitor’s name cards when the 1402 acted up. We got two read checks that were easily cleared by doing a non-process run out and a check reset followed by it working for a while. But then got it again and after clearing the read check it immediately happened again. After trying a couple of times to reset it I power cycled the system and reloaded Big Print. It then worked for the rest of the cards. Tape drives 1 & 2 were used and had no problems. The 1403 also had no problems. All 3 keypunches; were used and had no problems. And the sorter also had no problems.

There were no problems with the microphones.

Jim Maurer

The microphones worked OK.
We used the keypunch farthest from the closet, and it worked OK.
The sorter worked OK.
We used DE.
We fixed tape drive #2 by rethreading the take-up spool and adding a magnetic reflector to the tape. The printer was printing faintly, so I manually turned it to get darker printing. There were some card reader errors, but we managed to make it work. We preloaded BigPrint before the demo rather than load it during the demo.

Stephen H. Madsen

A/V - works very well!

Unit Record Machines

• We used keypunch #026-1 for the demo. #026-2 wasn't feeding for a while but the machine decided it wanted to work again and did so. #026-3 (closest to the A/V closet) worked well too.
• Sorter 083 worked beautifully.

DE 1401, 1402, 1403, 729

• We used DE 1401 but xsince the 1402 had intermittent issues earlier during the day, we loaded BigPrint prior to the demo and did not attempt to re-load it again. Duane explained what he would have done and then just ran the program using the visitor's name card.
• The 1403 printer worked well and printed nicely. We ran out of paper after the demo so Duane installed a new box.
• The 729-1 and 729-2 worked wonderfully. 729-3 was not in service.

• I duplicated a set of VOBJ using the 026. I still need to verify the duplicate cards prior to putting it into service so I am holding on to it for now. The original VOBJ and instructions are in the metal trays as usual.
• I started doing QC on the programs and found that BigPrint Deck #4 did not have a F/C. In fact, the first ~8 cards were missing or out of order. After Jack's efforts to straighten out the BigPrint decks, I don't understand how this can happen so quickly. I forgot to label this with a sign "do not use" but will do so on Wednesday, or better yet, if I have time, I'll restore the deck.

Larry

I noticed that our demo BigPrint decks were not doing well. Some were marked "Doesn't Run" or similar. So, during the periods when Ken wasn't using DE, we fooled around and were sometimes able to get the Punch Check to disappear for a while. I took that time to use DE to run VOBJ to investigate the BigPrint deck problems. We currently have five (5) copies of BigPrint, identified as #1 through #4 and a fifth one marked "Frank King". I found at least a trivial problem with every one of these decks.

• BigPrint #1: First Card was missing the program ID in columns 76-80. Probably happened when a Good Samaritan duped a worn first card and got tired of holding down the DUP key about column 77. Trivial error, which did not prevent this deck from loading and executing OK.

• BigPrint #2: The deck was missing Cards #2 and 3. Probably, this happened when somebody loaded the deck, got a Read Check on the first card, and forgot to do Non Process Runout when re-building the deck. As it was, this deck would not load.

• BigPrint #3: Cards #53 and #54 were swapped. Despite this minor error, this deck would still load and execute OK. No idea how this happened.

• BigPrint #4: First Card was missing the Program ID in columns 76-80. Card #9 was incorrectly moved after Card #11. Despite this minor error, this deck would still load and execute OK. No idea how this happened.

• BigPrint "Frank King": Card #1 was missing the Program ID in columns 76-80. There were three (3) copies of Card #98. A few years ago, BigPrint Card #98 was patched to correct a printing error for the big letter "D". Two of the Card #98s were the unpatched version, and the third was patched. Probably the "Frank King" deck was copied from an old copy of BigPrint which hadn't yet finalized the patch. The minor errors did not prevent this deck from loading and executing OK.

I corrected all the problems noted above. As of 11/15/2023 2:00 PM, we have in the demo trays five (5) BigPrint decks which all are identical, and all load and run. The DE1402 Reader infrequently gives Reader Check errors, but they don't seem to be related to any specific BigPrint deck. I didn't have time to investigate any other demo programs (Powers-of-Two, Lincoln, etc.).

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

There were 24 visitors who attended the demo. Plus, there was 1 person before and 2 afterwards that we talked to. Foreign visitors were from Hong Kong, Sweden, Romania, Ukraine, and Canada.

There were problems again with the channel 2 wireless microphone. Sometimes when you attempt to put it on standby or power it off it will not respond to the button. You must remove and reinstall the batteries and hope it doesn't happen again.

Jim Maurer

1. The new rubber rollers have arrived and they look great. The rubber is quite hard, which is good, and the OD is a tiny bit oversize (1.22" vs 1.21" theoretical), which is also good. See the photo below.
2. It occurred to me that by using two rotary encoders, one on the #1 drive roller and the other on its pinch roller, we can compare them for evidence of card slippage. If there is no slippage, the drive and pinch rollers will have a ratiomatic angular relationship determined by their differing diameters. If the software is written to compensate for that diameter ratio, the two angular position plots should be congruent. If they are not congruent, something must be slipping.

DC

Either way, there shouldn't be a punch check unless a punch scan is happening, so I still think the underlying problem is in the punch scan circuit. But it's hard to track down because it is intermittent.

Ken

Card Crunch movie

CT 1402 Reader card crunching:

I wanted to try to cut the motion analysis problem in half to see if either the machine is somehow misbehaving (bad clutch, etc.), or if the cards are just not moving as the machine needs them to move. So I attached a high-speed, high-resolution rotary quadrature encoder to the #2 clutched roller shaft to see if I could find any evidence of mechanism misbehavior. The setup has a brass hub to couple the encoder shaft to the roller pulley. The curved metal strap is screwed to the encoder body to keep it from spinning:

The encoder signal was sent to an ESP32-based quadrature capture board and from there plotted using the Arduino Print Monitor function. This is what a single clutch cycle looks like after being triggered by about 10 degrees of initial motion:

The vertical scale is degrees of machine cycle, and the horizontal scale is (approximately) milliseconds. You can see from the linear trajectory that the roller comes up to speed almost immediately and spins at constant speed until the clutch releases, at which point it stops dead. The small ringing at the stopping point is likely due to elasticity in the belt and vibration of the thin sheet metal arm that keeps the encoder from spinning. This 'signature' waveform happened when a single card was processed correctly. An identical waveform was produced when the card got crunched. There was no observable difference between the card crunch waveform and a normal single-card read waveform. This agrees with what we have seen all along when observing the solar cell waveform. I think it is safe to conclude that the mechanics and relay logic are not misbehaving when the card gets crunched.

We then took a high(ish) speed iPhone video of the card crash (attached). Viewing the movie frame-by-frame clearly shows the card jamming into the stopped clutched roller #2, but card slippage at the first clutched roller is not readily apparent. Maybe better video analysis (or a proper high-speed camera) will reveal that, though.

We had a mid-morning coffee+brainstorming session to review the results. One theory that emerged is that as a result of the roller swap John and I performed last summer, the "new" rollers we installed may be slightly smaller in diameter than they should be. This would result in the card not moving as far as it should do when its drive roller turns its prescribed number of degrees, making the card "late." So we set out to measure the "new" roller diameter.

Since it is not possible to fit calipers inside the machine, we measured the card travel per clutch cycle instead. We manually rolled a long strip of printer paper under the first roller until the clutch unlatched, marked the throat plate position on the paper, manually cranked a single machine cycle, and marked the paper again. The theoretical card travel for a 360 degree machine cycle is 5.00", calculated from the ISO 0.250" row spacing and the 18 degree per row solar cell spacing. The measured travel was 4.9", only 2% below the theoretical value. While we don't think this 2% completely explains the crunching problem, it may be adding to it by eroding whatever margin the mechanism has for allowable slippage.

One next step for analysis would be to somehow track the actual card position with similar speed and resolution as the rotary encoder does for the roller angle. Gluing a "tail" to the card that has some kind of linear scale (optical or magnetic or ?) and passing that through a reader would allow us to track the actual card position. Comparing that to the roller angle would allow us to characterize the card/roller interaction.

Another next step is for me to ping the vendor about the delivery date for the new rubber rollers.

That's it for this week.

DC

The clutch solenoid cannot be continuously energized because of of its series capacitor; it has to be pulsed. And we see this on the oscilloscope when we observe the solenoid drive voltage. But the solenoid can be retriggered just before the dog is about to reset, resulting in a pulsed solenoid drive, yet a continuous rotation of the clutch output pulley.

I deliberately described that the cards stop in front of each brush station to underscore the step-by-step nature of the card processing. But if the solenoid is pulsed just before the clutch is about to unlatch, the clutch continues to spin and the cards don’t actually stop. Yes, my original description was purposely a bit deceitful, but I didn’t want readers to think that the solenoid just turns on and the cards flow forever without further logic intervention until the solenoid is turned off. All of the card lever and cam switch qualification logic still happens for each clutch (half) revolution, even if the clutch is still turning when a new cycle begins. This is important because our card crunches may be due to some failure or instability in this qualifying logic.

Or else the rollers are slipping. ;--))

DC

The above picture is of the feed rolls.
From what I understood from Samuel mail was that 2 Clutched feed roll stopped on NPRO resulting in card jam.
I have marked the clutch, Clutch belt, clutched feed rolls and the continuously running rolls in the above pic.
Hope my understanding of Samuel's observation is correct.
Card levers 1 and 2 could timings could give indication on the card movement.

Bhushan Mohan

It comes back to roller slippage as still being the prime suspect. Replacement rollers are being fabricated and should arrive in a week or two.

DC

1. Drag under each roller.
   Manually feed one card and check the drag on both sides (rear and front) on the card. Should be checked for the complete circumference of the rollers.
   Better still cut the card longitudinally and pass iech strip under the front and rear of EACH of the rollers to check the drag. For the clutched rollers please engage the clutch. Drags could give indication which of the rollers might be slipping.

2. Bearings for bind and play. Gears of continuously running rollers
   Each pair of the 4 card feed rollers have one fixed and the other spring loaded roller. Would be good to check for all the 8 spring pressures and also all the 16 bearings for bind and play.
   Also please check the continuously running front cogged belt driving the 2 contact rolls and also the gears driving the 1st and the last continuously running feed rolls. Problems in any of these areas would result in card jams.

Please also update any further developments that took place today. By now you would be packing up for the day.

Bhushan Mohan

BTW the jamming is much less frequent than you might think it is. Maybe once in a few hundred cards? So we are encouraging the operators to use the machine for demos with the understanding that they may encounter the occasional jam.

But manually loading a single card always jams on CT and never jams DE. When manually loaded, the card is in a position that is similar to an mis-picked card, which can happen during a demo. A subsequent jam wrecks the demo, so we seem to agree that the problem is real and needs fixing.

Besides installing the new rollers when they arrive, next steps for me include studying the potential of making a “high visibility” card path that would allow a high speed camera to capture the fault as it occurs. We have spare brush assemblies that can be stripped of everything except the card guide. Then I will try to make a clear acrylic version of the card lever 2 plate. That plus adding location markers on the cards and rollers should enable us to make a realtime recording of the jam.

DC

If only one card does not feed ok, please check the clutch status. First check the Latch Keeper. The Latch Keeper could be checked without opening the clutch.

Else it would be worth opening the clutch for cleaning and checking the Latch, Latch Keeper and also the Dog and Detent on the clutch.

Worth a try to check these out

Bhushan Mohan

Thanks again for participating in our 1402 bug shooting expedition.

— Robert

p.s. I wildly pontificated last week that something (who knows what) might/could cause a slight/momentary backward roller motion. :)

But monitoring the clutch output angle more closely may yield more clues. I’m thinking about adding a second rotary encoder to the clutch output somehow that gives both better angular resolution and covers the entire 360 degrees of rotation. Although a high speed camera looking at the clutch output pulley would also work well.

I like the idea of breaking the problem in half to see if the trouble is “before” or “after” the clutch in terms of mechanical energy transfer. Slipping rollers are “after” the clutch pulley, whereas a malfunctioning latch, keeper, or dog are “before” it.

DC

On the CT1402, it looks like the second (read) set of brushes are currently working very well. A print of all-four's deck results in a perfect print-out.

However, we are still getting reader checks. So, Frank and I methodically checked via storage scan and saw that the first set of brushes (check) 3, 30, 50, and 51 were repeatedly showing up.

(Note brush #30 on the console appearing)

With Arda's mathematical help, we located the suspect brushes; I replaced three of the brushes. Brush #3 was not replaced, because it was not showing up as often as 30, 50 and 51. Running the tests again, it didn't seem to make much difference... the brush errors came back with similar results...somewhat.

(Brush #50 being removed)

During the demo, I was able to run the full deck of software and myriad name cards with no jams and with I/O check on. At one point, I got a reader check; due to my confidence that the second set of brushes are not the culprit, I just switched off I/O check and continued printing the name cards which sure enough printed correctly. Due to the intermittent nature of the device, this may work today and utterly fail by Saturday. I left I/O check off -- so, if you forget to turn it back on, and get a strange error on the console, that means something went awry on the second set of brushes.

There's a box o' brushes that were donated from a former IBM CE. Frank told me that he gave it all to the museum some years ago and Frank opened the box to discover all those "juicy" parts. Those "new" brushes are indeed fresh and juicy. I suspect there's plenty of micro-rust on the "old" brushes that would benefit from being put in some kind of safe solution to dissolve it away -- does anyone know of such a substance that might fit the bill?

("New" 2-group brushes!)

David observed that brush #3 is used in connection with the dynamic analyzer which was left on by accident; so, that may play a role in some of the behavior we're seeing.

David and I were experiencing some potential operator error in getting the dynamic analyzer to work. We configured the settings on the 1402 CE panel to what we recall/thought should display the neon lights to show cam timing, but were unable to do so on either machine ... so, we'll need Frank to remind us and I'll memorialize those settings. We were also unable to get the reader clutch switch (to advance a card without 1401 input) to work -- which we've never seen work before. David noted afterwards that perhaps the motor needs to be running prior via Start in order for that switch to work since the switch by itself has no mechanism by which to activate the motor.

David and I also checked the firmness of the pinch roller for the continuous unclutched rollers. They're extremely tight, no way that a card can slip when captured.

I rck'n that's all for now,

~Samuel Plainfield

The problem is intermittent, which makes it harder to track down. DE was working in the morning but failed after lunch. I turned off the air conditioner which (maybe coincidentally) got it working again in time for the demo. It is hard to get all the measurements I want because the problem is intermittent. Moreover, the triggers (flip-flops) are very sensitive and sometimes putting the oscilloscope probe on a pin toggles it.

Working backward from the punch check light:

I am pretty sure that the difference between working and non-working is the PUNCH SCAN GATE is -10 in the good case and -5 in the bad case. I pulled D19, which caused the light to go out, but the system still failed to read cards, so the problem is before D19.

Last week, I suspected the PUNCH SCAN trigger A22 was misbehaving. Marc and I tested it extensively and it appears to work properly. We also swapped the card and that had no effect. (One random thing: If we toggled it high, the console went wild as the CPU tried to perform a punch scan.) So I think the problem is between the trigger and the PUNCH SCAN GATE signal, that triangle northeast of A22.

The triangle (AND gate) consists of 3 boards (!) Here is the relevant part of the ALD:

Based on my measurements, both signals into the NAND gate are low, but the final GATED PUNCH SCAN (yellow) is high in the bad case. So maybe the NAND gate B26 is bad? Since the other cards only have one input, I don't see how they could give the wrong answer sometimes. So my plan is to examine B26's inputs and outputs the next time the punch check happens, to see if it is the culprit.

Ken