I have been unable to find any source for 1/8" diameter black acrylic rods, other than a custom order of 200 six foot long pieces with long lead time for delivery. I therefore will fall back to plan B - buy the available 1/4" size but sand or machine it down to 1/8" for the section that will be glued into the plexiglass panel. I believed this could be done by placing short lengths in the drill press, running it at slow speed and carefully applying sand paper backed by a flat wooden block.
I was able to use a rasp to do the job, as sandpaper clogged too quickly and was not able to remove much material. The four pegs were turned and glued into the back of the plexiglass panel. Unfortunately, the acrylic cement I used with the first peg ran onto the face of the panel and disfigured it slightly. Now that the pegs are in place, I can drill the openings and install the panel onto the enclosure.
 |
| Pegs cemented in place to rear of plexiglass panel |
The light panel is now fixed firmly in place inside the enclosure, ready for the plexiglass panel to be installed in front of it. I have some adjustments to make in the position of the light assembly as there is a bit of clear acrylic epoxied to the rear of the plexiglass, but it is starting to detach, pulling off the lettering which would ruin the panel. I have to leave it in place to avoid that fate. I have notched out the lip of the enclosure box, allowing the acrylic bit room to fit inside, but the light panel assembly is too close to the front and must be moved rearward.
After relocating the internal light panel back a bit, I tried to attach the mode switch plate on the right side, but the nut popped off the rear metal surface of the plate as I was tightening it into place. Epoxy just won't hold properly, time to give JB Weld a try. I spent so much time getting the lettering right on the panel I don't want to have to do it again if I weld or make a different plate with built in attachment hardware.
DOCUMATION CARD READER INTERFACING
I worked out the key ideas for the error handling necessary to convert errors that occur on the Documation reader into events that make sense for a 2501 card reader and cause the 1130 adapter logic to behave reasonably. An empty hopper or full stacker is reported with no delay, any motion error during feed is reported as a feed check when the adapter attempts its next 2501 feed cycle, and a read error encounted on a card is held until that card would be passing through the photocells of the 2501.
Since each card goes through two feed cycles inside a 2501, first moving into the preread station and then actually being read, the error from the documation is detected during the time when a 2501 would move that card to preread but not yet see its problems. Thus, I wait an entire feed cycle and report the read check on the subsequent feed cycle - the time when the card would be moving from preread to stacker on the 2501.
Physically, we see a card move through the Documation in a single feed cycle, from hopper to stacker, but it sits in a virtual preread station implemented as a FIFO inside my interface logic, and the second feed cycle of that card is done by extracting its data from the FIFO; its second 'move' is purely virtual.
 |
| Bus Pirate used to snoop on serial links |
 |
| Tektronix analog storage oscilloscope for diagnosing signals |
 |
