Keypunch interface moving ahead, more SAC interface assembly and some mechanical work on the 1442 card reader/punch

1442 CARD READER/PUNCH RESTORATION

The National Museum of Computing in Milton Keynes, UK restored an 1130 system a while back. Based on the experiences they had with the 1442, I decided I too would be better off if I disassembled the card feed clutch to thoroughly clean out old lubricants. Its performance is critical to the timing of the card reading process - if it slows the card down then check conditions are forced, stopping the machine from reading the next card.

Feed clutch disassembled in center, read clutch upper left

Read clutch with belts and pulleys removed

In addition, I partly disassembled the read clutch and made sure it was moving freely. There are some cams driven by the feed clutch whose mechanisms and their pivots seem stiff. I will work on those too.

various cams on card feed shaft whose pivot arms and mechanisms need work

Part of the disassembly process had me use a pin punch to drive a pin out of the shaft;  the pin holds a pulley in place. After I had removed one pin and was carefully disassembling parts of that clutch, I heard a clunk. I couldn't find the punch anywhere in, on or under the machine. I have a feeling it shot somewhere inaccessible in the garage, but until I find it I won't be comfortably buttoning up the reader and running it.

Parts removed from 1442 in order to access the two clutches

I also heard a smaller clunk when I was hand rotating the read clutch shaft, with a small rod dropping down from somewhere. The rod has hemispherical ball ends. I am studying the parts catalog diagrams as this too much be understood before I can power up the reader. The good news is that I was able to get old gunk out of the clutches and good lubrication inside. The read clutch has a grease nipple in a location that was completely inaccessible while everything was together, but can now be used to force in new lube.

Grease nipple on card feed clutch now much more accessible

By disassembling things, I took on a set of adjustments after reassembly that wouldn't have had to be touched otherwise, but these clutches are so critical to the operation and timing of the reader that I thought it worth the cost.

Main card feed clutch latch and release

Card read clutch latch and release

I found a small roller that is frozen due to grease, part of the card feed mechanism. Most rollers I have already found and loosened up, but this one escaped my notice until now.

Little frozen roller above midpoint of picture

NEW KEYPUNCH INTERFACE DEVELOPMENT

After some investigation I did find out what was causing my flaky failure to recognize a registered card, as well as the reason that my initial testing of the ability to read cards was not giving me any valid hole values. My relay contacts were oxidized - slightly but enough to cause erratic results for the Card Lever relay which determines that a card is registered, while the Dup 3 relay that switches the sensing pins for reading during duplication were oxidized as open circuits.

I used some contact cleaner which claims to not damage anything nor to leave residue - a version of Deoxit without the lubricants or 'protectant's of the other Deoxit varieties. I got good values for both N/O and N/C contact closures on all poles, reinserted the relays and verified correct operation of the keypunch while disconnected from my box.

I then inserted my box and again verified that I could do everything with the keypunch, no odd behavior while I was connected. Finally, it was time to hook up a terminal and see how the interface works. I was able to command the unit and continue with the debugging of the interface.

I found an error in how I was error checking one command while in short verb mode, found that the release is not taking place at the end of a punch, suspect that two character encodings in my ascii table might be wrong, and am still not happy with how my binary mode logic converts four hex digits to a variable I later use for punching. I began looking at each and clearing them up.

I corrected the error checking bug, suspected that the release solenoid needs 20ms just like the space and row solenoids so adjusted it, and looked at the encoding issue. I discovered that the ascii to card code table which is a duplicate of the encoding from the original interface built for the 1401 project, is using a BCD character equivalent which prints differently on an 029; the 029 uses EBCDIC encoding of the hole patterns.

I decided that we need two standard tables for ascii translation, one to the BCD characters and one for the EBCDIC patterns matching ASCII printable characters as would be viewed on a terminal program emulating an ASCII device. ASCII itself has a separate encoding of card holes which we won't be implementing since this is not usual for the IBM computer environment and it could be handled by the USERTABLE option if needed.

I will build two tables BCDtable and EBCDICtable, adding a command for selecting which is invoked in MODE ASCII. The command is CODE BCD or CODE EBCDIC. The code is added and part of the testing underway. .

