The modifications were done to the reader to eliminate the remote reset switch control for now, redo the remote stop control, and the new connection picking up the stacker full switch state. Before I close it up, I need to work on the busy problem below.
I verified that the pin on the connector has continuity all the way to the input mux chip, which pointed at the reader itself as the cause of the busy signal never going true. To test this, I removed my interface, hooked directly to the busy and ground pins of the plug on the reader boxy, then ran some cards through in local mode.
No sign of a busy signal, it stayed at 5V (this is actually an inverted signal not busy) the entire time. It should have dipped to zero for the duration of the 80 columns of each card. I will need to debug the card reader itself. I moved things, reseated boards, and now see the signal dipping on each card. Time to hook up the interface and use the analyzer on the transmitted results.
Well, I do get a busy signal for each card. BUT . . . it is not at the right time and highly erratic. The busy should go high as soon as the card first blocks light to the photocells, at the leading edge, and be dropped at the end (at the equivalent of column 84 of the card, based on the column counter). Instead, I see it go high after 10, 30, even 74 columns have already been read.
I need to stick my logic analyzer onto the control card of the reader to determine where the problem lies. The trigger for busy to go high is the same signal that successfully starts the column count; my ability to get all the data from each card is proof that the GPR signal is occurring on time as seen by at least some of the cards in the machine.
The GPR signal goes through an inverter, then drives a flip flop preset to turn on busy. The FF is turned off by the CR84 column count - this part seems reliable. The output goes through a NAND and an inverting buffer. As long as the GPR signal does not have a problem getting to the control card across the backplane, the problem should be found in an inverter, a flip flop, a NAND gate or an inverting buffer. Once I have a likely suspect, I can put the analyzer on the input and output side to confirm.
Another possibility is a erratic connection in my interface box - the logic analyzer work should point there if the busy timing is correct at the output pin of the inverting buffer. I can then check the link in the reader up to the connector. If in my side and it is intermittent, I should be able to inject a clocked signal and watch it from the other side while I vibrate things.
The busy signal may not sound essential, as I would know when I had issued pick but had not yet received the columns, but my logic uses the signal going low to indicate that we have finished reading columns from this card. If I didn't have a reliable busy signal, I would have to count columns, wait a bit to ensure no new index marker arrived, and then finish up the read cycle. Error checking is enhanced with the busy signal telling me that I should have received exactly eighty columns of data.
Drat - the logic analyzer on the Documation control card showed that busy was coming up exactly as it should. I probed the connector pin and still see busy occurring on spec. That means the flaw is inside my interface box. Every time I open this and disturb things, I run the risk of something else breaking - the dreaded phenomenon I have faced in several aspects of the 1130 project.
However, I now have only two choices - open the box and hope nothing goes south while I am repairing the latest induced failure, the busy signal which I believe worked properly before I fixed the ready signal problem, or leave it alone and code around the lack of the busy control signal. I will seriously think about the option to leave it untouched.
I believe I have a good way to proceed in spite of the lack of the busy signal and have recoded the logic appropriately. I will waive the requirement for the busy signal. Now that the control signals are working correctly, I can sign off on this layer of the stack and move up another one, to debug the adapter logic that is driving the reading, storing and presenting of data to the 1130.
There are two sides to this adapter, the side that controls the Documation and the side that emulates a 2501 card reader to the IBM 1130 adapter logic designed into the 1130. I may be debugging my implementation correctness of that IBM logic as well, depending upon the nature of any faults I discover.
Beginning the first test at this level of the stack, I brought up the machine and observed the correct status on the 2501 panel - only the power and feed check lamps lit. I pushed the NPRO button which cleared the virtual 2501 reader and turned off the feed check error. As soon as I put in a card and readied the Documation, it read the card then lit feed check once again.
The read of a card into the preread station should have required me to push the start button which triggers the run-in sequence, yet it read immediately. As I thought about this, I realized that the NPRO cycle had triggered the physical reader FSM which was now just waiting for the machinery to come ready.
I suspect the feed check was caused by error checking that expected certain physical things to happen in the execution of NPRO, such as cards clearing the photocells, which I wasn't emulating properly. It also could be a consequence of the read occurring prior to the instigation of a 2501 run-in operation, so I will handle these issues one at a time.
In thinking about how to handle NPRO such that this doesn't happen again, I realized that I should block any feed requests from the 1130 adapter logic if the virtual 2501 hopper is empty, as these are either an NPRO action or reading the last card to set EOF which will be fed exclusively from the FIFO. I put in the check in the FSM handling the Documation reader and reran my test.
The emulated 2501 is not doing the NPRO when it is commanded; it is not starting up and emitting the feed CB signals to complete the NPRO execution. Fortunately, I found the cause quickly by scanning my code. My method of ensuring the virtual 2501 reader doesn't run faster than the real Documation and end up with no data in the FIFO is to hold the virtual emitter wheel until the Documation has read a card into the FIFO.
This causes the main 2501 wheel and the feed CB pulses to be stifled just when I need them to operate. The 1130 adapter logic which commanded the NPRO expects to see feed CB1 and feed CB2 before it ends the NPRO process. I can modify the block of the wheel but I must go back to the reason I attempted it, to see how I ensure the 2501 doesn't get ahead of the documation. My solution is to block only when we have energized the feed magnets (ask to move a card in the 2501), have a card ready in the physical reader and have no card saved in the FIFO that the 2501 can draw upon. It will unblock once the documation reader finishes a read cycle.
The CB emitters began operating as soon as the NPRO button was pressed and the feed check was cleared. When I pressed the start button, the adapter lit the ready lamp, just as it should once a card is fed into the preread station by the documation reader. Unfortunately, we did not read a card nor put anything into the FIFO. Still not quite right.
It seems my FSM logic would lose a request for a feed if it occurred before the physical reader was ready, when it was intended that it hold in a particular state pending the ready signal going high. A coding slip caused this, now corrected.
Another problem was in the card lever signal that indicates whether the preread station has a card in it or not. The 1130 adapter logic expects this lever to go on and off as cards move through the machine, and they must occur at specific points in the wheel rotation of the 2501 mechanism. Thus, my logic for flipping this signal on and off is a bit complex. It was going on during the NPRO cycle, when of course no card is actually entering the preread station. I fixed this as well by waiting until the FIFO has a card loaded.
Now when I push the start key, I get two cards read rapidly in succession, which suggests I am keeping the pick signal active too long. In addition, I get a feed check condition from the 1130 adapter logic. The latter is a clue that I might not be emulating the timing well enough to pass the checks built into the adapter logic by IBM. I will deal with the double pick first, as this is the more obvious malfunction.
I will run a number of tests with various signals brought to the logic analyzers, while studying the 2501 reader documentation and the logic diagrams of the IBM designed adapter in the 1130. I should be able to determine what is not occurring as it ought, make appropriate changes to my logic, and iterate until I am able to get the whole system to preload a card and sit properly at the ready condition.
I am definitely not modeling the signals in the preread station correctly.The emulated 2501 has to match in every detail to which the logic of the 1130 is sensitive, in particular to its own timing generation which cyclically sends the three feed CB signals to the 1130 adapter logic. Much of the IBM designed adapter logic is making decisions at various CB times, thus my modeled behavior must be set up properly when those CB signals occur.
I worked out a different state machine to drive the preread station indicator CardLever1 as well as cause one of the data photocells to be 'dark' at the times when the adapters looks for 'any cell dark' to start timing card columns.
It appears I now had my state machine producing correct outputs at the times a 2501 reader would emit them, but still illuminating the feed check lamp after the NPRO operation. I moved well beyond this through more work, described further down, but the issues I had to correct fell into just a few categories of errors.
To illustrate the types of defects that came up during the debugging, I will describe a few as I discover them. Some are inadequacies in my emulation of a 2501 reader operation, some are errors I made in implementing the IBM designed logic in the 1130 that was the controller for the 2501, and some are defects in my logic in the inteface/adapter I built.
I found one cause for the feed check lamp after an NPRO operation, which was an error in my implementation of the IBM designed adapter logic in the 1130. Specifically, there was a single-shot of 500 us triggered as a card is heading into the read station, when the trailing edge has cleared the photocell in the pre-read station and the leading edge has just blocked the light on the photocells that read the 12 row values. IBM used that 500 us pulse to start timing columns which of course won't be happening if we are actually clearing a card from the machine in an NPRO.
I had the polarity of the output of that single shot reversed, so that it appeared to be continually emitting the pulse that erases the 2501 emitter drum, even though the single shot really hadn't been triggered. Most single shots in the 1130 produce inverted pulses but the logic diagram (ALD) shows the gate with a non-inverted output. It cannot be correct as the rest of the gates driven by that single shot don't work as described unless it is a normal inverted pulse.
Some of these errors were discovered through detailed examination of the signals being emitted, using the logic analyzer. This takes a bit of time to swap which 10 signals I am able to monitor with the analyzer. Others are discovered by painfully slow and careful study of the ALDs, other documentation, timing diagrams, and my code. Combine two tedious activities together and you get hours and hours consumed slogging through towards eventually correct operation of the reader system.
To show the flaws in my emulation of the 2501, I will describe where the fidelity of my behavior was not sufficient to meet the assumptions upon which IBM designed its controller logic in the 1130. The timing with which photocell detectors change as cards move and the way that other signals change relative to each other and the 1130 output signals effect many error checking circuits and functions in the IBM adapter.
The timing of the pre-read photocell must be very precise to fit in with the various CB pulses and the states that change in the IBM adapter logic at those times. Shortly after FeedCB1 is the point at which a card exiting the station clears the photocell, allowing light to reach it, and at roughly 211 degrees of rotation, a bit before feedCB2, is when the incoming card from the hopper will begin to block the light.
One might assume, as I did, that the functions that record emitter pulses, and play them back to denote the card column positions, are not needed when flushing a card out of the machine with an NPRO, but that would be a mistake. The error checking circuitry that validates the receipt of at least one emitter pulse is doing so regardless of the purpose of the card passing by. Whether it will be read or ignored, the IBM adapter logic wants to verify that pulses were written on the rotating drum and are playing back.
There is an intricate ballet of photocells being obscured and cleared, of pulses arriving, and of the feed CB pulses, along with some specific timing set by single shot pulse emitters in the 1130 adapter logic. I have to keep tweaking the emulation until it meets the expectations embodied in all the IBM adapter logic gates. Once it passes muster by satisfying all the IBM logic and gives appropriate behavior of the system, I can stop honing this area.
There was a class of errors that involved weaknesses or errors in the parts of my logic that drive the Documation reader, transfer and queue data and coordinate the states of the two (emulated virtual 2501 and real Documation). These generally didn't manifest themselves until the first two classes of problems were mostly resolved. As an illustration of these types of errors, I had a defect in the timing of when I presented the data value for each column of the card, causing a read error.
My clocked process to set up the state of the 12 photocells delivering the presence or absence of a hole in that row of the card was setting the value when the main reader cycle was in the state where it was waiting for, within or at the end of an emitter pulse. However, since the main reader cycle state is also clocked synchronously, we were one cycle behind in setting up the photocells. The logic that does error checking saves the values when the emitter goes high, then compares as it goes low.
The 2501 card reader powers up with a feed check lamp lit, requiring that the operator have the hopper empty and push NPRO to reset the machine and clear out any cards left in the path. I worked though problems until I could perform the NPRO process, clear everything, without triggering feed check or read check errors. At this point, the operator puts cards in the hopper and pushes the start key. The machine will feed that card into the pre read station and illuminate the ready lamp if all goes well.
This step of readying the machine with its first card is called the run-in process. My adapter has to read a card from the Documation reader and put its 80 columns of data into a FIFO queue, representing the pre-read station. My problems now included double-feeding on the Documation, as well as feed checks, read checks and other issues thrown up by the IBM adapter logic.
I am not satisfied with the coordination logic I used to drive the physical reading of cards into the FIFO and the emptying of cards from the FIFO by the emulated virtual 2501. Too, the way I keep track of the size of the FIFO assumes that both real and virtual readers are at an idle point when I make decisions, but one is emptying, the other is filling, and the count in the FIFO is the net of all these activities.
Long work verifying every gate and connection, lots of diagnostic information collecting and deep study of the IBM adapter logic to glean all purpose of each gate and the timing of its operation, have paid off in giving me a machine that now handles NPRO and run-in of a first card correctly, without spurious feed or read checks.
The coordination to drive the Documation reader in synchronization is still off. I believe I will be reevaluating the mechanism to find a more robust alternative, but will also be debugging from the current state while I work on design changes.
I expect that the effort won't be that high to reach two more milestones with this work. I should be able to get the Documation to read and load a card in preparation for the emulated 2501 to 'read' its columns, and I should be able to get a single XIO command to work reading one card into memory.
Beyond that point, the challenge comes in coordinating two independent machines coupled by a FIFO buffer, both of which have periods of time when they cannot be interrupted or slowed; certainly the real card reader has a card moving through the read station at a predetermined speed, and likely the timing checks built into the IBM adapter logic won't allow the virtual 2501 to pause in between columns.
Finally, once everything works normally, I have to test the handling of error conditions such as misfeeds, reading errors, empty hoppers and filled stackers on the Documation, so that it is done in a way that is intelligible to the IBM adapter. Just as importantly, it should report the same way (lamps on the 2501 panel) and the error recovery steps by the user should be consistent. Given the project goals of as much faithfulness to the experience a user had working on a real 1130, down to identical timing, behaviors, appearance and sounds.
After careful examination of all the IBM adapter logic, I determined that the wheel of the emulated 2501 could be frozen at a point between the end of feed CB3 and the start of feed CB1, after the adapter checks that the erased emitter drum is not sending out emitter pulses. This check is triggered for 5 ms after feed CB3, thus my freeze point must be after this completes. I can freeze the wheel if the 2501 is starting an action that needs the FIFO loaded but the Documation reader has not yet completed a successful read.
Any time the 2501 starts a feed cycle with cards left in the Documation hopper, it means that a card must be replaced in the preread station - it must be read into the FIFO in this case. The Documation state machine flips this state off when it finishes loading the FIFO. The FIFO is tracked as well, going empty when the 2501 finishes a read and marked full after the Documation reader finishes loading the card values.
I also developed the logic to handle the error conditions that can occur with the physical Documation reader. If the hopper runs out of cards, that signal is seen by the virtual 2501 and the adapter handles it correctly. If the stacker becomes full, this causes an attention condition which correctly takes the virtual 2501 out of ready. Two errors do have an impact on the machine that requires special handling in my adapter in order to make the IBM adapter logic and virtual 2501 behave properly - a feed or read error.
If the reader gets a feed check, this is the same as a 2501 failing to feed, meaning that any read occurring on the FIFO data as well as the loading of the preread station were not successful. On an actual 2501, the operator looks to see if the card from the preread station made it through to the stacker - if so, they NPRO and push start to try again to read the card from the hopper into the preread station. If it did not, then the card that stuck in the reader are put at the front of the stack in the hopper, after NPRO, and start is pushed.
My logic waits until the virtual 2501 has successfully read all card columns, but at feed CB2 time we set some cells dark, which implies that the card stuck on its way out to the stacker but was read correctly. The IBM adapter logic flags this, turns on the feed check lamp, and the user recovers by simply trying again to feed the card (after an NPRO of course).
If the real reader gets a read check, it is the error that the 2501 would have seen only when the card moved from the preread station through to the stacker. We experienced this one card early, when the card would be moving to the preread station in the 2501 - remember that the 2501 does not look at the card contents when the card takes its first feed cycle into the machine, only when it is on its second feed cycle to move it out of the preread station. The CPU is notified that the read failed in an error, the operator recovers by NPRO, correcting the bad card, then putting the bad card and the one from the preread station into the hopper in front of the rest of the deck, then pushing the start button.
My logic remembers the read check but does nothing to the virtual 2501 in its read cycle, since that read cycle is looking at the preread station card (FIFO) not the one with the error. On the subsequent feed cycle, I wait until column 80 is being read by the virtual 2501 and then flip a few bits in the midst of the reading. The IBM adapter saves the row data when the read emitter first fires, then compares it to what is on the photocells when the read emitter falls. My intervention will cause that compare to fail, triggering a read check condition. The operator recovery is the same - NPRO, fix the bad card and put it at the front of the hopper and push the start button.
A new phase of debugging requires a new set of instrumented signals plus think time to consider where problems might be caused or what signals would point me at the failures. Once those were configured, I rather quickly found and corrected two defects - one a coding slip where I wrote a conditional test as din_hock <= '1' rather than the intended din_hock = '1', which not only made the condition true but also set the signal on rather than interrogated it. This is one of those mistakes one can make unconsciously because VHDL uses <= for assignment and = for logical comparisons.
The system now is tested as far as I can go with NPRO, stop, making it ready with the run-in process ot load the preread area, and looking only at the state of signals and FSM states. It is time to build and use a small program that will read a card into the 1130, where I can verify that it arrived properly. I can then cause that program to loop to test out various synchronization and error recovery scenarios.
As I expected the synchronization of the independent physical reader and virtual reader activities is where my attention must focus. The XIO command from the 1130 successfully fires off my adapter but it hangs up before the physical reader can read the second card. I am suspicious of the timing of my FIFO push and pull activities, as the documation side logic believes it didn't finish reading the initial card.
My synchronization approach won't trigger the freeze of the 2501 wheel unless the 2501 is trying to feed the next card (do a read) but the FIFO is not available. I see that I hadn't marked the FIFO as available, plus I have the reader waiting for an index pulse in spite of the fact that the first card is long gone.
It occurred to me that I can clean out the FIFO by gating a signal during NPRO to the FIFO reset port, rather than counting and removing entries as I had been. I did some other cleanup of the code as well. Now I am able to read an 80 column card and mark the FIFO filled. The XIO from the program is accepted and kicks off a feed and read cycle (2501 virtually read card in preread station as well as Documation physically read the next card into FIFO that becomes the new contents of preread. I do, however, see the read check lamp lit on the first column of data.
New instrumentation in place to cover the key signals narrowing down the cause, I ran another set of tests.
I realized a couple of things. First, I am clocking the data out when the emitter occurs, which is too late to give the setup time needed. By shifting this back a bit I can avoid the unintended read checks. Second, my emitter pulses were too close together, producing more than 110 in the interval that should have just about 80 occur. Third, it appears I am not clocking out the first data word correctly, or I am storing a blank into the FIFO as the first word on the read by the Documation.
I adjusted the emulation counts to give me 12 tick pulses in a 157 tick cycle and modified the timing of when I present the data words on the photocell signals, addressing the first two problems noted. The third will take a bit more investigation. Testing seemed like it would be straightforward, yet everything fell apart.
The machine wouldn't even successfully complete an NPRO, usually but not always turning off the feedcheck, rarely in a condition after that to push start and read the first card into the 2501 preread. Nothing I touched should have impacts this widely on the machine; I spent about five hours tracing around looking at signals and sequences all over, a very frustrating time because I seemed to have been plunged backwards quite a bit.
Finally, I came across a symptom and spotted the problem - in the main backplane module there were signals that go into the IBM adapter logic that I set up, yet the power on reset signal was missing! I suspect that during one of the frequent malfunctions where the MS Surface Pro and its keyboard cover got out of sync and began typing random characters.
Usually I yanked the keyboard off and did a ctrl-Z to put back the affected code, but it seems that I missed the deletion of a key line. These are the kinds of problems and setbacks that never should happen, where my time is not debugging my designs or implementations but some random bad luck. I can only hope that there aren't other signals that are now missing, wiped out in the same event that took out my power on reset signal.
I am back at the point I was debugging when everything fell apart. I restored the instrumentation to examine the feed check causes and went back to testing. I no longer get a read check, so I must have resolved some of the timing issues, but I do see a feed check from the run-in. When I did the first capture, I could see that something else is still not right because the 'card in preread station' status should be on, but is not. I found the remaining dangling items, including a flaky connection to the reader's stacker full signal which was making the Attention lamp flicker and interrupting the logic.
I am back to debugging the read driven by a program XIO instruction, no longer receiving the read check but the data is not arriving in memory. I will trace some key fields to convince myself that I am setting up the correct data for the IBM adapter logic, but will also desk check the logic involved with data transfer into memory via cycle stealing, the mechanism used by the 2501 reader.
It is coming to the end of Sunday and I just (re)discovered a truth about FPGAs and non-clock-synchronous logic. IBM logic is riddled with latches that are composed of a pair of combinatorial gates with the output of the second fed back as an input to the first. These work fine with real combinatorial gates, but not so well with the lookup tables that are the true implementation inside the fpga. Often they will exhibit flaky and inexplicable behavior, at least inexplicable if one looks at the gates they believe are being implemented.
The IBM combinatorial latches are designed so that once any of the trigger signals temporarily switches on the first gate, the signal propagates through the second and back to the first to keep it energized after the original triggering signals have dropped. The second gate has reset signals that are ANDed with the output of the first gate, so that if any of the reset signals goes off, it blocks the signal and lets the first gate drop back to an off state.
If you build one of these on a breadboard, you will see it work reliably, because the delays of signals are well understood between the first and second gate. However, once the fpga synthesizer converts these into a truth table and then into values in a lookup table, this all falls apart.
Now, the reliability depends on the relative spacing of the various trigger and reset conditions as well as the spacing of the lookup tables. Each pass through the synthesizer when you have made a change somewhere very different in the total design causes the toolchain to redo the placement of everything.
Something works, then in next build it does not, then it works again in a third build, none of which have changes that touch at all on this logic. My solution, discovered the hard way working on other parts of the machine, is to take the signal in the loop between the two gates and make it clock synchronous. That adds one 20ns fpga clock cycle to it switching state, but in the context of a 275ns cycle machine like the 1130, or more importantly to IO devices that operate in hundreds of microseconds to hundreds of milliseconds, it is totally hidden.
It takes quite a while to go through all the code to make these changes, then there is the larger task of going back through the other adapter logic for devices I have not exhaustively tested yet, seeking out and inserting registered signals in all the combinatorial latches. I should also scan through the actual 1130 processor just to make sure I haven't missed any combinatorial latches that may cause glitches.
I am now digging into a lack of synchronization between the Documation reader and the virtual 2501 reader, where the end result is the 2501 frozen waiting for the reader to fill the FIFO but we only have 79 characters pushed in the stack and the card is over. If this is a failure mode, I need some reasonable solution, such as delivering a read check to the 2501.
I have reached the end of the weekend and will post this blog entry, then continue in the new week to work on the reader and the other parts of the project. Time to think through possible causes of the skipped column, likely due to conditions on the serial link, then work on solutions.
TEKTRONIX AND OTHER MISCELLANY
7D01 Logic Analyzer and DF1 Display Formatter
Now that my readout board functions in the 7603 mainframe scope, albeit with the temporary extended cables I built combining peltola cable segments with SMA connectors and adapters, I decided to try the 7D01/DF1 logic analyzer plug-in.
As always with a 'new' plug-in, you check the power supply connections to ensure none are shorted to ground by a failed tantalum capacitor, a very frequent failure in Tek plug-ins. Getting a clean bill of health from the VOM, I slid the plug-in into the 7603 and powered up. The unit appears to work well - although I didn't sample any signals yet, it displays various tables and configurations in a healthy way. Later I will use this to sample some signals as a further test, but it looks very promising.
I did discover to my surprise that I did not need the readout function in my scope to make use of this. The DF1 side (display formatter) does its own character generation, using the regular scope inputs to move the beam, ignoring the readout board. I could have used this weeks ago when I first received it. The readout function is still useful for my 7D15 frequency counter/timer plug-in and others, fortunately.
I hooked some signals up to the tracer and see that it is recording the state. There are some anomalies in what I see - burst where all signals are zero even though some are statically high - but this may be my lack of understanding of all the controls and functions. I read the manual in order to do a more definitive test of the unit.
Now that I knew what should occur and how to work all the controls and modes, I built the test fixture that Tektronix uses to check the unit - an 8 bit binary counter driven by a 1KHz clock. I threw a couple of chips on a breadboard logic experimenter unit in my shop, that has a convenient 1KHz clock generator as one of its built in facilities, and hooked it up to the probes. Using the display formatter (DF1) I can see the character based state tables, which show it is indeed recording, triggering and manipulating everything properly.
However, there are two modes that include some vector scan data along with the generated characters. These are not producing good output. The X by Y map mode just gives a thin horizontal line. The other mode should give me 16 stacked horizontal dashed lines showing the bit value from left to right of each of the stacked signal lines. Instead, I get some faint stacked lines but no dashes, they are continuous and no sign of the data pattern.
I pulled the DF1 off the analyzer, which would produce the stacked line display I just described as its only output. It yields the same faint junk. Further, while the vertical position and magnification controls change the screen image, the horizontal controls do nothing. This tells me that the 7D01 output is not working correctly, probably the horizontal section but it also could be the z intensity control part. I need to figure out what is wrong,when I get the time.
I had some time waiting for fpga code to be synthesized that was perfect to work on diagnosing the logic analyzer. I put a second oscilloscope on a few test points, where I saw reasonable waveforms. As I was working through the schematics to see what components might be bad, consistent with the external symptoms, I found the core problem.
The reason that the horizontal magnification and positioning controls were nonfunctional was because the connector to one of the internal circuit boards was unfastened. It was deep inside and not very obvious to the eye until I was following the cable - my plan had been to check the voltages at that connector - and noticed it hanging free.
I plugged the connector onto the logic board, put the unit back in the scope and tested again. Now I have the correct display of the signals, with the trigger and cursor points intensified. One function that appears to be misbehaving is the character generator logic that writes the trigger to cursor distance on the top of the screen and the binary values of the signals (at the time selected by the cursor) are written across the bottom. On my machine, the top is blank and the bottom is a constant string of 16 ones.
However, I mounted the DF1 formatter and with that unit, I do get the cursor position in characters, the correct values of the signals and all the other formatting. This is pretty usable already, even if I don't immediately fix the niggling issues remaining, particularly when used with the DF1 which is the norm.
Other capabilities that are not working correctly even using the combined 7D01 and DF1 include:
- The second set of eight signals is always ones, although I am feeding the probe a duplicate of the signals going to the corresponding signals in the first group of eight. I swapped the probe positions into the analyzer and the results are the same, so the probes themselves work correctly.
- There is a switch to organize the memory and display depending on whether the period of interest is mainly prior to the trigger condition, centered on the trigger condition or focuses on what occurs after the condition. The position for post-trigger does not work, the result is the same as the centered position.
I have clipped the switch off and found that it now works due in part to the twisting on the cut off lead; too late, of course. If I can't find the exact replacement switch, I can install another mini toggle switch as long as it has a shorter neck but visually identical handle length and swing, even if I have to use some bridge wiring to the PCB.
7603 scope add-in readout capability
My replacement peltola-connector cables arrived, I installed them and verified my machine's readout capability still works. I still have one frankenstein cable inside, the one that has, as connectors, peltola on one end and molex twin pin push-on at the other. I can live with this as the quality of the readout is excellent.
Other Tektronix gear
I have a couple of timebase plug-ins that stopped working when I drove them from the curve tracer hooked to the external trigger BNC - happened twice so I must be supplying too much voltage which nailed some weak component in both of them. These are on the side for debugging when I need a break from the real project tasks.
Other test gear
The transistor curve tracer circuit board is now mounted on a small block of wood to give it a base, protect it a bit, yet leaving the connectors exposed for easy access. I won't be doing anything further with this equipment, it is ready to store and use as necessary.
LIGHT PEDESTAL COMPLETION
Last week I made the decision to move the circuit boards and LEDs back in the acrylic light masks, reducing sideways illumination through the black portions of the plexiglass panel at the front because its black is not sufficiently opaque to get good results when the LEDs were fully inserted into the mask. I had to design and make a method to secure the boards behind the masks, instead of glued onto the back of the mask as I originally intended.
I investigated several methods before settling on the approach I will use. Part of the problem is the materials being used causing challenges in various means of securing it. It is difficult to impossible to drill and tap holes for a screw in the acrylic. Further, it is not an easy surface to which to glue anything.
Normally, two pieces of acrylic are joined by a 'cement' that is actually a solvent that slightly melts the plastic surface, allowing acrylic molecules to link up to form a bond. This won't work unless both pieces are acrylic, not the case here.
The other component, the printed circuit board, is a fiberglass reinforced resin. As well, whatever I use to hold the PCB away from the mask or to the enclosure body (steel), as to be able to connect to that resin. I can drill holes and use bolts, but not into the acrylic mask.
Fortunately, I can drill holes in the acrylic, even if I can't tap it with threads. If the hole accepts an acrylic dowel which I cement in place, I will have rods sticking out sideways and behind. These can be placed through holes in the upright brackets to affix everything in place.
I have to move slowly and carefully, since this area of the machine so often sustains new damage each time I move forward on some other change. Particularly as these sit up against the plexiglass panel whose paint is so fragile and already has quite a few battle scars.
I did run a test of my concept - acylic mask forward abutting the plexiglass panel from inside, the PCBs stationed a bit back so the LEDs only extend a short distance into the holes in the mask grid - and was pleased with the visual appearance. My yellow-orange translucent plastic sheet gives a much more realistic incandescent-like glow to the characters, the lights are bright enough to be read in normal room light and the shine through the black opaque sections is minimized. I am pleased.
I came up with a new design concept, allowing all the acrylic parts to be cemented together using only acrylic to acrylic bonds, but with a drilled hole vertically where a bolt and nut can secure it to the floor of the enclosure. The PCBs will have spacer objects epoxied to their faces to hold them back from the light masks. I will need something simple to keep the PCBs pushed forward onto their spacers, but will wait on designing that until next week.
I began carefully prepping the three acrylic light mask sections to glue them together along with a filler element to achieve perfect alignment to the plexiglass light panel for all the lamps. I will need some acrylic blanks in rectangular cross section to finish the mounts; Tap Plastics is not open today. I was able to glue together two of the three masks, because those two needed only a very thin shim to achieve the right spacing - I had a suitable sheet of acrylic for that task.
No comments:
Post a Comment