| Interface boxes connected to Documation reader to start testing, one box open |
I am encountering errors when the third chip is wired into the I2C link. The bus pirate sniffer output is not completely helpful as it appears to be missing clock beats thus reporting values that are shifted over one bit position. For example, it reports a transation START x4E (ack) x18 (nak) xFD (nak) STOP but I am fairly certain this should be START x4E (ack) x0C (ack) xFF (ack) STOP.
I found the root cause, which was an error in my documentation for the outputs board type which meant that I was wiring the address of the MCP23017 chip as 0100001 not 0100100 as I had thought. It was not responding because I wasn't giving its address correctly. With the address corrected, I reran the test and it still failed. I am suspicious of the functionality of the board, since I think a miswiring early in the construction may have toasted some part of it.
I believe it is time to haul out another output PCB board and build it, since I have all the needed parts on hand. The board is almost complete as of Saturday evening, with just two resistors and some connector pins to install. I should have the board wired into the interface replacing the defunct board in time to do some testing on Sunday.
With the new board in place and wired up, I ran some testing to validate the initialization and use of the output board. I should see the POWER lamp light immediately and FEED CHECK should be on as well, assuming the adapter logic correctly sets the reader's initial state.
However, something goes wrong with the initialization or first write to the third chip, so that nothing is lit. I found a way to trigger the chip to set all latches on, lighting all the lamps and successfully activating the 'pick' signal to cause the Documation to read cards continously. At least the wiring and operation is confirmed.
In the meantime, I pulled the output chip from the serial link logic to allow me to continue debugging with the input board. The results are reasonable so far, but I want to bring some of the lines out as diagnostic signals to capture with the logic analyzer next.
DOCUMATION READER MODIFICATIONS
The 7433 integrated circuit which was due to be at my home when I returned from my business trip on Thursday had not arrived - it took Fedex 7 days to move it from New Jersey to its first appearance in California, with estimated delivery late on Friday. Once I prepare the printed circuit board, I can build the board, install it and verify its function.
The fix is simple, an open collector NOR gate will combine the row 12 light signal with the '81CR' signal that indicates we are at column '81' of the card, the output is routed to the wired-OR with the light signals of the other eleven rows to produce the 'any-light' signal. Since the error circuits check for 'any light' during '81CR', removing row 12 from the 'any-light' at this time will prevent the reader from falsely detecting a ripped card or timing error when reading cards that have a diagonal cut on the top right side; otherwise, the row 12 detector sees enough light from around the cut to cause the read check error to be raised.
It was slightly complicated because of the location of the various signals and the use of open-collector wired-OR logic. The proper logic gate to fix this problem was a NOR, but 7400 series TTL gates that are both NOR and open collector are not common. The 7433 chip is the right part, but few are used or made today. The timing board produces the '81CR' signal and it is picked up on the error board where it is used. The wired-OR of the rows to produce 'any light' happens on the control board, but that board does not have '81CR' on it. The error board sees '81CR' but sees only the 'any-light' signal, not the individual components such as row 12.
I have to interpose my NOR gate on the signal from row 12 into the wired-OR, thus this chip has to be wired into the control board where this OR is implemented. To get access to '81CR', I can take advantage of the copper finger for '81CR' that fits into the board connector. Although the finger is not connected by traces anywhere else on the control board, I can tack on a wire to the finger where it extends out of the connector, giving me the needed signal.
The trace that carries the row 12 signal to the wired-OR can be cut, with wires tacked on each side to bring the signals to my little NOR gate board. The board also needs 5V and ground which are easily tapped from locations on the control board. The card cage for the Documation has several empty slots, fortunately they are right above the surface of the control logic board and I can use the space to place my small NOR gate board.
I set up a replicated design that will create 4 to 9 copies of the board on a single copper blank, depending on whether I expose on 3x5 or 4x6 sized boards. Rather than battling to put up light blocks over the various windows on the garage, I will expose and develop the boards once it gets dark on Saturday night.
With the board printed last night, on Sunday morning I drilled the holes in the board to mount the IC and connector pins. The unheated garage was quite cold, low forties F when I began working, which results in icy fingers even with a warm jacket protecting the torso. I dug out some space heaters and turned them on, hoping to bring the workspace to a more reasonable temperature for the remainder of the day. Two on a circuit don't work well for long - I reset the tripped breaker and spread the two across separate power zones.
My prepared small circuit board was tested to verify the connections and that it functions as designed. I don't want to modify the Documation with this board until I have finished debugging the adapter and reader. Once it works properly, I can put in the modification and be sure that any problems are the result of my change and not some other unrelated defect.
CLEAN UP BLIZZARD OF XILINX WARNING MESSAGES
The current build produces more than 2700 warning messages, almost every one a benign situation such as a signal that is not used in a module. These can hide serious situations, since I have to scroll through all the noise to see if there are any important warnings. The Xilinx tools don't provide any way to suppress the warnings that are trival.
I decided to clean these up by altering the code, hoping to slash the number of warnings to a more manageable number. As one example of the cause of these warnings, my edge triggered gate module is controlled by generic parameters, allowing it to be configured with inverted or normal inputs and outputs and also to put it in 'pass thru' mode, which is purely combinatorial. Pass thru mode is something I do only if one the gating inputs is already an edge triggered signal, as otherwise each edge trigger in a chain adds another fpga cycle of 20ns to the final result. Passthru mode has no delay inherent in it, but as a result it does not use the fpga master clock signal nor certain other internal signals - triggering several warnings per pass thru gate.
I chose to split this out into a pass thru and a non pass thru gate type, then change ALL the code that refers to the formerly single module in passthru mode to make the code now call the distinct pass thru variant. This is a huge PITA, for example each of the 20 RB modules that instantiate a bit of the I, B and M registers has 14 pass thru gates, thus I have to change 3 lines times 14 gates times 20 modules or 840 changed lines.
It gave me something to do during flights and in idle moments. After a day of work, I had the warning count down to just over 1500, which is still far too many to allow easy scanning to find real issues. I will keep looking for categories of warning that can be fixed with a reasonable code change.
Unfortunately, the largest remaining pool of warnings are for signals that are not used or assigned, because the portion of the design which would do so is not implemented - as for example when the logic for the 1132 printer is not configured, the build of the 1130 system will raise quite a few warnings for the signals that are associated with that module. VHDL and the Xilinx tools allow me to conditionally generate or skip the logic for the 1132, but the declarations of the signals themselves cannot be made conditional. That is a weakness of the language itself.
I would need to leverage a source code processor to turn my generalized VHDL for the top level module (backplane.vhd) into a specific version for the configured machine, omitting all signals and logic related to omitted peripherals or functions. Many have used a C or C++ preprocessor to accomplish this, but it adds some manual steps since the ISE toolchain wasn't built to have pre- and post-processed versions and force a preprocessor step to be run.
I have installed an open source preprocessor from Sourceforge that has a windows executable - MCPP - and am in the process of configuring the backplane file for conditional implementation of the code for various IBM peripherals, my interface logic and other optional functionality. I will have to remember to place any fixes to the backplane file into the master source and run the preprocessor before using the ISE tools - this will be a huge 'opportunity' to lose fixes and regress the code.
No comments:
Post a Comment