Testing continued, resolving the error checking bug and cleaning up the binary mode issue. Since the encoding is correct, but spurred a design enhancement, it is considered closed. The release is still not working and I found a couple of subtle flaws to clean up in the code. Looking at the release, I suspected the wiring but also the Release relay given the oxidation problem I had with the others.

Ran out of time tonight but making good progress on the keypunch interface. Hopefully the reading of the holes at the second station is not being blocked by oxidation on the sense pins, otherwise I will have to open up that station and clean up the contacts.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I  hooked up the TTL input and output leads to the first board. That one only needed the twisted pairs soldered onto the driver or receiver, as relevant for the direction of the signal, to make it operational.

I began a second board, but after three sets of circuits noticed I had made an assembly mistake on a number of the receiver circuits on the first board, swapping the position of a 1K and a 12K resistor. Sigh. I will have to clip them out, reopen the holes and then solder in replacements for the 9 bad circuits. I began by clipping and raising the faulty resistors.

Completed board but with misassembled resistors along bottom row clipped off and twisted up for replacement

Still battling the keypunch, stalemate tonight, plus more assembly of SAC interface boards

NEW KEYPUNCH INTERFACE DEVELOPMENT

After going over the inside of the keypunch and bending various SMS socket pins and relay panel pins to ensure there are no unintentional shorts, the keypunch appears to be working just fine by itself. I finished wiring up the new keypunch cables I began with better, more secure connectors and larger gauge (lower number) wire. I dressed it well along the panel and made the cable much more bulletproof and production level.

New reader cable DB25 plug - rugged wire bundle

Reader and Punch cable wiring dressed in place on back of wire relay gate inside keypunch

My reader (white) and punch (red) cables ready to plug into the interface box

In addition to replacing the cables and dressing them along the keypunch relay gate, I wired the power brick into the power supply so that it is switched on with the main keypunch power switch under the table. Finally, adding a DB9 extension cable to run up out of the machine, I now had the means to put the box inside the keypunch ready to close up the interface cover once debugging is complete.

Power brick cable converted to lugs to attach to the 029 power supply

Testing resumed but the keypunch is stuck in its state of refusing to recognize a card was registered. I will check over my wiring a bit but I am beginning to suspect this is just erratic operation from relay contacts that still have a bit of oxidation on them. However, I will also recheck the wiring to be sure it is correct.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I assembled more receiver and driver circuits onto the board today. I was able to finish one board and have three more to do. It is slow going to make sure I do it correctly. It has the +5V, +3V and ground power lines attached but does not yet have input or output leads.

One completed board for SAC interface, 12 drivers across top and 12 receivers across bottom

SCANNING COBOL PROGRAMMERS GUIDE MANUAL

Several manuals are not available on bitsavers or other digital archives, but should be. I slowly (and I do mean slowly) get the pages scanned in between other activities. This manual with more than 180 pages has taken three days elapsed time so far and I am still only at page 150. I don't usually comment on the scanning but realized it was completely sub rosa if I didn't.

Very light day working on the system

Between heavy work obligations and an afternoon at the dentist, I only had two hours to spend in the workshop today. Still, I did make a bit of progress.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I removed the added wiring inside the keypunch and began to wire it with the new preferred push on connectors, on the assumption that the old connectors were bridging to the wrong wires because they weren't very secure. While I was at it, I used larger diameter wire which I will install on a DB25 connector.

With all the wiring disconnected, the keypunch was still misbehaving. It worked fine with a card registered in the punch station but once there was a card registered in the read station as well, the card lever relay won't activate so punching or spacing is not possible. At least I now know this isn't a flaw in my interface design.

As soon as this is debugged and repaired, I can resume testing of the interface. While I am working on the keypunch wiring, I am also replacing the read cable connections as the pins I used are also insecure, very wide and exposed at the top where they can touch other pins.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I soldered a few more driver and receiver circuits onto the board, until it was too dark to see on the outdoor work table I use for assembly.

Successfully booted DMS2 from the internal disk drive and began building the SAC interface hardware.

Very busy with tasks from my day job, but I was able to grab a couple of hours with the system and made good progress in that time. starting manufacturing the logic/voltage conversion hardware that will interface the Storage Access Channel cable from the 1130 to TTL logic.

1131 DISK DRIVE RESTORATION

