I have read posts where this process took multiple days to complete, after which I discover exactly how little or much of the disk contents are still accessible. I will buy a new disk and cloning gear, but I will have some challenges with software, keys and the like if I have to reinstall Windows and applications. More seriously, the work of the past couple of weeks might be completely obliterated.
RESTORING CALCOMP 565 AS IBM 1627 PLOTTER
Disappointing news from the metalworker who I hoped could remove the dent in the plotter drum. He believes that the aluminum is too stretched to get good results working it. The only solution would be to fabricate a replacement cylinder, but that would depend on my finding a source for the pin feed conical shaped rivets that are on the two ends.
This was one of the possible routes to repair - a substitute aluminum cylinder - but the pin feed rivets are the real fly in the ointment. A replacement cylinder would need the rivets to act as pin feed pulling paper on the drum. If the shape isn't correct, the paper could slip as the plotter moves the drum up and down or it could cause the paper to bulge up off the surface.
 |
| Pin rivets that act as tractor feed for continous paper rolls |
There are some alternate courses of action I could take. One would be to build a replacement cylinder but without the tractor feed pins (rivets). It won't be a faithful restoration because of this, but it will allow me to tape sheets of paper to the drum and run some plotting.
A very unlikely solution would be to remove the existing rivets as carefully as I can and find someone who can weld extensions to the bottom to allow them to be affixed to a replacement cylinder or otherwise find a way to attach them.
 |
| Backside of the pin rivets |
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Restructuring the GUI
I finished testing the PC side of the virtual 2501 card reader. It handles hopper empty conditions properly and will set or reset the last card status when the fpga signals operation complete.
Using what I learned, I then worked on other device drivers to have them behave properly although purely from a PC only standpoint as I am not yet testing with the fpga and the 1130 system in the loop. Next up for careful study and testing was the virtual 1403 printer function. In the course of testing, I decided to drop the Carriage Restore button and function from the GUI.
From here, I finished the PC only testing for the real 1627 plotter and real 1134/1055 paper tape devices. These serve only to activate and deactivate the fpga which controls the real devices. The 2310 device took a bit more time to accomplish.
Next up was the code to communicate over the USB link. I restructured this so that my Queueing object will instantiate the USB handling module and keep it encapsulated entirely inside. This allows me to change the USB functions independently and allows the queueing module to control how it communicates, potentially even entirely replacing the USB link with something else. Good OO structure now and tested as far as possible without hooking up to the FPGA.
Once I felt comfortable with the logic for queuing transactions, having them pulled and communicated over a USB link and responses posted back to the caller, I could start up the background process that regularly updates the main screen with 1130 status. This too took some time to straighten out.
I had some hangs and stalls, since the main screen involves three cooperating threads, but I eventually got it all straightened out. I was attempting to pass an argument to one of the GUI threads that handle the main window status signals, which caused odd problems when I naively adding the argument to the threading command. I finally figured out a method to accomplish what I wanted without the argument.
Another enhancement I made was to add in logging window support, where status and error messages can accumulate, using the wxPython logging capability. This gives me a nice window with timestamps, support for saving the log to a file and/or clearing it out, and a new Action menu choice to Show or Hide the log window. This does require that I walk through all the code, replacing the diagnostic, status and warning 'print' commands with logging calls, a tedious but straightforward process. Fortunately, logging is thread safe and works well with my many-threaded design.
I finished testing the PC side of the virtual 2501 card reader. It handles hopper empty conditions properly and will set or reset the last card status when the fpga signals operation complete.
Using what I learned, I then worked on other device drivers to have them behave properly although purely from a PC only standpoint as I am not yet testing with the fpga and the 1130 system in the loop. Next up for careful study and testing was the virtual 1403 printer function. In the course of testing, I decided to drop the Carriage Restore button and function from the GUI.
From here, I finished the PC only testing for the real 1627 plotter and real 1134/1055 paper tape devices. These serve only to activate and deactivate the fpga which controls the real devices. The 2310 device took a bit more time to accomplish.
Next up was the code to communicate over the USB link. I restructured this so that my Queueing object will instantiate the USB handling module and keep it encapsulated entirely inside. This allows me to change the USB functions independently and allows the queueing module to control how it communicates, potentially even entirely replacing the USB link with something else. Good OO structure now and tested as far as possible without hooking up to the FPGA.
Once I felt comfortable with the logic for queuing transactions, having them pulled and communicated over a USB link and responses posted back to the caller, I could start up the background process that regularly updates the main screen with 1130 status. This too took some time to straighten out.
I had some hangs and stalls, since the main screen involves three cooperating threads, but I eventually got it all straightened out. I was attempting to pass an argument to one of the GUI threads that handle the main window status signals, which caused odd problems when I naively adding the argument to the threading command. I finally figured out a method to accomplish what I wanted without the argument.
Another enhancement I made was to add in logging window support, where status and error messages can accumulate, using the wxPython logging capability. This gives me a nice window with timestamps, support for saving the log to a file and/or clearing it out, and a new Action menu choice to Show or Hide the log window. This does require that I walk through all the code, replacing the diagnostic, status and warning 'print' commands with logging calls, a tedious but straightforward process. Fortunately, logging is thread safe and works well with my many-threaded design.
There's no way that you could weld extensions onto a rivet to re-use it but this seems to be an ideal place for a 3D printed replacement part since it is pretty much used for registration rather than heavy-duty traction feed. You could model the pin top and then design a new bottom stem to go through the drum surface and solvent or thermo weld it from the bottom.
ReplyDeleteThis sounds like the solution. But don't 3d-print individual nubs. 3d-print a thin flat strip with a row of nubs on it. Said strip could be designed to fit around the inner circumference of a cylinder with many holes drilled along its edge. Or, perhaps simpler, the strip could be designed to fit around the OUTER circumference of a cylinder that had a recessed band at the end, so the strip would lie flush with the surface.
DeleteOr maybe: 3d-print the whole cylinder. Probably no home 3d printer is big enough to do this. However, it could be 3d-printed as a series of rings, with interlocking tabs on their inner faces. Then the cylinder could be glued up from the rings.
To get the needed strength the printed cylinder would have to be thicker than the aluminum, probably. Which would make it heavier. Does the plotter mechanism depend on the low polar inertia of the aluminum cylinder?
Re the laptop: SpinRite. https://www.grc.com/sr/spinrite.htm
ReplyDeleteIt is much more likely to recover the HD to operating condition than the built-in recovery.
If you can get the old rivets off with enough shank left to locate them in the holes on a new cylinder you might be able to plug weld through the holes. Chances are you would not get them all off undamaged and so would need to make a few new ones anyway. Have you access to a lathe?
ReplyDelete