FINAL FIX MADE TO BYTE ORDER OF WORDS, FLASHED ARDUINO WITH THE CODE
After I adjusted the code to send the two bytes for each column in the order expected by the CARDREAD.EXE application, I flashed that sketch, without a bootloader, to the Arduino Mega2560 inside the external interface box. It was ready to test. That was the last fix, as the unit now reliably read the card images into the file as displayed by the companion DECKVIEW.EXE application.
 |
| Cards faithfully captured |
STARTED WORKING ON THE ARCHIVING OF WELL OVER 100,000 CARDS
I can now begin the highest priority task I have, the reading and archiving of all the boxes of punched card programs and data that I hauled with me from California. I begin with around two full boxes worth of cards, consisting of various programs and test data.
It takes a while for a deck of cards to read correctly - they are a bit sticky from the years of storage, thus from time to time there is a bit of drag as one card slides off the deck. This can cause the data in certain columns to be read as the adjacent column.
To catch these issues, I read the file and then pass the deck through again in verify mode, where it reads them and compares the data to the stored file. When I get a verify error, it can be an error made during the second pass or it can be an error in the pass that was captured to the file. It takes several tries to figure out which is correct and to get a stored file which verifies properly. Different decks, varying in condition, read with more or less issues and take different numbers of passes to complete.
The time it takes to make all these passes and yield a verified fail slows down the rate of reading dramatically from the nominal rate of the hardware. The Documation model 600 can read 600 cards per minute at full speed but my net rate of finished reading is only 1200 cards per hour. That is about 30 times slower than the theoretical. This means that it will take about 100 minutes, one and two-thirds hour, per box to archive.
BUILDING INTERNAL INTERFACE FOR DOCUMATION 1000 READER
I now have a reliable Arduino based controller for the reader which I will install inside the other card reader I own, removing the need for an external box and cabling to drive the machine. A USB port on the rear of the reader will let me link it to the card reading application on a PC.
I have a shield that consists of a set of holes I can attach to wires, linked to each of the Arduino pins. It forms a compact sandwich with the Arduino that will easily fit in the gap inside the Documation card cage between PCBs 3 and 6. The two unimplemented card positions 4 and 5 are a comfortable space.
I began soldering the wires from the Documation cards that had run down to the external cable connector, but are now available to hook to my shield. When these are done, the only remaining task will be to build a card sized base that slides into slot 5 and supports the Arduino/shield sandwich.
I had previously installed a pushbutton and LED for the End of File function that is part of the card reading application process. These hook to assigned pins on the shield just as they do in the external box I finished debugging this morning.
Can you "bake" cards in a dehydrator or low oven like you can for certain audio and video tapes to reduce their stickiness?
ReplyDeleteI don't know the answer to this.
ReplyDeleteWith tapes the worry is flaking of the oxide that permanently loses the data - the heating reflows the glue slightly to reduce the risk of flaking.
Fortunately with cards there isn't a similar risk.
Funny discovery while reading the cards, since they had been repacked into trays when I picked up the system originally, I found a few cards where there was a bit of decayed rubber band stuck between two cards. Fortunately the Documation could properly read the cards after I removed the foreign debris.
Well, with tapes one failure mode can be the oxide flaking, but another failure mode occurs when certain binder formulas absorb enough moisture that it becomes sludgy and will stick to, well, pretty much everything. (I experience this frequently with mid-70s open reel video tape). In the latter case the baking drives out the moisture and reactivates the binder, at least temporarily.
ReplyDeleteIt's the sticky-shed angle that made me think about it: assuming the cards have the row grids printed on them, it occurred to me that depending on the formula the ink might also deteriorate in a way that would encourage it to stick to the card on top of it. Not a lot, mind you, but just enough to matter in a high-speed application operating with a fair amount of precision.
And also more generally whether the card stock may have taken on humidity if it had been stored in suboptimal conditions for any length of time and how that might be a factor.
Anyway, just thinking out loud. Glad to hear the reading project seems to be moving well.
I learn something new every day. Thanks for the explanation of the sticky binder behavior with tapes.
DeleteSome of the card stock, after it had absorbed quite a bit of moisture in its original Kansas setting, had the faces of the cards get a bit 'fuzzy'. That might be increasing friction as the Documation tries to fire the card into the throat to be read.
The machine and the cards sat in a large commercial building - three floors plus basement - of a business that shut down a few years previously. The roof had deteriorated, letting rain into the upper floor, and the owner understandably wasn't running air conditioning or heating.
The result was some moisture on the machinery and the cards had all swollen to be thicker than the official spec. On an IBM card reader, which depends on a carefully adjusted slit and a well machined picker knife, these would have all jammed and refused to feed. The Documation with its air plus vacuum system is much more forgiving.