I checked over the cold start card data I had written down, spotted a couple of transcription errors and fixed them. After toggling the eighty words into core and readying a disk cartridge with the DMS2 monitor installed, I booted up the 1130! I head it seeking and reading multiple sectors and then drop into its I/O wait condition. The IAR read x002A and the accumulator (ACC) has x6000 which means the 1132 printer is not ready - exactly what would happen since I didn't have the printer powered up.

This is a very strong test of the system, both the 1131 processor and the disk drive, much stronger than the diagnostics I have been able to toggle into the machine so far. Once I have either the 1053 or the 1132 ready to print, I can run even more - DMS2 can be set to print on the console printer as an alternative to the line printer, plus the input commands can be rerouted from the 1442 card reader to the keyboard. I would need to have the 1132 appear ready, even if the hammers are not causing readable impressions, just to allow DMS2 to be ready to read. Then, I would have to nurse one card through the 1442, // TYP, which redirects input to the keyboard.

That would allow me to type in some job control (monitor) and supervisor cards. I could run programs, at least those that will allow all its critical input to come from the keyboard or keyswitches and don't need to print or read cards.

CHI INTERFACE AND DISK DRIVE

Until the disk heads can be thoroughly cleaned and inspected, I will not be putting any cartridges into the Diablo drive. I may experiment a bit to get sense DSW to respond for the disk drive and line printer device address that the interface implements.

I am not sure what addresses it uses, although the printer is called a 1405 which implies it may use the same area code as the IBM 1403 printer. Similarly, I expect the diablo disk to appear as one of the standard addresses that are used by DMS and the disk oriented utilities.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I am not happy with the security of the connections put onto the SMS socket pins, suspecting these are leaning over, shorting together wiring to cause the balky behavior of the keypunch. I found some push on connectors that fit much better than the current ones I installed. Once I rewire this with the improved connectors and am satisfied, I will go back to the testing.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

All my supplies came to day and I started construction. I slightly modified my plan for the board layout in order to make assembly easier. Now, each board will implement twelve drivers across the top half and twelve receivers across the lower half. I have built 25% of one board so far, before the light faded outside where my assembly table was set up.

Top shows three driver circuits, bottom has three receiver circuits

The circuits are packed tightly together, each requiring five vertical columns with the input at the leftmost column and the output at the rightmost one. The horizontal power strips are +5V and ground, but the receiver circuit also needs +3V which is an SLT requirement. The +3V will connect to the number two column of each five - you can see the open hole at the top  and near the bottom of the second column, where I will daisy chain the +3V down to a connection point at the far right of the board.

I have the parts to assemble circuits for all 77 signals that are carried on the Storage Access Channel interface. This will require four boards, whose total capacity would be 96 signals if they were needed, with twisted pair in the SAC cable hooked to these circuits. The TTL side of these circuits will be wired to a high density connector which I can use to connect other logic into this voltage conversion interface. 

Keypunch interface stubborn issue, SAC receiver circuit working, and testing the CHI interface/disk

NEW KEYPUNCH INTERFACE DEVELOPMENT

I wired diodes across the relay contacts in my box in order to absorb any induced back EMF from the opening of the coils. Electrically it would be more ideal to install these at or close to the punch solenoids in the 029, but we are trying to keep the keypunch modifications to a minimum. However, the small gauge wire connecting to the interface box will have to absorb the current spike flowing through the diodes.

Diodes added across relay contacts in order to quench back EMF from keypunch coils

With the diodes installed, I hooked up the box but found that the machine was not recognizing registration of a card even initially, with no attempts to punch. I will have to troubleshoot this to understand what is blocking registration.

I made up the dummy plug and verified that the keypunch works properly with the interface disconnected. Therefore, there is no damaged component in the keypunch. I hooked up the punch cable to my box, leaving all other cables including power disconnected. The keypunch worked properly one time with cards but after a clear cycle, it was again failing to recognize when the next card was registered.

Dummy plug for punch cable when box not attached to keypunch

This tells me that something in my static wiring is causing this problem - the wiring that is linked through relay contacts is somehow causing a problem - the relay contacts being open. It may be a wiring issue or a short in the connectors or something else, but I have to diagnose this before the box can be tested further.

I tested every wire going into the box from the punch cable and they were all infinite resistance to each other, except for the pair for multipunch pole 2 which are normally closed. I ran the keypunch with the dummy plug for a while, then plugged in the punch cable but otherwise had nothing connected to the interface box. This worked well for about five or six cycles of registering, spacing and clearing cards.

