Tuesday, December 23, 2014

Keypunch interface problem fixed, more progress with SAC interface testing

1053 CONSOLE PRINTER RESTORATION

Another hour down - no sign of the spring. Moved on to other tasks where I could make progress.

NEW KEYPUNCH INTERFACE DEVELOPMENT

I installed the interface and began testing. I had some odd behavior, which I traced to the relays whose contacts are still oxidized thus their connections are unreliable. I took each one out, hooked up the VOM to each contact and used my burnishing tool to clean off the oxide. It was fairly tedious with four sets of contacts on average per relay and quite a few relays, but I knew the keypunch would be more reliable once this was done.

When I was last working on the keypunch some weeks ago, I had a card jam and something is still wedged in the punch station so that the card won't advance. It could be a problem with the darned oxidation on the contacts for the escapement mechanism, but one way or the other I can get this fixed.

In spite of the problem, the keypunch itself and my interface believe it is actually moving and punching the card. That means I can still test to see if the interface resets before it completes punching 80 columns, the main problem I had before.

Success! I can rattle off a full card worth of punches and/or spaces with no problems. Further, I tried a read operation and it worked too. The data punched on the card I put into the read station were picked up perfectly.

No need to put in the zener diodes, so the modifications are done. I have some diagnostic print commands telling me the amount of free memory, which I will pull out.

This box will be ready for final testing once I clear up the mechanical issue blocking my keypunch from moving cards through the punch station. This failure occurs with or without the interface, when I punch on the keyboard or when I send data through the box, thus this is unlikely to be an issue with my device.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

After some cleanup, the box no longer generated any spurious signals to the 1131. I could put the 1130 in any mode including run and see it pop into the interrupt level when I flipped the switch on my box.

What is not working properly is the Adept mechanism that reads and writes to fpga 'registers' through the USB link. The Adept program is probably not working right, rather than my logic, because it lists the board with its proper descriptor but states 'unknown product'. I believe that the utility won't try to access the remote side unless it recognizes the board is capable of that function.

I will have to set up some Python code that uses the SDK to access the board function, displaying the values of the signals coming from the 1131. I need to see all of that in order to validate that I have the signals properly assigned and they all work properly.

I think I know why the Adept utility doesn't recognize my card - I have the breakout board added, with its own devices on the JTAG chain, thus not the same as a standalone FMC S6 card. While I can work on my SDK based Python code, I decided it might be faster to just add some LEDs to the box.

I have several connectors available on the breakout board I am not currently using, plus the board itself has four 'user' LEDs I can drive. Using two jumpers I am wiring in a quicky board with 16 LEDs. Using one of the slide switches on the main board, I can display 32 signals, 16 at a time, on the new board plus the four on the breakout card giving me access to all 36 inbound signals.

Quick LED board to display 16 signals at a time
I soldered up the quicky board with its LEDs and put the connector pins on the ends of the wires. However, I don't have the 6x2 sockets to insert the pins into - a trip to Frys is in the cards so I can finish this. I also have to define the 20 new signals for my LEDs in the UCF and VHDL files, route the signals to the LEDS including use of the slide switch, and then I can resume debugging my interface box.
Adding logic for my spare board to debug the register read/write function over USB
At night, when I am not working on the hardware, I am using a spare fpga board, although not the same type as in my interface box, in order to debug the Adept link and my python code.

Spare board I used to develop and debug the USB register read/write functionality

No comments:

Post a Comment