Observations from analyzer trace leads to verification of logic on Clock card

 OBSERVATIONS FROM THE LOGIC ANALYZER TRACE

Picking a card starts a timer while circuitry waits for the leading edge of a card to block one or more phototransistors. If the timer counts to zero it triggers a pick check since the card didn't make it into the read station. This should happen when a card does not get pulled into the mechanism. 

In this case, I see the OneDark signal go active when the first edge of the card hits the read station. This should trigger a Good Pick Reset (GPR) signal but that doesn't arrive. With GPR, all the other timing begins, the reader resets the pick timer and signals it is busy. 

Because we don't see the GPR, we don't activate busy nor start into the process of reading this card. Instead, the reader remains Ready without a Busy condition so that the pick is issued again to pull in the next card. We get several cards feeding through in a row before the pick timer counts to zero and triggers our Pick Check. 

The logic to create the GPR from the OneDark requires that a Pick Reset (PCR) be generated as the pick is accepted. I can't see if that occured since the trace starts much later in time after the card has reached the read station. One thing I will verify is the correct issuance of GPR as part of the picking. 

If that occurs, then we are dealing with three flipflops and a handful of inverters and other gates that sit between the poweron reset, PCR and OneDark as inputs and the GPR as an output. I will put the extender on the Clock card to give me access to the chip pins then begin shooting this more fully when I get to the shop. 

Circuitry generating GPR

Gremlin found and exterminated; M1000 card reader still not working

 THE CLUE THAT LED ME TO THE PROBLEM

I noticed that at some positions of the card cage, which was unfastened to let me get to the rear connections, the lights went out even though the blower motor ran. I checked the voltage on the rails of one card and found it was zero!

Some jiggling convinced me that the conductors in the wires had breaks or defective joints. There are a couple of areas covered with insulating wrap which may have solder joints inside. Rather than try to patch them up, I will replace the wires entirely. 

I stripped and soldered the wires on very carefully to be sure this doesn't cause future issues. Once I had reassembled everything it was time to try some runs to continue debugging and repair.

ON TO THE NEXT IN A SEEMINGLY INFINITE SERIES OF MISBEHAVIORS

The reader stays powered and responds well to the controller, but no data came out. The same pick error is occuring, where it passes a few cards past the phototransistor station but acts as if the cards didn't move. I turned on the logic analyzer and captured the signals to determine what was behind the issue.

When a pick is issued and the reader grabs a card, it waits until the OneDark signal is activated which indicates that the leading edge of the card has reached the phototransistor station. This will trigger a Good Pick Reset (GPR) signal that kicks off all the remaining steps in reading the card.

I see the OneDark go active, but no GPR is issued. The magnetic sensor pulses seem to be arriving okay, but the reader sits as if no card passed through it. 

I want to look carefully at all the signals I collected in the logic analyzer to see what anomalies might exist alongside the failure of the GPR signal to be raised. The logic analyzer prints an ASCII listing file of the signals, which I put on a 3.5" diskette and transferred over to my laptop. Tonight I will pore over the files and devise a set of tests to zoom in to the ultimate.

Found undocumented modifications to both Documation readers that cause problems

 INVESTIGATING THE ISSUE WITH RIGHT HAND DIAGONALLY NOTCHED CARDS

The Documation does error checking by testing whether any light is visible to the phototransistors at the time when the card is just past the last column (80) of data. Punched cards can be made with a diagonal notch on the upper section of the left or right hand side. This reader is known to issue a Read Check in error for any right hand notched card. 

The logic of the matching will count card columns, beginning with the first moment that the leading (left) edge of the card obscures the light to the phototransistors. It counts up with column 0 being the space just to the left of the first data on the card, eighty columns of valid data, then the trailing side is column 81 before the right edge clears the phototransistors. 