I then plugged in the power brick connector (but no AC was hooked to the brick), which locked up the keypunch on the second cycle. Very odd. At this point I have to suspect that a connection is intermittently shorting somewhere in the SMS block, so that small movements of the cables introduce the error.

CHI SAC INTERFACE, DISK CONTROLLER AND DIABLO DISK DRIVE

I powered up the CHI interface electronics and they came up cleanly. Looking over the cards, I came to the conclusion that it appeared likely to be working properly. As I result, I will cable this to the SAC interface and give it a try later tonight or tomorrow.

CHI interface looking good, decided to begin testing it

The interface came up fine and the drive loaded a pack I was willing to risk. I found a slight darker mark where the head was riding on the disk. I will inspect it in the sunlight to see whether it damaged the pack, but the heads must be cleaned at a minimum before I put any other cartridges into the drive.

Superficially clean drive, but some marking on a cartridge where the heads flew

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I picked up the solder this morning and rewired the demo receiver circuit, which is hooked through a transmission line (I twisted wires together from the driver output and from the receiver input, then connected those twisted pairs temporarily). This is intended to verify that TTL input signals to the driver will be properly reflected as TTL outputs from the receiver, as well as my verification that the voltages are at appropriate levels in both states.

The circuit worked perfectly. I varied resistances to ground on the TTL input to the driver to see at what voltage it would switch between on and off. It will recognize a logic level 1 down to .1V but is off somewhere above .066V, well within the specifications for the logic I will use to drive signals towards the 1131.

Driver circuit on top and receiver circuit at bottom - working perfectly

Now that the circuits work with each other, I will temporarily hook the receiver up to one of the SAC output lines and the driver up to one of the SAC input signals, in order to prove these circuits work with the IBM SLT logic cards. I chose interrupt request and the corresponding interrupt level status as the signals on the SAC interface, as I should be able to see the request mirrored on the 1131 console and the status of the interrupt level on the panel mirrored at the TTL output.

I lieu of testing this, I powered up the CHI interface and disk drive (see above). I may do some XIO tests to determine how the CHI interface is responding (and to what addresses), but the important testing will be with my circuits once I move on to try them with the SAC.

I went ahead and ordered the transistors, diodes and resistors I need to implement the full interface which will give me TTL logic on my side and for the other side it will deal with the 1131 SLT transmission lines coming out of the SAC interface. I expect to have all the parts by the end of tomorrow, thus doing the assembly on Thursday and Friday.

TTL to SLT driver circuit working well, plus solid progress on the keypunch interface unit

1053 CONSOLE PRINTER RESTORATION

I have a good new belt for the 1053, although I know that installing it means partly disassembling the operational shaft and possibly having to redo all the settings when I put it together. I will stall a few days before starting this odious task.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I studied the schematics for the 029 Keypunch and read the theory of operations manual until I figured out what is going wrong - the failure to register a card and allow punching that crops up after some time using the new interface. It is the multipunch key implementation I designed.

When the multipunch key is depressed, the keypunch will drop the alpha relay, putting the keyboard into numeric mode which does not allow space, A or Z keys to be activated (they have no numeric or shifted meaning). It also sets up the machine to pick the multipunch relay once the first key is pressed and to interlock further escapements (advancing columns).

The key on the 029 consists of two switch sections - one pole is normally disconnected but when pressed will route power to the multipunch relay. The other pole is normally connected to the circuit that holds the machine in alpha mode unless the numeric key is held down. When multipunch is pressed, it opens the line to the alpha relay, having the same effect as if the numeric key is pressed.

I only implemented the first pole, latching the multipunch relay but not switching to numeric mode. This resulted in the funny behavior, I theorized. I can take the two wires and relay currently used for the Clear switch and use them as the second pole of multipunch. Clear was not an essential function, it was a 'freebie' added because we had a spare relay.

However, the way the wiring works, we must be in series with the multipunch key second pole, All the other interventions are parallel, meaning if the cable is removed the keypunch operates normally, we just close a parallel set of contacts to the original key when we remotely operate it.

