Flakiness multiplies but I hunted the cause down; reader working excellently now; debugging of my cardread.exe commences

 CAREFULLY PREPPED FOR MY DEBUGGING SESSION

I had printed the schematics, written out a solid plan and set up the logic analyzer to help me capture the flaw in the Good Pick Reset (GPR) signal generation. The extender had to be moved to the Clock board which is where this circuitry resides, then I powered up to take some readings.

PROBLEM SHIFTED DRAMATICALLY, BACK TO AN EARLIER ISSUE

When I fired up the reader to read some cards, it was failing in an new but old way. The logic analyzer showed me that GPR was issued, but it came BEFORE the start of the card read and well before OneDark should be generated. Yet, that signal was showing as true.

I had the VOM out and probed some signals to get an idea where to begin troubleshooting this problem. I uncovered an invalid voltage of 1.6V on the motherboard line for OneDark. This is right in the forbidden zone for logic values. 

This is enormously frustrating. A set of symptoms crop up, I set up to debug them but the reader shifts to a very different behavior that requires entirely different debugging actions (and test points). 

SWAPPED SOME BOARDS, PROBED SOME CHIP OUTPUTS AND THOUGHT DEEPLY

I pulled the Control board that generates OneDark, powered it independently and probed a chain of chips and signals to try to understand the improper voltage. The card, however, was working exactly as it should and driving completely valid levels for OneDark, OneLight and all twelve rows of data. 

That led me to look at all the destinations for this signal on other boards, to see if one of them was dragging the levels down. The Error and Clock boards are the other two involved, both of which I swapped with the same cards from the M600 reader, but nothing changed. 

I popped the VOM on the backplane pin 6 for OneDark and saw it was indeed registering 1.6V while the card itself had 3.7V present on the finger plugged into the backplane. That was when I realized I might have a continuity fault or short between traces somewhere.

After quite a bit of testing across the boards and backplane, I narrowed the issue down to the backplane itself. I disassembled the reader to tilt the card cage up for close inspection. I tested adjacent pins for shorts, but that wasn't an issue. I then tested for continuity between the six rows of pins for each signal and voila!

The signal for pin 6 ran properly between cards 1, 2, and 3 but not down to card 6, the Control card that generates OneDark. All other pins had full continuity, but not this one. Further, upon close visual inspection I found a hairline break such that I would have periods of good connectivity, periods of lost connectivity, and periods of erratic connections.

Very tiny break in trace discovered

A jumper wire across the backplane bypassed this problem and everything went back together rapidly. Filled with anticipation, I first tried the manual feed switch on the back and watched it process an entire deck just as it should. I next hooked up the laptop to the controller and did a proper read of the cards.

SUCCESSFUL READING INCLUDING MY RIGHT HAND DIAGONAL NOTCH FIX

The cards I read were correctly captured with no false Read Checks from the cards with a right hand notch. The deck had sequence numbering in columns 72 to 80, so it appears I could properly capture data out to the end. I will conduct one more test tomorrow to prove to myself that row 12 in column 80 is being read correctly, but this seems quite promising.

I whipped through a half box of cards with right hand notches, containing part of the IBM 1130 COBOL compiler. The reader was faster and more accurate than the M600 I had previously been using. I look forward to completing my archiving task with this reader.

FIRST DEBUGGING OF MY VERSION OF CARDREAD.EXE - MIXED RESULTS

The version of the program that I had modified and compiled was driving the card reader while I was reading cards. It appeared to be working properly however I noticed one flaw immediately. The original version displays the characters across the top of the card image along with the hole pattern when reading in binary mode. My version displays nothing but ? characters. 

I finally had a verify failure occur where I could test out my new Truncate button that is intended to truncate the file at the last properly read and verified card image. I pushed the button but it did not gray out, nor did it work properly. When I opened the card file it was empty. Truncated, but not to the intended card image.