At the time of column 0 and again at the time of column 81, it verifies that none of the 12 phototransistors, representing rows 12, 11 and 0 to 9, have light reaching them. If any of the transistors sees light, a Read Check is indicated. The machine also tests at the time when the counter reaches column number 84 to be sure that the card has fully and completely moved beyond the phototransistors; if any of the rows is darkened then a Read Check is also generated. 

The failure in this card reader occurs when the highest phototransistor, reading row 12, sees some light passing through because the diagonal notch reaches the row 12 area. At column 81 time, row 12 is illuminated and we trigger the error. The diagonal notch also passes row 12 light at column 0 time, but by time the check is made it has moved over the light enough to pass the test, due to technicalities of when the state of the light is sampled and when the 'dark check' is made at CR0 and CR81 times. 

MY MODIFICATION SHOULD HAVE FIXED THE ISSUE BUT WAS NOT WORKING

I created a modification that forced row 12 to appear dark while the signal for column 81 is active, thus the 'dark check' passes as long as rows 11 and 0 to 9 are all dark. It picks up the CR81 signal, triggers a MOSFET transistor that will pull the row 12 wired-OR junction down to ground which logically represents a dark phototransistor. 

I still saw Read Check errors with right side notched cards. I put the scope on it, triggering on the CR81 signal in anticipation of watching the row signals and other signals involved in the 'dark check' at the same time. What I saw, however, was two CR81 signals. That shouldn't happen. I was getting the signal for both column 81 and column 82 times, but by the time of column 82 we would also have light hitting row 11 and maybe 0, thus generating our error even though I was blocking row 12. 

I ran the logic analyzer and saw the two different CR81 signals. The reader turned off the flipflop that sends the index marker pulses to the controller after the first, but the column count continues to increment until it reaches 84 and terminates the reading cycle. The second CR81 arrived just about ten microseconds after the light spilled around the notch and illuminated the phototransistor. In comparison moving one column takes about 500 microseconds so we caught the light in the last 2% of the column movement. 

DIGGING INTO THE DUPLICATE COLUMN 81 SIGNALS (CR81)

I looked closely at the PCB where the CR81 signal is generated and began to move the scope probe around to check the cause. The first place I was going to probe was the pin on the 8 input NAND gate which looked at the low order bit of the column count, as the failure symptoms suggested this was the cause. There was a resistor tacked onto that pin and the other end pulled the input up to the VCC rail!

low bit input pulled to VCC

That forced the input to be 1 for two different column times. This is why I was getting doubled CR81 pulses. Looking closely at the card I could see that the trace connecting the low bit of the counter to the NAND gate had been scraped away. This was a deliberate modification.

Modifications I discovered on clock card

Oddly, the other reader I have, an M600 model, has the exact same modification made to it! None of the schematics or other manuals for Documation readers show this or explain it. I removed the resistor and restored the link with a jumper wire. The machine read a group of cards including several with right hand notches without a Read Check!

All that remained was to read some cards including those with valid data row 12 of column 80, to be sure my modifications didn't break anything. Alas, the flaky behavior returned.

ERRATIC BEHAVIOR RESUMED

The position of the card tray determines whether the reader logic works and even the signal lights illuminating for state such as Stop and Reset. Various failure modes crop up based on whatever intermittent contacts are causing this issue. 

I will have to get to the bottom of this failure mode and correct it once and for all if I am going to be able to wrap up the repairs and use this reader to archive the remaining cards. I left the shop because I want to be situation for the SpaceX launch later this afternoon, but I am determined to root out and eliminate this issue when I next visit.

More erratic behavior from M1000 reader

 FAILURE TO COMPLETE A READ CYCLE, MOSTLY

I hooked up the reader to my laptop with my modified cardread.exe application, thinking I would be debugging the modification that lets me accept the portion of a verified deck prior to a mismatch stop using the new Trunc button. 

I had a short initial period where it read cards into the application, but the blank card on the end, with its right hand diagonal notch, triggered a Read Check. Since I had a modification to the reader that should block that, I turned on the oscilloscope to observe the issue. It would trigger at CR81 time (when the card to the right of column 80 is under the read station), letting me check for the source of the error condition. 

