Re: Agilent 82357B repeatable hard failure

dave penkler <[email protected]> Wed, 27 Sep 2023 13:01:16 +0200
Newsgroups gmane.linux.hardware.gpib.general
Message-ID <CAL=kjP2qGM5pw7QDeo9rpF+Y4WEsz3F1gYzWr9R-1VYSin5rNA@mail.gmail.com>
The 0x164 from the NI-USB-HS is the correct value for ibsta. Did you do one
byte reads with ibtest ?
/d

On Wed, 27 Sept 2023 at 00:05, Michael K <[email protected]> wrote:

> BTW I could not get the "onebyte.c" programe to work using the R&S NRVD
> power meter.
> I got a continuations stream of 0x0130 (occasionally a 0x013c) with the
> 82357B and, using the NI USB-HS, a continuous stream of 0x0164.
> The NRVD responded correctly when I use ibtest with *IDN?
>
> Michael
>
>
> On Tuesday, September 26, 2023 at 01:38:05 PM EDT, dave penkler <
> [email protected]> wrote:
>
>
>
>
>
> Hi Michael,
> Thanks so much for these traces. It certainly looks like the instrument
> latches the next data byte when the ADSR  (address status register of the
> 9914) is read.
> f6e240c0 13.914312 S Bo:1:039:6 - 9 =
>     03000003 01000000 00                                     <<< read
> f6e240c0 13.914346 C Bo:1:039:6 0 9 >
> f6e240c0 13.914352 S Bi:1:039:2 - 2 <
> f6e240c0 13.921144 C Bi:1:039:2 0 2 =
>     4820
>      H
> <<< H read over the bus
> f6c0bf00 13.921175 S Bo:1:039:6 - 3 =
>     050102                                                          <<<
> request to read ADSR
> f6c0bf00 13.921188 C Bo:1:039:6 0 3 >
> f6c0bf00 13.921195 S Bi:1:039:2 - 32 <
> f6c0bf00 13.921291 C Bi:1:039:2 0 3 =
>     fa0045
>      . . E                                                            <<<
> response E (the next byte)
>
> From the other traces sent by Micha and yourself the following instruments
> preciously latch the next byte: HP8753C, HP1660E, HP4191A, HP3458A
> In the HP3457A traces the current byte is read as ADSR.
> So in conclusion all the Agilent 82357B adapters for which we have seen
> traces do not return the actual ADSR from the chip when ATN is not set but
> he last data byte on the bus.
> Not sure how many folks depend on a reliable board ibsta but for now I
> propose to leave it as it is. Avoiding sending TCS should fix Jim's issue
> without affecting any other folks.
> -Dave
>
> On Tue, 26 Sept 2023 at 18:07, Michael K <[email protected]> wrote:
> >
> > OK Dave,
> >    Here is the usbmon output.
> > I also connected up the logic analyzer and saved the transaction between
> the 82357B and the HP8753C (see attached).
> > I installed your latest svn commit but I don't think I rebooted (so the
> debugging may not reflect your latest driver mod).
> > cheers,
> >    Michael
> >
> >
> >
> >
> >
> > On Tuesday, September 26, 2023 at 03:25:22 AM EDT, dave penkler <
> [email protected]> wrote:
> >
> >
> >
> >
> >
> > Hi Michael,
> > Could you please capture the usb traffic with Wireshark or usbmon for
> this onebyte run.
> > Judging by this output maybe your board behaves differently from Jim's
> and Micha's but we would like to check.
> > Each line of the decode below shows the character read, ascii code of
> character decoded as ADSR and ibsta decode.
> > It looks like the ibsta corresponds to the next character read
> interpreted as ADSR.
> > So it might be that the instrument has already latched the next byte on
> the bus when the ibsta of the board is taken after the previous read.
> > Could you do a onebyte run with a different instrument too please ?
> > No need to take the usb traffic for that also.
> > Thanks,
> > -Dave
> >
> >
> >
>
>

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