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

[dave p. <dpe...@gm...>]

It would be interesting to see if there is any timing difference between
the W1 and W4 write / read sequence with the logic analyser.
You might want to try and run ibterm with the -N option. After sending Wn
hit enter again to trigger the read. Perhaps a short delay between the
write and read may have an effect.
/d

On Wed, 26 Jul 2023 at 22:58, Jim Houston <ji...@ov...> wrote:

>
>
> On 7/26/23 09:01, dave penkler wrote:
>
> Hi,
> Judging from
> https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html
> it should work.
> What are you seeing on the console log ?
> /d
>
>
> Hi Dave,
>
> Thanks for getting back to me. I had seen that page.  I'm adding the
> mailing list back
> to the cc.
>
> I'm not sure if I have a bug or just subtly broken hardware.
>
> I didn't find anything obvious in the kernel logs.
> I have been slowly adding debug to the agilent_82357a driver.  The failure
> mode is a timeout
> in agilent_82357a_take_control().  It is going through the process of
> writing AUX_TCS  to the
> AUXCR register to set ATN and then looping the 10 times calling
> agilent_82357a_update_status()
> and not finding ATN set.  It returns the -ETIMEDOUT which becomes EBUS by
> the time it reaches
> the ibterm.  This is the state after I send the "W4" command with ibterm.
> It looks like the
> "W4" command works it responds with a "F" but all subsequent commands get
> the EBUS
> failure.
>
> It isn't obvious why the command being sent "W1" vs. "W4"
> would cause this failure.
>
> I have been looking for similar reports in the archives and notice the
> thread:
> *[Linux-gpib-general] Agilent 82350b can't recover from read timeout?
> <https://sourceforge.net/p/linux-gpib/mailman/message/36727912/>*
>
> https://sourceforge.net/p/linux-gpib/mailman/linux-gpib-general/thread/CAKrfojgY%2BEfzqo4e3vOEoC1vU0dEPnV_BrdDVuG1PJ%2BCHge_tw%40mail.gmail.com/#msg36730587
> I see that there are workarounds in tms9914_take_control and related
> drivers.
> I'm not sure if this problem would apply to the 82357B but I may try the
> workaround.
>
> I'm also thinking about getting out my logic analyzer.  I found a gpib
> cable with
> flying leads already hooked.
>
> Jim Houston
>
>
>
>
>
>