Due to the circuit layout in the 029, if we were to act in parallel to the numeric + multipunch pole 2 switches, we would block it from going to numeric mode - a failure. If we insert our relay in series so that our relay is normally closed, it will work properly and kick the machine to numeric during multipunch, but if the cable to our box is removed, the machine stays in numeric only mode - a different failure.

I can't see any clever way to implement this that is independent of the cable, unless I put a double pole relay down inside the keypunch to activate multipunch remotely; pole one in parallel with the key pole 1 and pole two in series with the numeric + multi pole 2. That would let me use one pair of cable wires to activate multipunch remotely, but it means additional changes must be made to a keypunch before it can be hooked to the interface. The upside is that we get our freebie Clear switch back because the relay and two wires are not needed - one circuit fires the remote.

The other option is a dummy plug that is put on the cable when it is not hooked to an interface box, the dummy plug bridging the circuit that is in series with the numeric + multi 2 switches. This requires less hardware but the user must remember to keep the dummy plug in place when the interface is not attached.

I chose the last method, rewired my keypunch and made a dummy plug up. This does not  preserve the two wires and relay for the Clear switch; we need it for pole 2 of multipunch. It has some rewiring necessary but that will be the normal instructions for modifying other keypunches.

Example of a dummy plug - although this is the wrong polarity. Need a male plug.

I put the modification in place, hooked up the interface, but I am still seeing the same problem - won't recognize card registration or allow punching. Letting the keypunch sit for a while and it works fine, but once I punch through the interface, the problem resurfaces. This happens with or without the read cable attached.

As far as I can see from the schematic my wires should be totally isolated from the other wiring, with relays connecting the circuits to fire various punch, space or release solenoids, and only one input which is my own magnetic reed switch with no wiring in common.

I have one small problem with single letter verb mode (i.e. allow M instead of MODE) that I will clean up, and it seems my parsing, storing and manipulating binary mode characters is flawed. However, my multipunch key functionality now works perfectly.

At this point, I suspect it is back EMF generated when the solenoids drop. This back EMF may be harming the keypunch, putting it into the problem state after some punching occurs and restoring itself with the passage of time. Fortunately, I had recently picked up a pack of 100 3A solenoids which are going to work out well for this purpose.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I varied parameters and simulated my driver circuit many different ways, but the outcome is always the same - it should work properly but the sample circuit I built didn't. At this point, I will rebuild a sample circuit and check again, in case there was a bad component or bad connection or other problem that invalidated my test.

After rebuilding the demo driver circuit and firing it up, the results were exactly as predicted by the design, totally unlike the poor results of the first try. Not sure what was wrong but I can drive the transmission line to 2.9+V for logical 1 and about 0.1V for logic 0. Since the margins for SLT logic are 1.8V high and 0.3V low, this will work well. It was designed for worst case resistance and I used a suboptimal set of twisted wires. Real world performance should be better.

I will now rebuild the receiver circuit with tested components and test it out, but my expectation is for both sides to work as intended. Somehow I let myself run out of solder, which is why I ceased operation tonight. Tomorrow, after resupplying, I will test out the demo receiver circuit.

Soon I will lay out the circuit board for the final set of drivers and receivers for my SAC interface. This board will convert all the incoming and outbound signals to TTL levels which I can readily manage with my FPGA boards.

I want to create a simple function using the interface - something to load and dump memory to a PC - which will just use (abuse) cycle stealing without the need for any XIO or interrupt routines on the 1130 side. That way I can stick diagnostics and sizeable test code into the machine in the interval where I am still fighting with the card reader. 

Memory addressing card repaired, all memory operational, console printer surprise, and more keypunch interface testing

1053 CONSOLE PRINTER RESTORATION

This morning, I finished up the installation of the 1053 onto the 1131, all closed up and ready to use. In order to verify that I didn't damage anything while manhandling the cover onto the mechanism, I entered a 1053 diagnostic routine into core via the console entry switches and began to test.

To my surprise, nothing typed. Not so surprising when I took a glance inside the top of the typewriter - the drive belt had broken. I was afraid that the rubber had dried too much for these belts to be trustworthy, and my fears were proven out. Why, however, did it have to happen immediately after I put everything together and checked this peripheral off as restored? Grrrrrrrrr.

Broken motor belt atop the newly reassembled console printer

1131 MEMORY CARD DIAGNOSIS AND REPAIR

