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

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

I should have done reply all.  Then I tried forwarding the original 
message and the
syslog file was too large so I have trimmed it down to just the debug 
messages
from the script now included inline.


-------- Forwarded Message --------
Subject: 	Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure
Date: 	Sun, 30 Jul 2023 12:53:05 -0400
From: 	Jim Houston <ji...@ov...>
To: 	dave penkler <dpe...@gm...>





On 7/30/23 08:23, dave penkler wrote:
> Hi Jim,
> There does not seem to be any timing difference in the two read 
> sequences. However in both traces NRFD is de-asserted for about 8us 
> with different timing offsets, at 473us in gpib4.vcd and 308us in 
> gpib5.vcd, after the transfer of the "@" and "F" respectively. Not 
> sure why NRFD is being de-asserted.
> Is the 3478A the only instrument on the bus at the time ? Also just 
> to clarify: You do receive the "F" in ibterm normally and it is only 
> when sending another command you get the EBUS, or do you get the EBUS 
> on the read of the "F" already ? If you send "W1" repeatedly does it 
> work every time ?
> Sorry for all the questions.
> /d
>

Hi Dave,

I spent a few minutes cleaning up a script to reproduce the problem and 
capture ibsta() and lines()
output after each step.  It ran and didn't fail.  The 82357 has healed 
over night.

So we are dealing with the Agilent 82357B hardware failing in a subtle
way rather than a driver bug.

Since I have spent the time already I will try to answer your questions 
in case they
help someone else in the future.

The HP3478 was the only instrument and was directly connected to the 
Agilent 82357B
before I hooked up the logic analyzer.

I'm attaching syslog output from an earlier attempt along with the 
python script
I was using to reproduce the failure at the time.  I started with the 
script to read
the HP3478 calibration and it is using address values which are non 
printing character
so it isn't as clear as the "W1" vs "W4".  What I see is that the the 
write and read which
cause the failure look ok.  The ibsta() value after the read is 8448 decimal
0x2100 so CMPL and END set.

I'm guessing that the problem and  healing are the result humidity. I'm in
a slightly damp basement and I cranked up the dehumidifier yesterday.

Jim Houston

jhouston@yogi:~$ grep kmsg_ syslog4
Jul 26 16:26:06 t5610 kernel: [ 7295.152917] kmsg_write W
Jul 26 16:26:06 t5610 kernel: [ 7295.161677] kmsg_read resp=b'@'
Jul 26 16:26:06 t5610 kernel: [ 7295.161689] kmsg_ibsta sta=8448
Jul 26 16:26:06 t5610 kernel: [ 7295.161717] kmsg_write W
Jul 26 16:26:06 t5610 kernel: [ 7295.171308] kmsg_read resp=b'D'
Jul 26 16:26:06 t5610 kernel: [ 7295.171354] kmsg_ibsta sta=8448
Jul 26 16:26:06 t5610 kernel: [ 7295.171381] kmsg_write W
Jul 26 21:18:09 t5610 kernel: [ 7295.176033] kmsg_error write() failed: 
An attempt to write command bytes to the bus has timed out.