It appeared that I had an issue, as some letters were issued in place of the planned character, but when I looked at the character chart to spot which solenoids or mechanisms might be at fault, it was obvious that the Rack Shift solenoid was never firing. That solenoid determines whether the typeball rotates in one direction or the other from its central 'home' position.
The typeball has six steps of rotation to the left and another six to the right, with the rack shift setting the ball at its left-moving home or its right-moving home position. IBM manuals refer to these as + and - directions, so the typeball can be at +5, +4, +3, +2, +1, +0, -0, -1, -2, -3. -4 or -5 position of rotation. The rack shift is the 'sign', + or -, for rotating.
In addition, the typeball can be tilted to one of four levels, 0, 1, 2 or 3. The combination of the tilt and rotate choices select one of 48 characters on the type ball hemisphere. Shifting between upper case and lower case involves rotating the ball 180 degrees, changing the hemisphere that is facing the paper, which doubles the characters available to 96. If you consider a space to be a character, as it would be on a computer where it has its own code and takes up the same 'space' as any other character, then the machine can type 97 characters.
I had forgotten one minor detail in my Arduino code - I didn't set the pin for the Rack Shift solenoid to be an output, which defaults it to an input and it didn't command the typewriter to do a rack shift. A quick update to the Arduino code, which is in a simplified version of C, and it was able to get the proper characters issued. I set it up to run multiple times, working through various characters and combinations. Unfortunately, that highlighted some sporadic mal-selection, as IBM terms it in their manuals - times when the letter on the paper was not the one you asked it to type.
What I discovered is that the two lowest sliding vanes in the pin block will sometimes hang up a bit and not select the right pin even though the solenoid has fired. I have made contact with a dealer/repair shop in Austria that has some NOS spare parts (new old stock). NOS means the parts were never used and sat in his inventory for years, because no new spares are being produced by Lexmark who continued the typewriter/printer business when IBM exited that business segment.
The easiest and most reliable fix would be to buy a NOS pin block, which would be free of these balky behaviors. The last official spare part price was $528, high in part because the machine sold for many thousands of dollars back in the early 1980s, not because the materials, manufacturing effort or anything else warrants that price. The dealer in Austria is kindly offering it for a much more reasonable $125, but that is still a high kind of price if I can get the typewriter to print well with the existing pin block.
The rotate cam is $28, which is more understandable since the plastic cam is machined after the basic shape is built. With a new pin block, it probably makes sense to have the cam replaced, removing the weird channel I had to dig. I had also asked about the ribbon cable, since mine had been ripped and had to be repaired. The cable is priced at $48. That decision is easy, at least. I will not be replacing the ribbon cable.
I will putter around with the pin block a while to see if I can coax it into a low enough error rate to live with. I can tolerate one wrong character per page maximum. Otherwise, I will be buying the $125 pin block, the $28 cam and paying the $28 shipping, plus I will have to wait forl the package to wend its way around the globe to my home.
 |
| Disassembled pin block and solenoids |
 |
