I continued the hunt for the errant spring, meanwhile re-installed the tab gang clear and tab overthrow stop plates which I had removed for better access to the escapement and tab mechanisms while I was fixing the tab issues.
The gang clear plate went on smoothly, but while I was maneuvering the tab stop plate into position, it slipped from my fingers and fell inside to disappear totally from view. With the relative large size of the plate and the openness of this area of the typewriter, I expected it to be easy to see and retrieve it.
However, it vanished as if it had fallen through a wormhole to some alternate dimension. I spent twenty minutes looking carefully and turning the machine, to no avail, before I decided I had to remove the motor. With the motor out, the entire area where the plate fell was accessible with no place to hide. Retrieving the plate, I put it into position on top of the carrier.
It was an opportunity to clean out accumulated oil and grease in the area, before re-installing the motor. It was fairly easy to put this back in place and get it adjusted for good smooth operation.
I then adjusted both of the plates to meet their specs. The gang clear plate has to be within a range of distances from the clear post of the current column on the tab rack. Too far and it won't clear the posts, too close and it will interfere with carrier movement. The tab stop plate must allow the tab mechanism to latch up reliably, but not move so far forward that it can interfere with the tab rack itself.
The adjustments done and the motor back in place, I can return to the carrier return and missing spring issues which are all that remain to address. I put in another thirty minutes of searching and FINALLY spotted the missing spring. It sat in a spot parallel to several other springs which are attached and functional, so challenging to notice it wasn't supposed to be there. All my prodding in the past didn't uncover that fact, as it was wedged in a way that made it seem attached.
Hurray, I thought, as I got my tools on it and lifted it most of the way out of the typewriter. That is when it happened - the spring popped loose and disappeared again into the bowels of the operational clutch area. Again. After five minutes of looking with no clear sign of the spring, I put this aside until the utter frustration dissipates. I wouldn't want to do any damage while under the sway of emotion.
I came back to the typewriter as daylight faded, since this is inside the garage and equally easily searched day or night. I devoted another fifteen minutes of hunting and peering, which of course included the spot that this spring had hidden last time around. No luck, but I will keep at it as much as I can stand each time and return to the Sisyphean hunt each time after the frustration has abated.
NEW KEYPUNCH INTERFACE DEVELOPMENT
I pulled the interface box out of the keypunch and will insert some additional protective devices just in case we have induced voltages on the wiring that are forcing the Arduino to reset. I will put zener diodes on the inputs even though they should only be switching 5V power we emitted, and improve the arc suppression design for the outputs.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I got right to the repair attempt this morning, setting up the board, clamp, heat gun, replacement connector and other items on a table outside. After a few minutes prep-ing the board with flux paste and fresh solder on the pads, it appeared I might be able to solder this down with just my fine tip soldering iron and ordinary solder.
I gave it a shot and was fully successful! I hooked up to a PC, downloaded by test logic to the board and am ready to start testing of the interface box. Very pleased. The cause of all the problems is a malformed cable, the one sent to me along with the fpga board - it won't fit into any microUSB sockets but another cable I had in my supplies slid in easily to both the original and replacement sockets on the board.
The fpga board was put back inside the box on its mounts, the breakout board fitted onto the high density connector and screwed down, then the power and signal connectors were all put into place. A USB cable was the last connection, in order to test the board and update its hardware configuration.
Time for a bench test of each signal pair from the SAC cable connector, ensuring there are no shorts and that the resistance of each pair is an appropriate value for either a receiver or driver circuit. Once it had passed I could connect cables between this box and the 1130 and safely power up.
My initial test program is set up to inject appropriate (off or idle value) signal levels into the 1131, see that the existence of the box doesn't stop the 1130 from operating normally. In addition, it has a mode that will force an interrupt to be taken (on level 4) and show receipt of certain processor state.
I powered the box up in order to load the configuration file, but the loading software reported no valid devices found. It definitely sees the USB link and device, reporting the correct board type, but otherwise can't see the fpga for bit programming nor the flash devices to store configurations.
It worked fine with just the fpga board, but with the XM105 breakout board installed it is failing. That is the clue - something is wrong with the JTAG chain that is used to detect and program devices. I remember reading somewhere that if the chain is open, the signal won't wrap back to the sender which may be what is happening, if the fpga board opens the chain when the HPC connector is installed.
Without having logic set up by my program, the outputs are not driven to zero, instead defaulting to their 'on' condition. Thus, the 1130 reported interrupt requests on all four levels, but didn't show any signs of distress otherwise. Once I fix the program with the JTAG chain and can configure the logic of the interface, I should be able to test steadily.
I found that my fpga board checks a signal called FMC-Present which is one when the breakout board is installed. When on, it breaks the connection of the JTAG chain, allowing the user to insert additional devices on the breakout board. All I need to do is connect the JTAG signals TDI to TDO on the breakout board and this should work fine. Made up a jumper and installed it. Worked fine now.
I am able to receive and properly interpret all the signals arriving from the 1131 to the box, but my signals requesting interrupts are being ignored. I may have jumpered something in the 1130 to block these in my earlier restoration and debugging, or I may have a problem with the circuits that drive input to the 1131 from my box. I am going to monitor the voltages on one of the signals to see what is actually occurring on the cable.
The output voltage stayed high, although it should have been pulled down to near ground when I activated the request. I had an LED indicating the state of the signal I believed I was sending to that circuit and it faithfully matched what I set with the fpga board switch. I moved the voltmeter to the input of the circuit which should be driven by my fpga, yet I saw no change in voltage as the request changed between on and off.
Any number of problems could be causing this:
Time for a bench test of each signal pair from the SAC cable connector, ensuring there are no shorts and that the resistance of each pair is an appropriate value for either a receiver or driver circuit. Once it had passed I could connect cables between this box and the 1130 and safely power up.
My initial test program is set up to inject appropriate (off or idle value) signal levels into the 1131, see that the existence of the box doesn't stop the 1130 from operating normally. In addition, it has a mode that will force an interrupt to be taken (on level 4) and show receipt of certain processor state.
I powered the box up in order to load the configuration file, but the loading software reported no valid devices found. It definitely sees the USB link and device, reporting the correct board type, but otherwise can't see the fpga for bit programming nor the flash devices to store configurations.
It worked fine with just the fpga board, but with the XM105 breakout board installed it is failing. That is the clue - something is wrong with the JTAG chain that is used to detect and program devices. I remember reading somewhere that if the chain is open, the signal won't wrap back to the sender which may be what is happening, if the fpga board opens the chain when the HPC connector is installed.
Without having logic set up by my program, the outputs are not driven to zero, instead defaulting to their 'on' condition. Thus, the 1130 reported interrupt requests on all four levels, but didn't show any signs of distress otherwise. Once I fix the program with the JTAG chain and can configure the logic of the interface, I should be able to test steadily.
I found that my fpga board checks a signal called FMC-Present which is one when the breakout board is installed. When on, it breaks the connection of the JTAG chain, allowing the user to insert additional devices on the breakout board. All I need to do is connect the JTAG signals TDI to TDO on the breakout board and this should work fine. Made up a jumper and installed it. Worked fine now.
I am able to receive and properly interpret all the signals arriving from the 1131 to the box, but my signals requesting interrupts are being ignored. I may have jumpered something in the 1130 to block these in my earlier restoration and debugging, or I may have a problem with the circuits that drive input to the 1131 from my box. I am going to monitor the voltages on one of the signals to see what is actually occurring on the cable.
The output voltage stayed high, although it should have been pulled down to near ground when I activated the request. I had an LED indicating the state of the signal I believed I was sending to that circuit and it faithfully matched what I set with the fpga board switch. I moved the voltmeter to the input of the circuit which should be driven by my fpga, yet I saw no change in voltage as the request changed between on and off.
Any number of problems could be causing this:
- mis-wired connector or confusion over which connector pin is emitting this signal
- problem with configuration of fpga resulting in invalid voltages driven into circuit
- my wiring of the SAC interface connector did not connect IntReq Lvl4 to this circuit
- unknown flaw in the circuit
No comments:
Post a Comment