EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: guenthert on February 10, 2020, 03:59:57 am
-
So far I have been unable to access my Keithley 181 using GPIB. I tried the Arduino based AR488 discussed on eevblog earlier, but that seems to cause the Keithley 181 to reset (display goes out briefly and range etc. is set to power-on defaults) whenever I send a query. I had a look at the source code for the AR488 and suspected then that it wouldn't get all corner cases quite right.
Meanwhile I got a bone-stock PCI GPIB adaptor from NI (and a hefty GPIB cable from HP) which I control so far using linux-gpib's ibterm program (the box the GPIB adaptor is in is headless and currently doesn't run Windows). Still can't communicate properly with the Keithley, but the symptoms are different now: the Keithley does light up the 'remote' LED, but otherwise doesn't seem to respond. The linux-gpib software reports timeouts and claims it's unable to write to the device (the remote device is meant, not the local unix character device).
Both software/hardware combination can communicate successfully with my Keithley 220 current source from the same vintage (and similar command strings), so somehow the 181 seems to be 'special'. And yes, I did check that the 'T[alk]O[nly]' switch in the rear is off (toggled it even a few times in an attempt to clean the contact, in case that would be necessary).
Anything else I could try, before I open the 181 and poke it with an oscilloscope (don't have a 5V tolerant logic analyzer)?
-
Hello,
have you send K0X and have you the right terminator?
best regards
egonotto
-
Hello,
have you send K0X and have you the right terminator?
best regards
egonotto
Don't know what you mean by terminator here.
-
I was confident that my NI PCI GPIB adaptor was in good shape and I didn't mess up the programming (using linux-gpib) too badly, but I couldn't be sure. So I took an Arduino Nano transformed into an AR488 and programmed it to be a GPIB sniffer. With that I see that the DAV and NRFD are pulled low all the time.
I also acquired meanwhile an old HP LA with that it looks like the DAV and NRFD lines don't match between the MC68488 chip (actually a HP 1820-2219) and the GPIB connector. So I suspect the bus driver is bad (curiously those lines are on two separate bus drivers -- could they both be bad? Some doubt remains).
The MC68488 is socketed and there is some flux residue around the socket. So I presume there has some repair work in that area been done before. Next step would then be to simply pull the MC68488 and verify the bus drivers, alas that chip (40pin DIP) sits tight and the space around it is somewhat constrained...
-
Hello,
in Operator's Manual Model 181 at page 4-6:
"Programmable Terminator. The data string of the Model
181 is normally terminated with one or two ASCII
characters. The default terminator sequence is (CR LF),
but this may be changed by sending the ASCII character
Y followed by the desired terminator. For example, if the
desired terminator is the letter H, the sequence YHX
must be sent over the bus."
Best regards
egonotto
-
Thanks for the clarification. I had flash-backs to SCSI with the there required bus-termination. Surely within all my attempts there must have been one were I accidentally got the right sequence. :P
Meanwhile I can say with confidence though that the MC3447 bus drivers (both of them) are shot. ATN and DACK (the former hardwired to be an input here) are low w/o anything plugged in. Looks to me like the internal resistor network was damaged.
Not sure, if I dare to desolder those chips or leave that to someone more qualified ...
-
This should probably go into the Repair section now.
Anyhow, if indeed just the internal resistor network is damaged, then I should be able to fix this by adding an external resistor. Let me try that ...
EDIT:
The external resistor didn't get me any further.
I then kind of messed-up by ordering the wrong parts. I couldn't find the MC3447 locally and got two from FleeBay. That were however the MC3447P3, not the MC3447P soldered in the KE181. The P3 are (fortunately) electrically identical, but use a smaller package (the width you would expect a 14pin DIP to be), while the P are as wide as a MC6800 CPU (or most 40pin DIP).
Didn't want to sink in another $20 and wait several weeks for a package from China for right chips (the ones I could find in North America were all P3), so I cut out the defect chips, flattened the 24p sockets I had and soldered those to the stumps of the legs of the removed chips. Not pretty, but seems to work.
Lo and behold, I can now talk to the KE181 using GPIB! So it was indeed the defect bus driver chips and not my limited understanding of the GPIB protocol. :P
-
Aside of the hardware issues above, the Keithley 181 is a bit finicky when being talked to by a stranger, or rather a controller not quite IEEE488-1978 conform. In an attempt to solve some initialization issues, I wanted to suppress the high speed (HS488) handshaking, by setting the cable length (bcHSCableLength) to 0. That doesn't seem to work, hex 1F and 0 bytes are still sent as command, which apparently confuse the nanovoltmeter, which then at first opportunity (when addressed as talker) sends a 0 byte (and only a single byte w/o setting EOI), which in turn the Linux gpib library can't deal with. Turns out, when I not set the cable length at all, no HS488 handshaking is performed and all seems well. I think the documentation is in this case a bit, er, unclear.
-
So with the basic GPIB programming under way, I wanted to know, how fast and reliable I can read from the instrument. With my current set up -- Agilent 82357b (clone?), BanaPi running bananian 4.4.66, linux-gpib r1908 -- I get about four readings/s in the higher ranges (the datasheet of the Keithley 181 promises 8/s). Long term stability seems fine, below a graph measuring a Zener (not exactly why one would get a Nanovoltmeter) over 20,000s at a rate of 2 measurements/s. There are curious outliers though: single measurements some 400mV above average. Not quite sure, where those come from (RFI? I sadly don't have a proper lab here and there are plenty of sources around).
In the 2nd graph I removed the worst offenders (some 200 of them).
-
I also had problems with GPIB communication with K181.
Sometimes communication worked fine then after some time it failed and didn't recover.
Another time there was no communication at all.
The problem was broken resistor network used as pullup for GPIB adress selection switch.
The crack was barely visible.
Photo after desoldering below.
(http://rfscientific.eu/sites/default/files/articleimage/img_2813_m.jpg)