Testing of the 1627 plotter adapter implemented in the SAC Interface Box
I set up a larger rectangle in memory and prepared some video clips of it being loaded, run and the plotter doing the drawing. At the outset, I discovered that my timing parameters for the adapter are still not good enough. While I seem to trigger reliable movement for pen movement, it was not long enough to move the pen up or down onto and off the paper. Further, I may not be giving enough time for the mechanical and electronics to complete before permitting the 1130 program to issue a subsequent command.
I made more changes but I am still not happy with inconsistent behavior from my plotter replica. It doesn't move the same amount when rerunning the same program sequence. Further, it can stall in some condition where my manual buttons don't move the drum or shift the pen off/on the paper. The solution to that is to power cycle the electronics of the plotter, which tells me they are getting wedged in some bad state.
Video of the replica plotter driven through interface box
The only solution is to make a new hardware adapter unit, replacing the box I currently have between the Strobe plotter and the fpga. This will be a small design exercise, but not a priority, because I am pretty comfortable that my SAC Interface Box is working fine. I also could attach the mbed based board designed by Richard Stofer, since this takes the six movement commands produced by my interface and will convert them into valid HPGL, sending that to an ethernet connected printer.
Building the high speed SPI link capability to a remote fpga
The remote fpga will serve as a pin extender giving me another 60 to 120 input/output signals for peripheral attachment. I will initially clock the link at 1Mhz to debug it, then shift up to its max speed of 48Mhz later in steps while validating continued reliable operation.
I designed the SPI link as a simple data pump, sending all the outgoing signals to the remove side while simultaneously receiving incoming signals from the same board. It will start with a single remote board, but I will be able to extend it to multiple remote boards fairly easily, by simply cycling through the boards sending and receiving the frames associated with each.
The frames sent between fpga boards are 128 bits long and make use of a code that can correct any single bit errors and detect any double bit one. It is a Hamming Code, carrying 120 data bits with seven parity bits for the Hamming Code plus one additional parity bit. This converts it to a Single Error Correction, Double Error Detection (SECDEC) mechanism that can be used to reliably correct single bit errors unless we suffer triple or more bit failures in one frame.
I coded up the SECDEC encoding and decoding functions, although my first cut does not attempt any error correction, it simply flags that one or more of the parity bits were in error. I then began on the SPI link and data pump logic. Once done, I need to create the complement for my Digilent Nexys2 board which will be my first remote endpoint. That unit will start out mirroring signals on LEDs and seven segment displays while sending in the state of various slide and pushbutton switches.
Building the virtual 2501 card reader
Interspersed with coding of the VHDL for the fpga functions above, I decided to work on the Python program on the PC to implement a 2501 card reader for the 1130. It will serve cards from files on the PC, using the file formats created by Brian Knittel for his 1130 simulator.
Building the high speed SPI link capability to a remote fpga
The remote fpga will serve as a pin extender giving me another 60 to 120 input/output signals for peripheral attachment. I will initially clock the link at 1Mhz to debug it, then shift up to its max speed of 48Mhz later in steps while validating continued reliable operation.
I designed the SPI link as a simple data pump, sending all the outgoing signals to the remove side while simultaneously receiving incoming signals from the same board. It will start with a single remote board, but I will be able to extend it to multiple remote boards fairly easily, by simply cycling through the boards sending and receiving the frames associated with each.
The frames sent between fpga boards are 128 bits long and make use of a code that can correct any single bit errors and detect any double bit one. It is a Hamming Code, carrying 120 data bits with seven parity bits for the Hamming Code plus one additional parity bit. This converts it to a Single Error Correction, Double Error Detection (SECDEC) mechanism that can be used to reliably correct single bit errors unless we suffer triple or more bit failures in one frame.
I coded up the SECDEC encoding and decoding functions, although my first cut does not attempt any error correction, it simply flags that one or more of the parity bits were in error. I then began on the SPI link and data pump logic. Once done, I need to create the complement for my Digilent Nexys2 board which will be my first remote endpoint. That unit will start out mirroring signals on LEDs and seven segment displays while sending in the state of various slide and pushbutton switches.
Building the virtual 2501 card reader
Interspersed with coding of the VHDL for the fpga functions above, I decided to work on the Python program on the PC to implement a 2501 card reader for the 1130. It will serve cards from files on the PC, using the file formats created by Brian Knittel for his 1130 simulator.
No comments:
Post a Comment