While I saw one or two pulses from CR81, the reader moved on to failing to read at all. It would pick a group of cards but not send any data to my controller. Looking at the logic analyzer, it wasn't recognizing a good end of the pick so that it was really moving multiple cards while believing that it had mispicks being handled by reissue. 

ORIGINAL FLAW WAS CONTINUOUS ONEDARK SIGNAL FROM ROW9

When I last saw this pick failure symptom, the signal from row 9 of the card was triggering OneDark, as if that row was obscured (by the card body without a hole in the location). Since this was steady, the circuitry couldn't detect the proper start of the card and thus read garbage data. 

The problem went away by itself but I did reflow all the solder connections in the row 9 signal path. This time, both OneDark (one or more rows are blocked) and OneLight (one or more rows has light falling on the phototransistor) were working properly.

ANOTHER FLAW WAS ABSENCE OF MAGNETIC SENSOR PULSES

Another earlier episode of balkiness was characterized by lack of any pulses from the magnetic sensor reading the toothed timing wheel. My preliminary look at the logic analyzer implied these are working properly. I had only a short time at the shop thus will have to dig into this when I return. 

I am not happy at all because of the many and varied sporadic failures I am seeing in the circuitry. I can't just swap the cards from the M600 because there is a preset built into the card based on the reader speed - 600 cpm versus the 1000 cpm of the machine I want to get working. 

Adjusted M1000, now operational, but right side notch fix not working

 ADJUSTMENTS MADE

With my spring scale to determine proper belt tension, I was able to set the motor mounts in the proper position so the belt won't skip teeth or be overstressed. I then put the timing tooth wheel back on the shaft, adjusted it planar with the center of the magnetic sensor and verified that the gap between teeth and sensor pole is .007".  The reader is back to reading cards.

TRIED A RIGHT SIDE NOTCH CARD BUT RECEIVED A READ CHECK

I had made the modification that I believed would fix the issue with cards having a diagonal notch on the right upper side of the card, wherein the card reader throws a spurious Read Check error because it sees some light at a time when it thinks, at column 81, all cells should be dark. 

I will have to put the scope on the card to see what is actually occuring. I may not be picking up the CR81 signal that indicates we are at column 81 time, I may not be correctly pulling row 12 down to a dark state, or there may be some other issue I didn't anticipate giving me the error. 

Varied tasks at shop while waiting for scale and drive belt

 WAITING ON TOOL TO FINISH M1000 CARD READER REPAIR

In order to set up the card reader after I swapped in a drive belt from the M600, I will need to set two adjustments, using a feeler gauge and a spring scale. Until the tool arrives tonight, I can't get any more done on the reader. In the interim I accomplished a few minor tasks in the workshop.

TESTING MY MODIFIED CARDREAD.EXE APPLICATION WITH NON-WORKING READER

I hooked up the laptop to my external interface box for the M600 card reader. Although both readers are currently not operational, I could at least verify that the modified application communicates with the interface and picks up status correctly.

I was able to connect, see the hopper and error status that occurs when the reader is not powered on, and watch the EOF status reflect the pushbutton and LED on the interface. I also checked that the new "Trunc" button is disabled when it is not appropriate to use it. 

It should only enable when we are verifying a binary mode deck and have at least one card that matched, after which a miscompare occurs between the originally read file and the one being passed through the reader for verification. It will be reset by use of the button or if either the Start read or the Verify buttons are activated. I need an operational reader to test out that functionality and the proper truncation of the original file to the end of the last correctly verified card. 

DISASSEMBLING M600 PICKER MECHANISM TO DEAL WITH ITS ISSUES