| Input board with all but one chip installed |
I switched all the fast protocol links from the PMOD connectors on the Digitlent board over to positions on the FX2 100 pin connector, as those signals have only a 75ohm resistor in series and will be much easier to impedance match than the PMODs with their 200 ohm protective resistors. The twisted pair cabling I will be using averages around 75 ohm impedance, thus a good match being driven from the FX2 connections.
Monday - The typewriter is now very reliable by hand and when directing a single character under power by firing the selection solenoids and kicking of PSCC, but still erratic with the Arduino based test code. Before I conclude that I need a replacement pin block, I have to exclude these possibilities:
1) bouncing of the reed switch for feedback
2) erratic connections from Arduino testbed
The PFB reed switch that tells me when the print cycle has hit 85 degrees and 300 degrees of rotation is used to turn off the solenoids for selection at 85 degrees, as well as stopping the PSCC signal. If this is firing too early, I might be dropping the solenoid before the cam is at a point where the pin will stay engaged. If it bounces, my simple logic in the Arduino might think the entire print cycle is done and begin commanding the selection of the next letter to type. I will put the logic analyzer on the PFB switch and see what is actually occuring on that signal line. If bouncing is occuring, I will do some debouncing in logic and some protective delays in the Arduino testbed.
The input lines to my typewriter driver board are temporarily soldered to pin ends suitable for sticking into breadboards or the headers on the Arduino, but the pin diameter is a bit small for either kind of hole into which it will be inserted. Thus, with the vibration of the typewriter during the sequence of printing and moving, the test setup might vibrate those pins and yield erratic connections. If the selection signal is not asserted or drops in and out, that would produce a mal-selection (I still find this IBM term tortured and bizarre, thus I repeat it whenever possible). To test this possibility, I will move the testbed to an isolated foam spot nearby, isolate the typewriter with a foam bed, and stick some spare pins in alongside the wired pins to wedge the key connections firmly into the Arduino header.
Finally, there may be an issue with the Arduino itself or the code I wrote, which I will exclude by instantiating a very simple test driver in the FPGA to output the same sequence of characters as the test bed, ensuring that the wiring is equally firm into the FPGA expansion board header I will be using.
The logic analyzer confirms clear bouncing of the reed switch, after it activated, it bounced back off for a microsecond at t+10us, then flipped once again at t+15us for a duration of 3us, but was rock steady from 17.7us after the switch onwards. Based on the nominal print cycle duration of 67.5 ms, each degree of rotation takes just under 188 microseconds. I can debounce for about 500 us, passing the changed signal value immediately but blocking any effect of changes during that interval, less than 3 degrees of rotation, when the timing we are looking for is much grosser, flipping on at 85 degrees and off again at 300. Any test to ensure the PFB is in the proper state for a new character will be accurate by 303degrees which is well within the time needed to fire PSCC for the next character before the rod rotates to the latch position and has to stop. This keeps the rod rotating continuously to reach the maximum print rate possible.
The erratic selection was not dependent on isolation of the testbed nor of any efforts to guarantee a firmly seated connection. That potential cause is excluded.
In reviewing my Arduino code, I was embarrassed to see that some of my test conditions were coded as "if (signal = condition) {. . .}" instead of the correct "if (signal == condition) {. . .}" using the equality comparison operator instead of the assignment operator. Switching between Python, Arduino C and VHDL, plus operating a brain that is 62 years old, leads to these kinds of errors. Code now cleaned up and I have inserted some sorta-debouncing logic, delaying 1 millisecond before interrogating the status of PFB while the cycle is progressing. In other words, the check for 300 degrees is delayed 1ms from when the Arduino finishes changing signals at the 85 degree point, and then there is a 1ms delay before returning from the routine doing the printing so that the test for the next character will see a stable PFB status.
With the changed code and debouncing in place, the result of my print sequence test on the Arduino was not confidence inspiring. I added a long delay between characters but that was perhaps worse. Possibility is that the start-stop of the print cycle is causing more bouncing of the selection pins but it might also be erratic rotation of the print mechanism which can cause these problems. I must complete the fpga test logic and use that in order to rule out all the possible Arduino testbed problems. plus I can look for various conditions I suspect and latch/report them.
The testing of the LED board was completed and it works perfectly. Once I have the exact dimensions of a real 1130's light panel, I will build the final matrix of LEDs and the pedestal enclosure.
 |
| Completed LED Driver Board |
- flaw in my driver board causing misfires, e.g. power supply sag or cross talk or ???
- bouncing of reed switch at start of a print cycle due to vibration, prematurely signaling the time to release the solenoids.
- noise induced on cabling that is mistriggering or blocking triggering of solenoids
- defect in the logic of my arduino test program
- flaky connections of pins into headers of Arduino and fpga board
- ground bounce due to small, long, and poorly secured ground links E50 to testbeds
- erratic print cycle causing pin bounce and reed switch bounce
- still maladjusted in some key area
- pin block is bad, causing all the problems
- other defect in E50 not yet spotted
Tuesday evening - Improved cabling to the Arduino and FPGA boards, plus set up a much beefier ground connection to eliminate the possibility of ground bounce. Still no definitive answer and also no clean operation. The Rotate 3 solenoid seems to be involved in most wrong characters - it should be on for the intended character but the one that displays is the same pattern of solenoids but without R3.
However, shift is not reliable, and that involves only solenoid R2, which is otherwise always firing when it is needed. I did recheck the vertical clearance of the pin block and found the right side (rotate side) to be a bigger gap than I had set - this will cause failure to relatch and substitutions. Thus, I need to carefully adjust the pin block height tomorrow and verify it stays true. I will use feeler gauges to ensure a very accurate height.
Watching the solenoids I see that they are all firing, but sometimes R1 is only returning partway back to the restored position. This could be causing interference in the pin block and misselection. Some of the characters that are coming out wrong are printing with zero rotation instead of some desired level. This could be failure of the pin to seat in a groove (from the excess height).
Will keep at it until i am more certain of the true cause. Using a tablet, I shot a video of the bottom of the carrier as it typed the test sequence, then slowed it down to a few frames per second to watch the action more closely. It was clear that the R1 wasn't returning to the full idle position quite a few times, which may be causing the problems. Once again, i will take the pin block apart and try to get it working reliably. If this try doesn't work and it is still sticking partway, then the replacement pin block will get ordered.
I wired up the prototype board for the keybaord interface and will conduct the test tomorrow, Saturday, once I return from my visit to a real 1130 where I will take all the detailed measurements I need for my physical enclosures and final versions of the light panel, etc.
 |
| Prototype testing of keyboard interface design |
 |
| Keyboard testing setup, some keycaps removed for painting |
No comments:
Post a Comment