Re: [Linux-gpib-general] Fwd: Fwd: Agilent 82350b can't recover from read timeout?

[Dirk N. <dir...@gm...>]

Hi Frank,

I thought the issue was directly related to the particular device because i
originally triggered the issue by sending an invalid command to the board.
You don't actually need to send anything- just reading from the device
without sending anything is sufficient,

Even when i do send an invalid command, from the iblines() status i don't
actually see any SRQ:

St: 0x52ff [NDAC REN ATN ]
^^ Initial status
St: 0x96ff [NDAC NRFD REN EO! ]
^ after write of *IDN?
REs: [Hewlett-Packard Co., HP7673A, 0, B.00.00\n]
^ valid read result
St: 0x16ff [NDAC NRFD REN ]
^After read
St: 0x96ff [NDAC NRFD REN EO! ]
^status after sending invalid cmd 'ID'
REs: []
^ Nothing read
St: 0x12ff [NDAC REN ]
^ status after read

Regards,

Dirk







On Wed, Jul 31, 2019 at 11:31 PM Frank Mori Hess <fm...@gm...> wrote:

> On Wed, Jul 31, 2019 at 5:47 PM Dirk Niggemann <dir...@gm...>
> wrote:
> >
> >
> > H Frank,
> >
> > I checked the value returned from the DIR register and it's almost
> always 0xa so the last byte sent on the previously successful read. Or 0 if
> we never read anything.
> >
> > I am already testing with the _unaccel driver because i wanted to make
> sure this wasn't a side effect of using the FIFOs- sorry, I should have
> mentioned that.
>
> You said the board goes into the bad state after sending an invalid
> command to the device.  The controller doesn't care if the command was
> valid or not, so what is the device doing that puts the controller
> into a bad state?  Does it request service when it receives a bad
> command?  You could check the state of the SRQ and other bus lines
> using iblines.
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>