I quickly discovered that I want to spot weld nickel alloy strips across the cells, not solder them, to prevent heat damage to the battery cells. For $100 or so I can buy a spot welder, but that is hardly justified to produce this single battery pack.
Instead, I poked around the internet looking at various DIY types and came to a plan for a very inexpensive, quick and dirty welder. Motorcycle battery charges capacitor bank through a light bulb, car starter solenoid releases the energy to the weld when a button is pushed. Parts are on their way here.
The nickel plated steel strips are on their way to me, while I pull together the parts for the welder itself. I will do a bit of practice welding on the old dead cells I removed before risking my new ones.
KEN DIGS INTO THE IBM 1401 SYSTEM CARD READER LOGIC (1402)
Ken Shirriff has sunk his teeth into the challenge of understanding the rat's nest of connections, relays, cam based switches and processor logic that comprise the 1402 card reader/punch. The 16 pages of diagrams have evolved over years as IBM added feature after feature to the machine, so that every page has dozens of off-page connections and some on-page connections that were not drawn as connected lines.
Trying to trace a signal involves paths through a myriad of relay contacts and cam based microswitches, introducing a time based aspect to the schematic that is hard to understand. That is, some paths are connected at specific ranges of degrees while the main motor mechanism rotates, but not others. Other paths are connected at specific ranges of degrees as the clutched part of the machine moves cards along.
With more than 16 relays, having four to six pairs of contacts each, plus about two dozen of the cam based switches, and several contact switches for card positions within the path, this is a dense mesh of signals. Trying to follow them off page, when the signal can be moving in either direction, boggles the mind. Some few places have diodes to introduce directionality, but most spots have multiple wires hooked together with unhelpful, obscure labels.
Our recently fixed problem on the 'German' 1401 system, where sequences of card read and print operations would trigger false reader errors and stop the mechanism, pulled us into this mysterious world in order to resolve the issue. However, while we could see what was failing and the conditions that triggered it, we didn't understand how the conditions arose.
Ken has reached the point where he knows why our test program - read, print, read, print, read, print, read, halt - would fail on the last read pretty steadily. The 1403 line printer operates at 10 lines per second while the card reader runs at roughly 13 cards per second. The printer itself is busy for 84 milliseconds printing a line, the remainder of the time is spacing down one line but a subsequent print operation could be accepted to overlap the spacing.
When you look at the 84ms cycle of the printer and the shorter cycle of the card reader, they lead to a delay in accepting the third print operation. That pushes off the time when the program issues the read operation, which pushes it out to a range of degrees of card reader motor rotation where the clutch does not have enough time to engage.
The clutch has an outer ring of inward facing teeth that rotates with the motor, while the inside shaft has a pawl that will be pulled out to engage a tooth whenever the clutch magnet is energized. The inside shaft is therefore connected to the motor and rotates one revolution, at which point the pawl is forced out of the teeth and ends inner shaft movement.
The cam based microswitches in the reader are set to control when the clutch magnet can energize within a motor rotation. These are the times when it is possible for the pawl to reliably engage a tooth. The signal is blocked when the window of opportunity closes, until the next tooth is in appropriate range.
We had misadjusted cam based microswitches, which allowed the read request from the processor to energize the clutch magnet too late, resulting in a missed tooth. With proper adjustment, the reader would have held off until the next tooth was in position, then clutched in. One third of a motor rotation brings each new tooth in position, so the delay would be about 25 ms before firing off the reader.
The reason for a 1/3 delay is a feature added to the card reader to speed up operations. In the original design, if the mechanism missed the window to energize the clutch, the motor would spin almost one rotation to bring the single tooth back in position. The early read feature introduced three teeth at 120 degree positions, three lobed cams for the cam based microswitches, and therefore a read request would have to wait no more than about 25 ms instead of a maximum of almost 75 ms.
The triple lobes introduce complexity in understanding the behavior of the reader, but we can simplify the logic if we imagine the machine with only a single firing point. The essential issue was still that the cam switch allowed the clutch to be energized when the shaft was too close to the tooth to reliably snag it.
Our failure was detected by the reader by a comparison between the contacts of a Clutch Check relay and other relay that will be activated only the movement of the inner mechanism which moves cards forward. If a request comes to feed a card, the Clutch Check relay activates immediately and then the clutch magnet energizes.
In a good feed, the inner shaft rotates, the cam based switches on that shaft will turn on other relays, and we will see agreement in the relay statues. If the pawl does not engage, then the inner shaft based relays don't engage, causing the mismatch with the activated Clutch Check relay. This latches the Reader Stop relay, stops further reading and triggers an error back to the processor.
For the simple case, cards have already been moving through the reader and new cards are sitting in the hopper, then each time the clutch engages, we move cards, write the presence or absence of 80 column holes for each of 12 rows the come past, and let the processor convert that into 80 characters in memory locations 1 to 80.
Cam based switches on the inner shaft (RL CBs in the diagram) determine when each of the twelve rows of the card, (12, 11, 0, 1, . . . 9) have passed under the brushes and updated core in special core planes dedicated to the card reader. The processor logic will quickly scan through the 80 locations and process the holes, updating its detected character. When the last of the twelve are processed, the card is simply finishing its movement to stop at the next location.
It is more complex when the reader has no cards in it, or the hopper emptied but one card is still inside. Two card detecting microswitches, card levers 1 and 2, activate relays CL1 and CL2 which determine whether we have the simple case or one of the exceptions just discussed.
These also participate in detecting jams, since there is a small window between cards when the CL will turn off. If it doesn't, we had a jam. Other switches are placed in the path to detect jams, but have no other role in reader operation.
If an empty reader has a new deck put in the hopper and the Start button is pushed, it must feed twice to read that first card. The first feed moves the card under the Read Check brushes but there is no card moving through the next station (Read brushes) so the actual update of core has to be blocked. On the second feed, everything is normal. The CL relays are part of the logic that determines which state the reader is in.
If either CL is activated, then there are cards in the machine, either between Read Check and Read or in the hopper. If the machine is powered up in this state, it requires you to get to the known good condition of empty card path. You do this by lifting the cards out of the hopper (CL1 now off) and doing a NPRO (non-process run out) to move any internal cards to the stacker and shut off CL2.
If CL1 isn't active but CL2 is, at the end of reading a stream of cards, this means that the hopper has gone empty. If the Start button is pushed with CL1 off, it will feed once to read the final card and the reader is empty at the end. This sets a status bit that can be interrogated to detect that the last card of some deck has been read. If Start was not pushed, then the machine waits for more cards (CL1 will activate when hopper filled) then it resumes reading with Start.
The punch side of the 1402 has almost as much complication on its own, with separate motors, clutches, card levers and cam based switches. We are ignoring that until the read side is understood. More in future posts as Ken completes his analysis.
haha, OK this answers my question from last month. ;-)
ReplyDelete