I removed the card at gate D, compartment A1, slot M3, which is the address driver card which was faulty for addresses of the form '01100xxxxxxxxxxx', in  order to repair it if possible. I have a testbed to mount SLT cards, supply the three voltages they need, and to check out why the card is failing.

If the fault is in the discrete components on the card, a repair is fairly easy. I am hoping that it is a failed transistor, which has readily attainable substitutes that can be soldered into place. If it is one of the diodes or other parts inside an SLT module, the aluminum covered square modules on the card, it may be harder and more cumbersome to repair the card.

The card has eight IBM 131 discrete transistors, two 361457 modules (FTX - four 9V transistors) and two 361456 modules (AOXb - and-or-extenders), plus a multiresistor pack, a multicapacitor pack and one filter cap for the 8.3V. I am working out the wiring for this, between the general schematic in the memory ALD, the pin assignments and the card itself where I can trace out some of the connections.

Testbed to begin diagnosing the fault in the 5803467 card

A superficial examination shows all pins have good connectivity and all transistors appear to be working. The card only receives +6V for the address selection use, 8.3V for the FTX module and discrete transistors, and ground. No +3 or -3V supply is consumed on the card and the use of +6 is quite low, simply to bias the diodes of the AND function for the address selection.

I then checked the resistor and diodes of the address selection logic, which were all good. The card requires more than the usual SLT voltage levels and driving, which is why I didn't yet try to power the card and watch it operate. There is the 8.3V level for one part of the card, but it also requires a current source to feed the other half - it implements both the read driver and write gate circuit. I suspected it would take a bit of design and fiddling to get all the drivers and sinks. The 8.3V is trivial but not sufficient.

I next did some in-circuit testing of the transistors and diodes. They all operated as diodes with the correct voltage drop - treating the transistor as a pair of diodes sharing one terminal. However, when I tested the transistors as three lead devices - which gave me good results on seven of the discrete transistors but one of them was not altering the collector current as the base current changed. It was still just a pair of back to back diodes with a center wire. I had found my bad part!

It was totally consistent with the symptoms - this transistor was for addresses with bits 3, 4 and 5 of '100' which is where the problem manifested. It is marked as a Texas Instruments unit but numbered with IBM's house values - 131. I looked up some handy substitution charts that gave me a replacement type of 2N2696. This PNP transistor is not in current production but there are a few on eBay. However, it was a close enough match to NTE159 and therefore to the very common 2N3906 part.

I had some 2N3906 on hand and carefully removed the IBM transistor. Because the leads are soldered on both sides of the SLT card, removal of the leads and replacement through the cleaned out holes would take more heat and time than I wanted to apply to the card. It has thin traces linking those pads to other parts of the circuit, which might be damaged by excessive heat.

I therefore clipped the transistor off close to the can. leaving the three leads attached to the board. I formed up the new transistor to solder onto those leads and sit low enough to fit inside the card compartment without touching the adjacent SLT card. I soldered it in place, tested everything and then inserted the newly fixed card into the A1 compartment, slot M3.

Replaced transistor on repaired memory driver card (5803467)

I powered up the 1131, tested the formerly bad address range which now worked normally. I used the Storage Load and Storage Display functions (CE Switches hidden under the cover near the usage meter) to load and then check various bit patterns throughout all 16K words of memory. Flawless operation now!

NEW KEYPUNCH INTERFACE DEVELOPMENT

I began further testing with the keypunch interface and found that although everything was working well initially, after doing reads, an attempted punch hung up and after this the keypunch was again refusing to recognize a card registered in the punch station. I need to understand this in order to make appropriate adjustments.

It didn't appear that I had any connections which could feed back into the keypunch. All the punch, space and other key/switch activations are done with relays, which remain open when dropped. I sense the state of the registration relay by a reed switch, thus I am uncoupled from any circuitry.

The only direct link to wiring is the set of read contacts at the dup station and the +5V I inject to the common plate to read the signals. It may be that there is a path I don't recognize from those, which should be totally isolated by the DUP relays as they sit in their dropped state. Further, when they pick, the disconnect all my wires.

If I have an error where I leave some of my control relays picked, it could cause a problem but I don't see any indicator lights inside the interface box which would glow when I am picking any of the sixteen relays.

I am going to do some studying of the circuits in the keypunch to see what could possibly be happening here.  In the meantime I decided to work on the memory card - results reported above.