Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

Hi Dave, Everyone,

I have made some progress on the problem I have with linux-gpib on an 
82375B trying to
access an HP3478.  The problem was that if I sent the command "W1" to 
read a nibble
from the calibration memory, it would produce the correct value "@".  I 
could do this
repeatably, but if I sent an "W4" command, it would get the correct 
reply "F", but all
subsequent attempts would fail with the EBUS -14 error.

I had tracked this down to the agilent_82357a_take_control() using the 
AUX_TCS
command to assert the ATN signal and failing with a timeout.

Since I wrote last, I have tried to replicate the problem using the 
Keysight IO libraries.
The good news is that Keysight now has a version for Linux.  The bad 
news is that
they don't document how to configure it to work with PyVISA.  The PyVISA 
documentation
helped me figure out that I had to supply the path to the shared library but
didn't have the detail.  Eventually I found:

     rm = ResourceManager('/usr/lib/X86_64-linux-gnu/libivivisa.so.7.0.0')

It almost worked.  I would send the "W1" command to the HP3478 and get 
the meter
reading as the reply instead of the expected "@".  This was was 
repeatable except
for one time where it worked correctly and returned the "@".

I was able to get a bit of insight on what was going on by capturing the 
USB traffic
with usbmon and the interface to the driver using strace.  I think that 
the failure
to  read the correct "@" reply was the result of a secondary address 
being sent.
I used GPIB::22:INSTR, but it used GPIB::22::0::INSTR and sent an extra 
0x60 in the
command stream for secondary address 0.

The Keysight IO libraries include an opensource kernel driver.  It 
provides the
connection to USB but doesn't include the GPIB specific code.  I played with
sending commands directly using this driver and was able to send a "W1"
and get an "@" back.

I also came across this discussion of 82357 clones on eevblog:

https://www.eevblog.com/forum/testgear/flood-of-new-agilent-82357b-gpib-usb-adaptors-on-ebay-the-real-deal/200/

The creator of the Bieming GPIB interface said that the 82357B uses the 
NAT9914.
I had been thinking of hooking up the logic analyzer, but when I checked 
for the
power and ground signals, the pin numbers didn't match the NAT9914 data 
sheet.  The registers
described in the NAT9914 reference manual seemed to match up with things I
saw in the usbmon traces.  For example I saw reads from register offset 
4 which
doesn't exist in a TMS9914 but is ISR2 in the NAT9914.  The NAT9914 manual
also describes the initialization sequence including setting a register 
to select the
clock frequency.

After all of this I switched back to playing with the linux-gpib driver.
One of the differences I saw in the Keysight usbmon output was that they
always used the AUX_TCA command to assert ATN signal.  I hacked 
agilent_82357a_take_control
so that it always uses AUX_TCA and my problem is solved.

This leaves the problem of finding a solution which is acceptable for 
inclusion in
linux-gpib.  I suspect that most users don't understand what the sync 
option to
ibcac() does.  Setting sync to 1 means delaying setting ATN if the 
controller believes
that an IO is in progress.  The manual page for ibcac() says that if the 
synchronous
take control times out, that ATN is set immediately.  This is clearly 
not the case
with the agilent_82357a driver.

I'm having trouble imagining the case where this is useful to use the 
synchronous option
when sending a query to a device.  I would change the ibcac() call in
drivers/gpib/sys/ibcmd.c to specify sync as 0.

Jim Houston