|
I recently acquired a parts donor for my working 468. The donor unit had a GPIB card which I tried to transplant into the working one. Having checked the documentation, I found that a DIP switch enabled the GPIB option. This I located and turned on. In addition, the ?transmit¡¯ switch and indicator LEDs were missing. Fortunately I had a similar switch in my box of bits which I was able to install and I used two LEDs instead of a single red/green one. The first problem is that both LEDs are turned on at power up which I am not sure is correct? The second is that when I connectthe GPIB board, this prevents the computer from starting up. There are no flashing zeroes on the 7-segment display. Disconnecting the board restores normailty. I checked to make sure that the short connector ribbon cables are oriented correctly. Away from the scope I checked the board and there is no obvious power rail short. On an external 5v PSU the board draws about 300ma and none of the ICs appear to be getting hot, so I am unsure what steps to take next.
Can anyone help with what further diagnostic steps I might take please?
|
On Thu, Dec 30, 2021 at 11:05 PM, John wrote:
Can anyone help with what further diagnostic steps I might take please?
This might give you some hints: It is the GPIB mod kit instruction. /H?kan
|
Thank you for that reference. It does contain a couple of bits of information that are not in the main service manual so that will be useful. Apparently the RED LED is supposed to be on, but the green one is meant to come on during transmit. Since both LEDs came on, something is evidently not quite right there.
I did ensure that the arrow on the ribbon cable was aligned with the arrow on the PCB, so the cables appear to have been installed correctly. I will check the LED wiring try attaching the GPIB board again but one cable at a time to see whether it can be narrowed down to a particular row of pins.
|
I have had another look at this today. Still not found the problem but have been able to confirm a couple of things.
Firstly without the board connected, the green LED illuminates when the scope is powered on and goes out once initialisation is complete. Secondly, pressing transmit causes storage to enter Save mode and freeze as described in the GPIB mod notes. However, the green LED does not illuminate.
I have also confirmed that the problem ocurs only when the bottom ribbon is connected to P265. With the top ribbon connected (which corresponds to the 8-bit data bus) the scope will complete initialisation. Since power does not seem to be the issue (board powers up fine as previously determined) the problem, then is related to the control signals of which there are four: ALE, GPIBSEL, INIT and GPIB INT. The remaining pins connect to ground.
The first test I tried was connecting just the GND and +5v wires and immediately the scope failed to initialise. Further tests showed incorrect voltages on the GND and 5v test pins and it turns out that the 5v source was on the other ribbon! I carefully installed them parallel to each other and thought I had correctly followed the arrows, but evidently that was not the case. Crossing them over I reconnected the GPIB board and the scope now initialised with the board connected. I considered myself fortunate that no damage had been done by my inadvertent mistake.
Finally I connected a GPIB controller which I set to the adress indicated by the DIP switches. Talk mode was off so issued a read command and was met by a response:
ID TEK/468,V79.1,FV:2.0;
I then tried sending an image of the square wave test signal by going into storage mode and pressing transmit. This time I got the device ID and firmware version and data!
ID TEK/468,V79.1,FV:2.0;WFMPRE WFID:"CH1 DC",NR.PT:512,PT.FMT:Y,XINCR:10,XZERO:0,PT.OFF:64,XUNIT:US,YMULT:4,YZERO:0,YOFF:000,YUNIT:MV,ENCDG:BIN,BN.FMT:RP,BYT/NR:1,BIT/NR:8,%QQRQQRRQQQQQQQ??????????????????????????????????????????????????????RQQQQTQRQQQQRPRQQQQQQQQOSQRQRQRQRRQQQQQQRQQQQQQQQQQ??????????????????????????????????????????????????????QQQQQQQQTQQQQQPRPRQQQVRQQQQQQQQQQRMQQQSQRQRQQQQRQRQ?????????????????????????????????????????????????????RQQRRRQQQQQQQQRQQQQRQRQRSSRQRQQQPRQQQQPPQQQQQQQQQQO??????????????????????????????????????????????????????QQQQQQQPRQRRQQQSQRQQQQRQRPQPRPQQQQQQRQRPQQQQQQQQQQQ??????????????????????????????????????????????????????RRRQQPQQQQQQQRPRPQQQQQQL
I now have to figure out how to interpret this. It doesn't look like HPGL. I am wondering whether there is a program out there that can read the Tek data?
|
Not sure about the reading, but I noticed
ENCDG:BIN
BN.FMT:RP
and the rest of the human readable stuff likely tells you exactly what is what (their way).
so it looks as if you have a binary dump after you parse the /NR:8, likely starting with the % character (the binary thereof)
Harvey
toggle quoted message
Show quoted text
On 1/2/2022 12:33 PM, John wrote: I have had another look at this today. Still not found the problem but have been able to confirm a couple of things.
Firstly without the board connected, the green LED illuminates when the scope is powered on and goes out once initialisation is complete. Secondly, pressing transmit causes storage to enter Save mode and freeze as described in the GPIB mod notes. However, the green LED does not illuminate.
I have also confirmed that the problem ocurs only when the bottom ribbon is connected to P265. With the top ribbon connected (which corresponds to the 8-bit data bus) the scope will complete initialisation. Since power does not seem to be the issue (board powers up fine as previously determined) the problem, then is related to the control signals of which there are four: ALE, GPIBSEL, INIT and GPIB INT. The remaining pins connect to ground.
The first test I tried was connecting just the GND and +5v wires and immediately the scope failed to initialise. Further tests showed incorrect voltages on the GND and 5v test pins and it turns out that the 5v source was on the other ribbon! I carefully installed them parallel to each other and thought I had correctly followed the arrows, but evidently that was not the case. Crossing them over I reconnected the GPIB board and the scope now initialised with the board connected. I considered myself fortunate that no damage had been done by my inadvertent mistake.
Finally I connected a GPIB controller which I set to the adress indicated by the DIP switches. Talk mode was off so issued a read command and was met by a response:
ID TEK/468,V79.1,FV:2.0;
I then tried sending an image of the square wave test signal by going into storage mode and pressing transmit. This time I got the device ID and firmware version and data!
ID TEK/468,V79.1,FV:2.0;WFMPRE WFID:"CH1 DC",NR.PT:512,PT.FMT:Y,XINCR:10,XZERO:0,PT.OFF:64,XUNIT:US,YMULT:4,YZERO:0,YOFF:000,YUNIT:MV,ENCDG:BIN,BN.FMT:RP,BYT/NR:1,BIT/NR:8,%QQRQQRRQQQQQQQ??????????????????????????????????????????????????????RQQQQTQRQQQQRPRQQQQQQQQOSQRQRQRQRRQQQQQQRQQQQQQQQQQ??????????????????????????????????????????????????????QQQQQQQQTQQQQQPRPRQQQVRQQQQQQQQQQRMQQQSQRQRQQQQRQRQ?????????????????????????????????????????????????????RQQRRRQQQQQQQQRQQQQRQRQRSSRQRQQQPRQQQQPPQQQQQQQQQQO??????????????????????????????????????????????????????QQQQQQQPRQRRQQQSQRQQQQRQRPQPRPQQQQQQRQRPQQQQQQQQQQQ??????????????????????????????????????????????????????RRRQQPQQQQQQQRPRPQQQQQQL
I now have to figure out how to interpret this. It doesn't look like HPGL. I am wondering whether there is a program out there that can read the Tek data?
|
What you say makes sense. Some other bits can be licked out as well: CH1, DC coupling. Could XINCR:10 indicate a x10 probe? XUNIT:US might mean microseconds. YUNIT:MV shows millivolts. These are a few I was able to pick out but not sure about the others. Trying different control settings and comparing output might help to determine the meaning of some of the others. Would help to find a reference though whick so far I have been unable to find anything useful.
Funnily enough, I am sure I have seen something very similar somewhere. If only I could remember where....
|
I'd go for XINCR:10 possibly the x10 magnifier on, unless (and I dont' think so) you had an x10 probe in the x input and you were in XY mode.
Harvey
toggle quoted message
Show quoted text
On 1/2/2022 5:31 PM, John wrote: What you say makes sense. Some other bits can be licked out as well: CH1, DC coupling. Could XINCR:10 indicate a x10 probe? XUNIT:US might mean microseconds. YUNIT:MV shows millivolts. These are a few I was able to pick out but not sure about the others. Trying different control settings and comparing output might help to determine the meaning of some of the others. Would help to find a reference though whick so far I have been unable to find anything useful.
Funnily enough, I am sure I have seen something very similar somewhere. If only I could remember where....
|
Ah yes. Getting my X and Y mixed up! The x10 magnifier was not on so maybe its a time factor, or that each horizontal graticule mark represents an increment of 10 x XUINIT which is in uS.
I am hoping that someone on here has some insight or even a pointer to some documentation?
|
Parsing the GPIB output is described in the 468 User's Manual on Tekwiki at
--
Bob Haas
|
Bob, thank you. Doh! I had the service manual and the GPIB option installation above but not the user manual so thank you for sharing that link.
|
I have now written a Python program for reading the data and creating a snapshot. It uses a Prologix style Gpib adapter to interface with the scope. I would like it to interface with Linux GPIB, but unfortunately don¡¯t have any suitable GPIB interface hardware.
|
This looks great but it only runs on Unix. I installed Python 3 on Windows and figured out how to install modules like "serial". Unfortunately, the module "termios" is only available on Unix (and Linux I assume). The python code uses termios here:
# Force DTR
f = open(ser.port)
attrs = termios.tcgetattr(f)
attrs[2] = attrs[2] & ~termios.HUPCL
termios.tcsetattr(f, termios.TCSAFLUSH, attrs)
f.close()
So it's related to DTR. Does anyone know how to accomplish this in Windows? Sorry, I do C/ASM, not python, even though python was designed by a Dutch guy (I'm from The Netherlands).
-Jan-
|
I'm trying to get the Python program that John (Twilight-Logic) posted below to run.
I was able to comment out the "termios" lines but now I'm running into a different issue. Python claims that module "serial" has no attribute "Serial":
Python 3.10.2 (tags/v3.10.2:a58ebcc, Jan 17 2022, 14:12:15) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
========== RESTART: C:\electronics\Tek468\468plot-main\src\468plot.py ==========
Traceback (most recent call last):
File "C:\electronics\Tek468\468plot-main\src\468plot.py", line 728, in <module>
ser = serial.Serial()
AttributeError: module 'serial' has no attribute 'Serial'
I installed "serial" as follows: Python -m pip install serial
John, thank you so much for your brilliant AR488 design!
|
Quick update here: It turns out that there are 2 Python modules exporting the name "serial", one called serial, one called pyserial. I had to do "Python -m pip uninstall serial", followed by " Python -m pip install pyserial" before it worked. Found this by searching for the error message.
I was able to download exactly 1 WF from my 468 using the micro-pro based AR488 controller (configured as a controller) but after that no more communication.
A while ago, I posted this on eevblog:
================
I was able to talk to a Tektronix 468 (with GPIB option) using the micro-pro version of AR488 (thanks so much for this design).
The program I used was the Prologix Configurator from KE5FX (this means I had to change the AR488 version string to match prologix).
The 468 was configured as device 3 and the TALKONLY option was DISABLED.
Commands I issued before turning the 468 on:
++addr 3
++srqauto 1
++eor 7
The 468 (which is ONLY a talker, not a listener) issues an SRQ value 1 on startup (called Power On SRQ).
==============
the AR488 handles this SRQ using these settings. With this setting, the GPIB LED on the side of the 468 is turned off because the "Power On SRQ" request is now handled.
-Jan-
|
Hi, David.
I'm mostly interested in the DIGITAL internals of the 468: how does the 8085 CPU accomplish its tasks. Making the GPIB work is part of that.
As I mentioned, John (Twilight-Logic) created this AR488 GPIB controller which can be made for less than $20.00 (I made the pro-micro version, see for more info).
Problem with GPIB is, of course, that you need application software to process the custom GPIB commands and John provided that below - in Python which is another project :)
My cheap digital scope does all this much better, but making this 40 year old scope work the way it was intended is a goal in itself. Besides that, CRT scopes are much better at XY displays (see my Dutchtronix AVR Oscilloscope Clock). If anyone is interested in the 8085 firmware running the 468, please contact me.
What I really interested is is this: is there a way to produce "digital XY" mode on the 468? Currently, if you set the TIME/DIV knob to XY mode while the scope is in digital mode ("STORAGE" in Tek terminology), the scope gets into an undefined state.
While looking at the XY mode in Analog mode, I noticed the following: there is a separate path for Vertical Channel 1, which is the horizontal (X) signal in XY mode, but Channel 2 follows the normal path, including the delay line. This causes the Y signal to arrive later at the main amplifiers than the X signal. Is the delay so small that it doesn¡¯t matter, or is there a correction I have not found yet? For Channel 1, see J107 <1> going directly to <10>, the horizontal amplifier. For Channel 2, see <2> going to <3>, to the Delay Line, going to <5>, the vertical amplifier.
-Jan-
|
Some things to consider on this scope:
1) it is send only, IIRC, and was never designed for remote operation.
2) you set it up with the front panel controls, I don't think that any of the scope settings can be remoted.
3) IIRC, this was a "get waveform, press button, get printed copy" concept.
I did look at replacing the CPU, but that was going to be a plugin module of some sort, either just replacing the CPU or CPU/ROM etc.
Although, the original system RAM and ROM become more or less irrelevant once you put in an ARM processor.
Harvey
toggle quoted message
Show quoted text
On 2/17/2022 2:50 PM, jrseattle wrote: Hi, David.
I'm mostly interested in the DIGITAL internals of the 468: how does the 8085 CPU accomplish its tasks. Making the GPIB work is part of that.
As I mentioned, John (Twilight-Logic) created this AR488 GPIB controller which can be made for less than $20.00 (I made the pro-micro version, see for more info).
Problem with GPIB is, of course, that you need application software to process the custom GPIB commands and John provided that below - in Python which is another project :)
My cheap digital scope does all this much better, but making this 40 year old scope work the way it was intended is a goal in itself. Besides that, CRT scopes are much better at XY displays (see my Dutchtronix AVR Oscilloscope Clock). If anyone is interested in the 8085 firmware running the 468, please contact me.
What I really interested is is this: is there a way to produce "digital XY" mode on the 468? Currently, if you set the TIME/DIV knob to XY mode while the scope is in digital mode ("STORAGE" in Tek terminology), the scope gets into an undefined state.
While looking at the XY mode in Analog mode, I noticed the following: there is a separate path for Vertical Channel 1, which is the horizontal (X) signal in XY mode, but Channel 2 follows the normal path, including the delay line. This causes the Y signal to arrive later at the main amplifiers than the X signal. Is the delay so small that it doesn¡¯t matter, or is there a correction I have not found yet? For Channel 1, see J107 <1> going directly to <10>, the horizontal amplifier. For Channel 2, see <2> going to <3>, to the Delay Line, going to <5>, the vertical amplifier.
-Jan-
|
Thanks Harvey for your reply. Yes, the 468 does not support remote operation. However it does support a remote WF request from the GPIB controller.
Replacing the CPU with a more modern microcontroller is the ultimate goal. That would replace all the ROMs as well as the System/Scratch RAM. However, the Acquisition RAM (512 bytes) and Display RAM (1K) are still needed since the 468 hardware autonomously accesses those. I' m more into AVRs then ARM myself.
At the same time, I have been able to change the address decoding logic so that I can now use the full 32KB ROM space, using an AT28C256 Eeprom, as well as added Serial I/O (with the existing 8085 CPU). I have decoded the Service ROM code and relocated it to run in the address space above the standard 16KB ROM range.
-Jan-
|
zenith5106
Bob Haas
jrseattle