When I attempted to set up the M600 reader, the step that sets the picker foot .002" above the vacuum input plate caused it to lock up and not feed. I had to open the gap quite far before it no longer got stuck. The surface between the vacuum plate and picker foot is roughed up, causing the binding. Without a good tight seal the reader doesn't have enough vacuum to guarantee good picking, which is an issue resulting in not only pick checks but errors reading or verifying.

Opening the picker mechanism to restore it

I wanted to disassemble the entire mechanism, smooth the roughed up surface, correct any other issues and get this back into spec. After disassembling things I noticed some magic marker with .010" written near the foot - clearly the setting that let tried to balance low vacuum with the binding of the rough surface. I also see that the shaft on which the picker foot is hooked is chewed up a bit by poorly positioned and tightened set screws. 

Signs that this reader had problems

PUTTING THE IBM 1130 CONSOLE BACK TOGETHER

I had developed a single large PCB with mounted incandescent lamps as a replacement for the poorly designed original boards with SCRs and lamp holders that are a nightmare when a bulb needs replacing. Now that my board is working properly and fits well into the honeycomb, I had to reassemble the console pedestal where these lights will reside.

The plastic honeycombs have the faceplate attached with the legends and openings for the roughly 160 lights. They screw into metal brackets on the sides which themselves are bolted to the insides of the enclosure. On either side of the faceplate there are white metal rectangles that hold the Emergency Stop and Run Mode Switch. These are bolted down to the front of the enclosure and adjusted to fit with uniform gaps to the faceplate. Finally there is a terminal strip that brings the AC power, lamp test and ground lines to the enclosure. 

Run Mode switch from the back

Emergency Stop pull switch from the rear

In addition to the strip, there are about 160 individual wires with clips that push onto pins for each of the lights to be controlled. My PCB has pins in the same relative positions as the multiple small PCBs IBM used. It will be easy to plug them in once the light PCB is placed onto the rear of the honeycomb.

I need to make up some soft wedges to hold my PCB against the rear of the honeycomb, otherwise we are ready to install it and wire it up for testing. There is one other contingency before I can test - I need to get a 240V outlet installed in the workshop. 

FURTHER TESTING OF THE P390 SYSTEM 

I brought up the P390 system, having corrected the seating of the Intel Ethernet card in slot 2. That was giving errors when OS/2 booted up, but now everything comes up cleanly.

I had been worried about the CMOS battery status but with a proper battery installed it has been holding its settings for weeks of downtime. I feel good about the state of this system. Ahead are efforts to connect the 3174 terminal controller to the P390 via WAN cables and to install and configure my 370 parallel channel card for bus and tag peripheral access.

Cardread.exe successfully recompiled, now introducing my modifications

 RESOLVING THE STRCMPI AND STRNICMP USES TO MAKE THIS COMPILE

I wrote my own version of the case insensitive functions strcmpi and strnicmp, inserting them in the code, which made the Pelles C compiler happy. I built the executable and it executes fine as far as tell without connecting it to a working card reader. 

ADDING IN MY MODIFICATION TO TRUNCATE A FILE UP TO THE POINT IT VERIFIED

This enhancement was inspired by the high frequency of verification failures as I read decks with the M600 card reader. I realized that I was often reading 100 cards, verifying to a point through most of the cards and failing on a verification error. I may have to verify again a few times, or re-read and then verify but the process required me to pass the entire 100 card deck multiple times. 

If I could tell the program to just trim the file I had read to the last successfully verified card, I could put those away and resume with only the remaining cards to be re-read and verified. For example, if the bad card was number 76 then I only had to read and test 25 cards as the first 75 are known to be good. 

To achieve this, I add a "Truncate" button on the GUI which is active only when we are in verify mode, reading cards in binary format, and have just encountered a miscompare on some card. The button will cause the file I had been reading for the comparison to be opened in output mode and truncated to the point of the last good card. 

The M1000 reader was reading much more reliably, thus this enhancement is less necessary than with the troublesome M600. Still, I did the design work and have invested time thus I will complete this project and make use of the button for the infrequent cases where I get a verify error going forward.