Sunday, October 19, 2014

1053 debugging, SAC interface circuit testing and good progress on keypunch interface controller


I hoisted the console printer up for access to the contacts and began to check continuity and operation of all the contact/switch units on the typewriter frame. Amazingly, given all the oxidized contacts in the rest of the machine and peripherals, everything in the 1053 worked properly.

Checking switches and contacts in the 1053
The erratic spacing has to be mechanical, therefore. I did some spacing with the hand crank wheel rotating very slowly to see the operation at the moment of release. I saw spots where the carrier did not move forward at the release, while in most spots it jumped promptly to the right.

While it could be a bit of sludge on the escapement and backspace rack teeth at the failing spots, I am still leaning to residual sludge between the escapement, backspace and tab levers keeping them from snapping back in place as they should under their spring tension.

I know that the tab should latch the escapement and backspace pawls out of the way until the carrier runs into a tab lever in some column that is set, which releases that latch. On some tab operations, however, I see the tab lever fail to latch so that it moves only a few columns over.

Since the latch is part of the stack of levers along with escapement and backspace, it reinforces the theory that it is sludge in the levers causing all these problems. Access is difficult without disassembling many parts that must be carefully adjusted upon reassembly.

Stack of tab, backspace and escapement levers, looking at tab lever on topo

Escapement and backspace rack teeth visible toward top, bottom pins are the tab stops

Another view of the stack of levers where I suspect sludge is causing problems


I deferred debugging the problem with the user serial link, due in part to the total ambiguity surrounding PC serial port links -

  • which of dozens of permutations of control lines are used (CTS/RTS/DSR/DTR. . .)
  • voltage (TTL versus true RS232)
  • cables (all wires, partial wires, straight thru, crossover, control signal loopbacks)
  • NL, CR+NL (a terminal program variation rather than link per se
Instead of attacking the link, I temporarily changed the input routine to use the USB serial0 link associated with the Arduino code upload. With that in place I could do quite a bit of testing of my logic. In some cases, I added temporary 'Serial.print' instrumentation.

 I have worked through quite a bit of the functionality successfully, other than the question of whether it does what I expect to the keypunch. Identified issues to debug are:
  • Punch command with more than 80 columns of data is not detected and truncated
  • Verify mode doesn't properly handle shorter card for punching than prior card being checked
  • Serial1 link is not working, no output displayed by my terminal program

There is still more to check, such as:

  • translation under binary and user table mode
  • proper loading of the user table, 
  • parsing of binary mode punch commands
  • verify operation correctness
  • keypunch function timing 
I put together a pigtail power connector to hook to the Arduino from the main 12V power brick, since it is powered by the USB cable at the present, but no USB cable will be in place when the interface is in normal operation.

One part of the spec is not implemented - XON/XOFF flow control - but that shouldn't be hard to add in as testing wraps up. No point worrying about it until I get the user serial link working.

Later in the evening, I worked on the code and resolved all the known errors except for the serial link which I am avoiding for now. I also tested the binary translation mode, entering punch data in binary, and related functions. Ignoring the serial link issue, the rest of the testing should be done hooked to the keypunch.


Initial issue when I began testing my SAC interface sample circuits, but it turns out I mis-selected all of the transistors. All I had on hand were some IBM 077 and a random NPN small signal transistor, not the parts I had simulated. The failing circuit was the driver which takes a TTL input and drives an SLT transmission line as output.

I will do some simulation with varying part characteristics later tonight, even though I plan to replace the current transistors with the part number I will use for full scale production. If I find tweaks that make it less sensitive to component specs, I will apply them. 

No comments:

Post a Comment