Monday, October 27, 2014

TTL to SLT driver circuit working well, plus solid progress on the keypunch interface unit


I have a good new belt for the 1053, although I know that installing it means partly disassembling the operational shaft and possibly having to redo all the settings when I put it together. I will stall a few days before starting this odious task.


I studied the schematics for the 029 Keypunch and read the theory of operations manual until I figured out what is going wrong - the failure to register a card and allow punching that crops up after some time using the new interface. It is the multipunch key implementation I designed.

When the multipunch key is depressed, the keypunch will drop the alpha relay, putting the keyboard into numeric mode which does not allow space, A or Z keys to be activated (they have no numeric or shifted meaning). It also sets up the machine to pick the multipunch relay once the first key is pressed and to interlock further escapements (advancing columns).

The key on the 029 consists of two switch sections - one pole is normally disconnected but when pressed will route power to the multipunch relay. The other pole is normally connected to the circuit that holds the machine in alpha mode unless the numeric key is held down. When multipunch is pressed, it opens the line to the alpha relay, having the same effect as if the numeric key is pressed.

I only implemented the first pole, latching the multipunch relay but not switching to numeric mode. This resulted in the funny behavior, I theorized. I can take the two wires and relay currently used for the Clear switch and use them as the second pole of multipunch. Clear was not an essential function, it was a 'freebie' added because we had a spare relay.

However, the way the wiring works, we must be in series with the multipunch key second pole, All the other interventions are parallel, meaning if the cable is removed the keypunch operates normally, we just close a parallel set of contacts to the original key when we remotely operate it.

Due to the circuit layout in the 029, if we were to act in parallel to the numeric + multipunch pole 2 switches, we would block it from going to numeric mode - a failure. If we insert our relay in series so that our relay is normally closed, it will work properly and kick the machine to numeric during multipunch, but if the cable to our box is removed, the machine stays in numeric only mode - a different failure.

I can't see any clever way to implement this that is independent of the cable, unless I put a double pole relay down inside the keypunch to activate multipunch remotely; pole one in parallel with the key pole 1 and pole two in series with the numeric + multi pole 2. That would let me use one pair of cable wires to activate multipunch remotely, but it means additional changes must be made to a keypunch before it can be hooked to the interface. The upside is that we get our freebie Clear switch back because the relay and two wires are not needed - one circuit fires the remote.

The other option is a dummy plug that is put on the cable when it is not hooked to an interface box, the dummy plug bridging the circuit that is in series with the numeric + multi 2 switches. This requires less hardware but the user must remember to keep the dummy plug in place when the interface is not attached.

I chose the last method, rewired my keypunch and made a dummy plug up. This does not  preserve the two wires and relay for the Clear switch; we need it for pole 2 of multipunch. It has some rewiring necessary but that will be the normal instructions for modifying other keypunches.

Example of a dummy plug - although this is the wrong polarity. Need a male plug.
I put the modification in place, hooked up the interface, but I am still seeing the same problem - won't recognize card registration or allow punching. Letting the keypunch sit for a while and it works fine, but once I punch through the interface, the problem resurfaces. This happens with or without the read cable attached.

As far as I can see from the schematic my wires should be totally isolated from the other wiring, with relays connecting the circuits to fire various punch, space or release solenoids, and only one input which is my own magnetic reed switch with no wiring in common.

I have one small problem with single letter verb mode (i.e. allow M instead of MODE) that I will clean up, and it seems my parsing, storing and manipulating binary mode characters is flawed. However, my multipunch key functionality now works perfectly.

At this point, I suspect it is back EMF generated when the solenoids drop. This back EMF may be harming the keypunch, putting it into the problem state after some punching occurs and restoring itself with the passage of time. Fortunately, I had recently picked up a pack of 100 3A solenoids which are going to work out well for this purpose.


I varied parameters and simulated my driver circuit many different ways, but the outcome is always the same - it should work properly but the sample circuit I built didn't. At this point, I will rebuild a sample circuit and check again, in case there was a bad component or bad connection or other problem that invalidated my test.

After rebuilding the demo driver circuit and firing it up, the results were exactly as predicted by the design, totally unlike the poor results of the first try. Not sure what was wrong but I can drive the transmission line to 2.9+V for logical 1 and about 0.1V for logic 0. Since the margins for SLT logic are 1.8V high and 0.3V low, this will work well. It was designed for worst case resistance and I used a suboptimal set of twisted wires. Real world performance should be better.

I will now rebuild the receiver circuit with tested components and test it out, but my expectation is for both sides to work as intended. Somehow I let myself run out of solder, which is why I ceased operation tonight. Tomorrow, after resupplying, I will test out the demo receiver circuit.

Soon I will lay out the circuit board for the final set of drivers and receivers for my SAC interface. This board will convert all the incoming and outbound signals to TTL levels which I can readily manage with my FPGA boards.

I want to create a simple function using the interface - something to load and dump memory to a PC - which will just use (abuse) cycle stealing without the need for any XIO or interrupt routines on the 1130 side. That way I can stick diagnostics and sizeable test code into the machine in the interval where I am still fighting with the card reader. 

No comments:

Post a Comment