Re: Agilent 82357B repeatable hard failure

Folks,
Off-list Micha provided the usbmon traces and the corresponding outputs of
onebyte.
Analysing the traces shows that his board also returns the last byte read
when the ADSR register is read and the ATN line is not asserted.
It also shows that take control synchronously (TCS) always times out. TCS
was invoked after the read of the "E" and the "\m" where in the value of
the ADSR read ATN is not set and LA is.
When sending command bytes and ATN is already set in the returned ADSR
value  the driver skips sending the TCA/TCS.
The command succeeds anyway because the firmware always sends a TCA before
sending the command bytes to the 9914.
On Jim's board when the driver sends TCS it causes the board to hang. On
Micha's board it times out.
Below is a decode of one of the runs. The first column is the byte read,
the second up to || is the byte read decoded as ADSR and the last is
ibsta decoded
The ATN, LA and TA bits of the ADSR are systematically reflected in
ibsta by ATN, LACS and TACS respectively. In the traces the values of ADSR
read while the ATN line is asserted are correct: 0xa4 = REM | ATN | LA.

-  ATN | TPAS | LA        || CMPL | CIC | ATN | LACS
1  ATN | LPAS             || CMPL | CIC | ATN
7  ATN | LPAS | LA | TA   || CMPL | CIC | ATN | TACS | LACS
.  ATN | TPAS | LA | TA   || CMPL | CIC | ATN | TACS | LACS
3  ATN | LPAS | TA |      || CMPL | CIC | ATN | TACS
1  ATN | LPAS             || CMPL | CIC | ATN
3  ATN | LPAS | TA        || CMPL | CIC | ATN | TACS
0  ATN | LPAS             || CMPL | CIC | ATN
0  ATN | LPAS             || CMPL | CIC | ATN
0  ATN | LPAS             || CMPL | CIC | ATN
E  LLO | LA               || CMPL | LOK | CIC | LACS
-  ATN | TPAS | LA        || CMPL | CIC | ATN | LACS
0  ATN | LPAS             || CMPL | CIC | ATN
3  ATN | LPAS | TA        || CMPL | CIC | ATN | TACS
\m TPAS| LA               || CMPL | CIC | LACS

The conclusion so far is that there is a bug in the 9914 chip used in the
82357B.
I will push a patch to the SVN to avoid sending TCS in the driver. When the
TCS times out the driver falls back to TCA when it is about to send command
bytes.
cheers,
-Dave

On Mon, 25 Sept 2023 at 12:14, Michael Dittrich <[email protected]>
wrote:

> Hi Jim,
> attached the readings from two instruments including 'E' (both are
> connected to GPIB and on at the same time).
> _read are after reset, end_always are with sending "END ALWAYS" (EOI line
> set true when the last byte of each reading sent).
>
> Ciao, Micha
>
> -----Ursprüngliche Nachricht-----
> Von: Jim Houston <[email protected]>
> Gesendet: Montag, 25. September 2023 02:51
> An: Michael Dittrich <[email protected]>;
> [email protected]
> Betreff: Re: AW: [Linux-gpib-general] Agilent 82357B repeatable hard
> failure
>
> Hi Micha,  Everyone,
>
> Thank you for running this.   Would you do another run, I would like to
> see what happens with a response including the letter 'E'.  A command that
> returns a voltage would likely do.  On my HP3478A a 's' returns the front
> panel value it may work on your meters.
>
> Thanks
> Jim
>
> On 9/24/23 19:48, Michael Dittrich wrote:
> > Hi Jim,
> > attached the outputs from my system.
> >
> > Ciao, Micha
> >
> > jhouston@linux-gpib:~$ python3 byte_read.py 4 volt?
> > b'0' 256
> > b'.' 256
> > b'0' 256
> > b'E' 256
> > InternalReceiveSetup: command failed
> > Traceback (most recent call last):
> >     File "byte_read.py", line 12, in <module>
> >       ch = inst.read(1)
> >     File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in
> read
> >       self.res = gpib.read(self.id,len)
> > gpib.GpibError: read() failed: An attempt to write command bytes to the
> bus has timed out.
> > jhouston@linux-gpib:~$
> >
> >
>
> _______________________________________________
> Linux-gpib-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

_______________________________________________
Linux-gpib-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general