linux-gpib-general — linux-gpib package mailing list

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

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

Yes, that works too.

That leaves the question of why there is a byte to read when nothing was
sent?

Regards,

Dirk

On Tue, Jul 30, 2019 at 3:51 AM Frank Mori Hess <fm...@gm...> wrote:

> On Mon, Jul 29, 2019 at 3:08 PM Dirk Niggemann <dir...@gm...>
> wrote:
> > I'd traced it down to ibcac (in sys/ibcac.c) and
> tms9914_take_control()  in tms9914_aux.c myself- it skips the TCS because
> the board is not addressed to listen and goes straight to the TCA which
> fails with ATN unasserted.
> >
> > The weird thing is i managed to unwedge the TCA by sending  write_byte(
> priv, AUX_RHDF, AUXCR );  just before it- (in a misunderstanding of how
> holdoffs in read actually work, I think).
> >
>
> I wonder if it gets gummed up due to an unread byte in the data in
> register.  if you do a "read_byte( priv, DIR )" instead of the release
> data holdoff, does it also make the take control async work?
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

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

[Frank M. H. <fm...@gm...>]

On Mon, Jul 29, 2019 at 3:08 PM Dirk Niggemann <dir...@gm...> wrote:
> I'd traced it down to ibcac (in sys/ibcac.c) and  tms9914_take_control()  in tms9914_aux.c myself- it skips the TCS because the board is not addressed to listen and goes straight to the TCA which fails with ATN unasserted.
>
> The weird thing is i managed to unwedge the TCA by sending  write_byte( priv, AUX_RHDF, AUXCR );  just before it- (in a misunderstanding of how holdoffs in read actually work, I think).
>

I wonder if it gets gummed up due to an unread byte in the data in
register.  if you do a "read_byte( priv, DIR )" instead of the release
data holdoff, does it also make the take control async work?

Re: [Linux-gpib-general] ibln() fails on Agilent 82357a

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

Hi,
I can confirm the GPIB-USB-HS doesn't need the MTA  command to address
itself to talk for ibln() to work.
However, using it seems to have no negative effects.

Regards,

Dirk

On Sat, Jul 27, 2019 at 11:12 PM Dirk Niggemann <dir...@gm...>
wrote:

>
> Hi Frank,
>
> I can confirm that adding MTA is also needed on the Agilent 82350b PCI
> GPIB card.
> I hope to be able to test with an USB-GPIB-HS later in the week.
>
> Regards,
>
> Dirk Niggemann
>
>
> On Thu, Jul 25, 2019 at 2:44 AM Frank Mori Hess <fm...@gm...> wrote:
>
>> It might be due to the gpib transceiver, which sits between the actual
>> gpib bus lines and the gpib chip.  The transceiver controls whether
>> the various bus lines are inputs or outputs.  The transceiver I'm
>> looking at configures NDAC as an output/input based on whether the
>> gpib chip is talker.  So it seems as a practical matter we do need to
>> address the controller as talker to read the NDAC line.  The 488.2
>> FindListeners protocol doesn't include any mention of talker
>> addressing, only listener addressing, which you could take to mean
>> that addressing the controller as talker shouldn't cause any problems
>> with the protocol.  We should probably mention in the docs that the
>> functions change the talk state of the controller though.
>>
>> On Mon, Jul 22, 2019 at 4:54 PM dave penkler <dpe...@gm...> wrote:
>> >
>> > Hi Dirk,
>> > Does using ibcmd() to address the board as talker before calling ibln()
>> not work for you ?
>> > AFAICT there should be no issue to add the one-line patch as standard
>> behaviour for the 82357a but I don't know whether it could adversely affect
>> other card types.
>> > -Dave
>> >
>> > On Mon, 22 Jul 2019 at 20:35, Dirk Niggemann <dir...@gm...>
>> wrote:
>> >>
>> >> It looks like the Agilent 82357a has the same issue as some of
>> Measurement Computing cb7210.2 chips (even though it purports to e tms9914
>> internally)  and can't read the state of the NDAC line unless addressed to
>> talk.
>> >> There was a simple one-line patch published by  Bernhard Heibler in
>> 2004 on this list that still applies today.
>> >>
>> >> Adding the single line to add a MTA command in listenerFound in
>> ibFindLstn.c resolves the issue.
>> >>
>> >> Can we make this either the standard behaviour or add some kind of
>> option in gpib.conf to enable the alternate behaviour?
>> >>
>> >> For my application, autodiscovery would be very useful.
>> >>
>> >> Regards,
>> >>
>> >> Dirk
>> >>
>> >> _______________________________________________
>> >> Linux-gpib-general mailing list
>> >> Lin...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>> >
>> > _______________________________________________
>> > Linux-gpib-general mailing list
>> > Lin...@li...
>> > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>>
>>
>> --
>> Frank
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>

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

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

FYI the fix you provided made no difference. It's definitely the RHDF that
seems to unstick the ability to assert ATN. I'm not sure what other side
effects that's likely to have.

Dirk

On Mon, Jul 29, 2019 at 6:20 PM Dirk Niggemann <dir...@gm...>
wrote:

> Hi Frank,
>
> I'd traced it down to ibcac (in sys/ibcac.c) and  tms9914_take_control()
> in tms9914_aux.c myself- it skips the TCS becauase the board is not
> addressed to listen and goes straight to the TCA which fails with ATN
> unasserted.
>
> The weird thing is i managed to unwedge the TCA by sending  write_byte(
> priv, AUX_RHDF, AUXCR );  just before it- (in a misunderstanding of how
> holdoffs in read actually work, I think).
>
> Regards,
>
> Dirk
>
>
>
> On Mon, Jul 29, 2019 at 5:09 PM Frank Mori Hess <fm...@gm...> wrote:
>
>> On Mon, Jul 29, 2019 at 8:17 AM Frank Mori Hess <fm...@gm...> wrote:
>> >
>> > On Sun, Jul 28, 2019 at 3:22 PM Dirk Niggemann <
>> dir...@gm...> wrote:
>> > >
>> > > Hi,
>> > >
>> > > I have a strange difference in behaviour between the Agilent 82357a
>> and the Agilent 82350b cards in linux-gpib-4.2.0 running on ubuntu 16.04 on
>> a 32-bit kernel  4.4.0-157-generic.
>> > >
>> > > Sending an invalid command ('ID' instead of '*IDN?') to a specific
>> device (HP7673 on ID 8) results in a bus lockup. On the 82357a this can be
>> cleared using ibclr() but on the 82350b the lockup can only be cleared by
>> reinitialising the board with gpib_config.
>> > >
>> > > Any other command aborts immediately with iberr set to 14  EBUS until
>> the board is reinitialised.
>> > >
>> > > The EBUS error is directly translated ETIMEDOUT error from the ibcmd
>> ioctl,
>> > >
>> > > This error occurs immediately, even if the timeout is set to 10s, so
>> it's almost like the timer can't  successfully restart after a timeout.
>> > >
>> > > I can't figure why nothing clears this error on the 82350b.
>> >
>> >
>> > It's probably a bug in the tms9914 module.  My guess the chip is
>> > raising an error interrupt (HR_ERR) to try to indicate a data byte got
>> > discarded without being read.  Hmm actually try adding the change I
>> > just added in svn commit 1821.  It looks like the tms9914 command
>> > coded needed to clear the bus error state.
>>
>> Hmm, actually from what you said it the timeout must be coming when
>> the board tries to assert the ATN line.  So in the kernel drivers,
>> ibcmd is calling ibcac is calling tms9914_take_control which is timing
>> out.  It makes sense the synchronous attempt to take control would
>> fail, but it should be falling back to asynchronous which should not
>> fail (but apparently it is).
>>
>> --
>> Frank
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>

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

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

Hi Frank,

I'd traced it down to ibcac (in sys/ibcac.c) and  tms9914_take_control()
in tms9914_aux.c myself- it skips the TCS because the board is not
addressed to listen and goes straight to the TCA which fails with ATN
unasserted.

The weird thing is i managed to unwedge the TCA by sending  write_byte(
priv, AUX_RHDF, AUXCR );  just before it- (in a misunderstanding of how
holdoffs in read actually work, I think).

Regards,

Dirk



On Mon, Jul 29, 2019 at 5:09 PM Frank Mori Hess <fm...@gm...> wrote:

> On Mon, Jul 29, 2019 at 8:17 AM Frank Mori Hess <fm...@gm...> wrote:
> >
> > On Sun, Jul 28, 2019 at 3:22 PM Dirk Niggemann <dir...@gm...>
> wrote:
> > >
> > > Hi,
> > >
> > > I have a strange difference in behaviour between the Agilent 82357a
> and the Agilent 82350b cards in linux-gpib-4.2.0 running on ubuntu 16.04 on
> a 32-bit kernel  4.4.0-157-generic.
> > >
> > > Sending an invalid command ('ID' instead of '*IDN?') to a specific
> device (HP7673 on ID 8) results in a bus lockup. On the 82357a this can be
> cleared using ibclr() but on the 82350b the lockup can only be cleared by
> reinitialising the board with gpib_config.
> > >
> > > Any other command aborts immediately with iberr set to 14  EBUS until
> the board is reinitialised.
> > >
> > > The EBUS error is directly translated ETIMEDOUT error from the ibcmd
> ioctl,
> > >
> > > This error occurs immediately, even if the timeout is set to 10s, so
> it's almost like the timer can't  successfully restart after a timeout.
> > >
> > > I can't figure why nothing clears this error on the 82350b.
> >
> >
> > It's probably a bug in the tms9914 module.  My guess the chip is
> > raising an error interrupt (HR_ERR) to try to indicate a data byte got
> > discarded without being read.  Hmm actually try adding the change I
> > just added in svn commit 1821.  It looks like the tms9914 command
> > coded needed to clear the bus error state.
>
> Hmm, actually from what you said it the timeout must be coming when
> the board tries to assert the ATN line.  So in the kernel drivers,
> ibcmd is calling ibcac is calling tms9914_take_control which is timing
> out.  It makes sense the synchronous attempt to take control would
> fail, but it should be falling back to asynchronous which should not
> fail (but apparently it is).
>
> --
> Frank
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

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

[Frank M. H. <fm...@gm...>]

On Mon, Jul 29, 2019 at 8:17 AM Frank Mori Hess <fm...@gm...> wrote:
>
> On Sun, Jul 28, 2019 at 3:22 PM Dirk Niggemann <dir...@gm...> wrote:
> >
> > Hi,
> >
> > I have a strange difference in behaviour between the Agilent 82357a and the Agilent 82350b cards in linux-gpib-4.2.0 running on ubuntu 16.04 on a 32-bit kernel  4.4.0-157-generic.
> >
> > Sending an invalid command ('ID' instead of '*IDN?') to a specific device (HP7673 on ID 8) results in a bus lockup. On the 82357a this can be cleared using ibclr() but on the 82350b the lockup can only be cleared by reinitialising the board with gpib_config.
> >
> > Any other command aborts immediately with iberr set to 14  EBUS until the board is reinitialised.
> >
> > The EBUS error is directly translated ETIMEDOUT error from the ibcmd ioctl,
> >
> > This error occurs immediately, even if the timeout is set to 10s, so it's almost like the timer can't  successfully restart after a timeout.
> >
> > I can't figure why nothing clears this error on the 82350b.
>
>
> It's probably a bug in the tms9914 module.  My guess the chip is
> raising an error interrupt (HR_ERR) to try to indicate a data byte got
> discarded without being read.  Hmm actually try adding the change I
> just added in svn commit 1821.  It looks like the tms9914 command
> coded needed to clear the bus error state.

Hmm, actually from what you said it the timeout must be coming when
the board tries to assert the ATN line.  So in the kernel drivers,
ibcmd is calling ibcac is calling tms9914_take_control which is timing
out.  It makes sense the synchronous attempt to take control would
fail, but it should be falling back to asynchronous which should not
fail (but apparently it is).

-- 
Frank

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

[Frank M. H. <fm...@gm...>]

On Sun, Jul 28, 2019 at 3:22 PM Dirk Niggemann <dir...@gm...> wrote:
>
> Hi,
>
> I have a strange difference in behaviour between the Agilent 82357a and the Agilent 82350b cards in linux-gpib-4.2.0 running on ubuntu 16.04 on a 32-bit kernel  4.4.0-157-generic.
>
> Sending an invalid command ('ID' instead of '*IDN?') to a specific device (HP7673 on ID 8) results in a bus lockup. On the 82357a this can be cleared using ibclr() but on the 82350b the lockup can only be cleared by reinitialising the board with gpib_config.
>
> Any other command aborts immediately with iberr set to 14  EBUS until the board is reinitialised.
>
> The EBUS error is directly translated ETIMEDOUT error from the ibcmd ioctl,
>
> This error occurs immediately, even if the timeout is set to 10s, so it's almost like the timer can't  successfully restart after a timeout.
>
> I can't figure why nothing clears this error on the 82350b.


It's probably a bug in the tms9914 module.  My guess the chip is
raising an error interrupt (HR_ERR) to try to indicate a data byte got
discarded without being read.  Hmm actually try adding the change I
just added in svn commit 1821.  It looks like the tms9914 command
coded needed to clear the bus error state.

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

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

Hi,

I have a strange difference in behaviour between the Agilent 82357a and the
Agilent 82350b cards in linux-gpib-4.2.0 running on ubuntu 16.04 on a
32-bit kernel  4.4.0-157-generic.

Sending an invalid command ('ID' instead of '*IDN?') to a specific device
(HP7673 on ID 8) results in a bus lockup. On the 82357a this can be cleared
using ibclr() but on the 82350b the lockup can only be cleared by
reinitialising the board with gpib_config.

Any other command aborts immediately with iberr set to 14  EBUS until the
board is reinitialised.

The EBUS error is directly translated ETIMEDOUT error from the ibcmd ioctl,

This error occurs immediately, even if the timeout is set to 10s, so it's
almost like the timer can't  successfully restart after a timeout.

I can't figure why nothing clears this error on the 82350b.

The weird thing is that the same board works OK in win7 using the Keysight
VISA drivers, so it's not an inherent problem with the 82350 board.

The problem is definitely timer related because any read timeout triggers
the same behaviour. You don't actually need to write invalid data, just
triggering any read timeout causes the problem.

Regards,

Dirk

[Linux-gpib-general] Fwd: ibln() fails on Agilent 82357a

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

Hi Frank,

I can confirm that adding MTA is also needed on the Agilent 82350b PCI GPIB
card.
I hope to be able to test with an USB-GPIB-HS later in the week.

Regards,

Dirk Niggemann


On Thu, Jul 25, 2019 at 2:44 AM Frank Mori Hess <fm...@gm...> wrote:

> It might be due to the gpib transceiver, which sits between the actual
> gpib bus lines and the gpib chip.  The transceiver controls whether
> the various bus lines are inputs or outputs.  The transceiver I'm
> looking at configures NDAC as an output/input based on whether the
> gpib chip is talker.  So it seems as a practical matter we do need to
> address the controller as talker to read the NDAC line.  The 488.2
> FindListeners protocol doesn't include any mention of talker
> addressing, only listener addressing, which you could take to mean
> that addressing the controller as talker shouldn't cause any problems
> with the protocol.  We should probably mention in the docs that the
> functions change the talk state of the controller though.
>
> On Mon, Jul 22, 2019 at 4:54 PM dave penkler <dpe...@gm...> wrote:
> >
> > Hi Dirk,
> > Does using ibcmd() to address the board as talker before calling ibln()
> not work for you ?
> > AFAICT there should be no issue to add the one-line patch as standard
> behaviour for the 82357a but I don't know whether it could adversely affect
> other card types.
> > -Dave
> >
> > On Mon, 22 Jul 2019 at 20:35, Dirk Niggemann <dir...@gm...>
> wrote:
> >>
> >> It looks like the Agilent 82357a has the same issue as some of
> Measurement Computing cb7210.2 chips (even though it purports to e tms9914
> internally)  and can't read the state of the NDAC line unless addressed to
> talk.
> >> There was a simple one-line patch published by  Bernhard Heibler in
> 2004 on this list that still applies today.
> >>
> >> Adding the single line to add a MTA command in listenerFound in
> ibFindLstn.c resolves the issue.
> >>
> >> Can we make this either the standard behaviour or add some kind of
> option in gpib.conf to enable the alternate behaviour?
> >>
> >> For my application, autodiscovery would be very useful.
> >>
> >> Regards,
> >>
> >> Dirk
> >>
> >> _______________________________________________
> >> Linux-gpib-general mailing list
> >> Lin...@li...
> >> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
> >
> > _______________________________________________
> > Linux-gpib-general mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
>
>
> --
> Frank
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] ibln() fails on Agilent 82357a

[Frank M. H. <fm...@gm...>]

It might be due to the gpib transceiver, which sits between the actual
gpib bus lines and the gpib chip.  The transceiver controls whether
the various bus lines are inputs or outputs.  The transceiver I'm
looking at configures NDAC as an output/input based on whether the
gpib chip is talker.  So it seems as a practical matter we do need to
address the controller as talker to read the NDAC line.  The 488.2
FindListeners protocol doesn't include any mention of talker
addressing, only listener addressing, which you could take to mean
that addressing the controller as talker shouldn't cause any problems
with the protocol.  We should probably mention in the docs that the
functions change the talk state of the controller though.

On Mon, Jul 22, 2019 at 4:54 PM dave penkler <dpe...@gm...> wrote:
>
> Hi Dirk,
> Does using ibcmd() to address the board as talker before calling ibln() not work for you ?
> AFAICT there should be no issue to add the one-line patch as standard behaviour for the 82357a but I don't know whether it could adversely affect other card types.
> -Dave
>
> On Mon, 22 Jul 2019 at 20:35, Dirk Niggemann <dir...@gm...> wrote:
>>
>> It looks like the Agilent 82357a has the same issue as some of Measurement Computing cb7210.2 chips (even though it purports to e tms9914 internally)  and can't read the state of the NDAC line unless addressed to talk.
>> There was a simple one-line patch published by  Bernhard Heibler in 2004 on this list that still applies today.
>>
>> Adding the single line to add a MTA command in listenerFound in ibFindLstn.c resolves the issue.
>>
>> Can we make this either the standard behaviour or add some kind of option in gpib.conf to enable the alternate behaviour?
>>
>> For my application, autodiscovery would be very useful.
>>
>> Regards,
>>
>> Dirk
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general



-- 
Frank

[Linux-gpib-general] Fwd: ibln() fails on Agilent 82357a

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

Hi Dave,

That might well work (haven't tried it), but i'm accessing this in Python
via pyvisa/pyvisa-py and the gpib_ctypes bindings to libgpib and those
assume that ibln() works as advertised. I could probably modify pyvisa-py
or gpib_ctypes to support this but it would have to have knowledge of the
underlying card to make an intelligent decision to employ the alternative
strategy. The idea is to keep the Python application layer ignorant of
whether it is bound to libgpib, NI VISA, NI488..2, macosx_gpib_lib or
Keysight VISA on Windows.

Regards,

Dirk

On Mon, Jul 22, 2019 at 9:54 PM dave penkler <dpe...@gm...> wrote:

> Hi Dirk,
> Does using ibcmd() to address the board as talker before calling ibln()
> not work for you ?
> AFAICT there should be no issue to add the one-line patch as standard
> behaviour for the 82357a but I don't know whether it could adversely affect
> other card types.
> -Dave
>
> On Mon, 22 Jul 2019 at 20:35, Dirk Niggemann <dir...@gm...>
> wrote:
>
>> It looks like the Agilent 82357a has the same issue as some of
>> Measurement Computing cb7210.2 chips (even though it purports to e
>> tms9914 internally)  and can't read the state of the NDAC line unless
>> addressed to talk.
>> There was a simple one-line patch published by  Bernhard Heibler in 2004
>> on this list that still applies today.
>>
>> Adding the single line to add a MTA command in listenerFound in
>> ibFindLstn.c resolves the issue.
>>
>> Can we make this either the standard behaviour or add some kind of option
>> in gpib.conf to enable the alternate behaviour?
>>
>> For my application, autodiscovery would be very useful.
>>
>> Regards,
>>
>> Dirk
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>

Re: [Linux-gpib-general] ibln() fails on Agilent 82357a

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

Hi Dirk,
Does using ibcmd() to address the board as talker before calling ibln() not
work for you ?
AFAICT there should be no issue to add the one-line patch as standard
behaviour for the 82357a but I don't know whether it could adversely affect
other card types.
-Dave

On Mon, 22 Jul 2019 at 20:35, Dirk Niggemann <dir...@gm...>
wrote:

> It looks like the Agilent 82357a has the same issue as some of Measurement
> Computing cb7210.2 chips (even though it purports to e tms9914
> internally)  and can't read the state of the NDAC line unless addressed to
> talk.
> There was a simple one-line patch published by  Bernhard Heibler in 2004
> on this list that still applies today.
>
> Adding the single line to add a MTA command in listenerFound in
> ibFindLstn.c resolves the issue.
>
> Can we make this either the standard behaviour or add some kind of option
> in gpib.conf to enable the alternate behaviour?
>
> For my application, autodiscovery would be very useful.
>
> Regards,
>
> Dirk
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] ibln() fails on Agilent 82357a

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

It looks like the Agilent 82357a has the same issue as some of Measurement
Computing cb7210.2 chips (even though it purports to e tms9914 internally)
and can't read the state of the NDAC line unless addressed to talk.
There was a simple one-line patch published by  Bernhard Heibler in 2004 on
this list that still applies today.

Adding the single line to add a MTA command in listenerFound in
ibFindLstn.c resolves the issue.

Can we make this either the standard behaviour or add some kind of option
in gpib.conf to enable the alternate behaviour?

For my application, autodiscovery would be very useful.

Regards,

Dirk

Re: [Linux-gpib-general] Linux GPIB support for ADLINK driver

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

Howzit Jaime,
It looks like the card might be compatible with the NI drivers.
Can you provide us with an
$ lspci -nn output for your system with the card plugged in.
cheers,
-dave

On Mon, 24 Jun 2019 at 11:58, Jaime Nieto-Camero <ja...@tl...> wrote:

> Hi,
>
> I am wondering if someone has worked on a linux driver for the Adlink card
> LPCIe-3488A GPIB controller?
>
> Kind regards,
>
> Jaime
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Linux GPIB support for ADLINK driver

[Jaime Nieto-C. <ja...@tl...>]

Hi,

I am wondering if someone has worked on a linux driver for the Adlink card LPCIe-3488A GPIB controller?

Kind regards,

Jaime

Re: [Linux-gpib-general] sudo modprobe ni_usb_gpib

[Dale S. <dal...@gm...>]

On 6/18/19, Anderson Minozzo Begossi <amb...@uc...> wrote:
> I updated my ubuntu and am trying to recompile the driver in the new
> kernel.
> But when I execute the command sudo modprobe ni_usb_gpib i get the
> following error:
> modprobe: ERROR: could not insert 'ni_usb_gpib': Exec format error
>
> dmesg | tail output
>
> [ 1646.522555] gpib_common: version magic '4.15.0-50-generic SMP mod_unload
> ' should be '4.15.0-51-generic SMP mod_unload '
>
> Can someone help me?

Doesn't this mean that your module was compiled against a different
kernel that the one currently running?  The version numbers are
different.

Make sure your various kernel packages match.  (linux-headers-* and
linux-image-*)

-Dale

Re: [Linux-gpib-general] sudo modprobe ni_usb_gpib

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

Hi Anderson,
Do you see the module when you execute the command:
$ ls /lib/modules/`uname -r`/gpib/ni_usb
ni_usb_gpib.ko
$

If not you need to rebuild the drivers and install them in your upgraded
ubuntu.
cheers,
-Dave

On Tue, 18 Jun 2019 at 20:21, Anderson Minozzo Begossi <amb...@uc...>
wrote:

> I updated my ubuntu and am trying to recompile the driver in the new
> kernel.
> But when I execute the command sudo modprobe ni_usb_gpib i get the
> following error:
> modprobe: ERROR: could not insert 'ni_usb_gpib': Exec format error
>
> dmesg | tail output
>
> [ 1646.522555] gpib_common: version magic '4.15.0-50-generic SMP
> mod_unload ' should be '4.15.0-51-generic SMP mod_unload '
>
> Can someone help me?
>
> Enviado via UCSMail.
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] sudo modprobe ni_usb_gpib

[Anderson M. B. <amb...@uc...>]

I updated my ubuntu and am trying to recompile the driver in the new kernel.
But when I execute the command sudo modprobe ni_usb_gpib i get the
following error:
modprobe: ERROR: could not insert 'ni_usb_gpib': Exec format error

dmesg | tail output

[ 1646.522555] gpib_common: version magic '4.15.0-50-generic SMP mod_unload
' should be '4.15.0-51-generic SMP mod_unload '

Can someone help me?

-- 
Enviado via UCSMail.

Re: [Linux-gpib-general] PCI-GPIB board with TNT5004 chip from NI

[W <dat...@gm...>]

Hello Frank

Thanks for coming back to me about this issue. I have one bad and one
good news:
The bad one is that my radio test set exploded this morning releasing a
bunch of magic smoke... it was probably too stressed this long and rainy
weekend :-)

Anyway, it's going to be repaired sooner or later (probably later).

The good one is that I picked up another test equipment and I did the
test you asked...and this time it worked. There are a couple of things I
learned from that: I need to clear the instrument buffer. I have created
a python script that showed me this behavior.

Still, I don't know why ibtest did not work with the other device. I
never managed to get anything from it using the PCI board. Maybe it does
need some "special" termination strings or some different timings. Once
repaired, I will try to hook a logic analyzer. If interesting, will
publish some results here
https://github.com/daturach/Documentation/wiki/GPIB-interface-(Marconi-2955)

Thanks

Walter

Test, see below

$ ibtest
Do you wish to open a (d)evice or an interface (b)oard?
    (you probably want to open a device): d
    enter primary gpib address for device you wish to open [0-30]: 6
    trying to open pad = 6 on /dev/gpib0 ...
You can:
    w(a)it for an event
    write (c)ommand bytes to bus (system controller only)
    send (d)evice clear (device only)
    change remote (e)nable line (system controller only)
    (g)o to standby (release ATN line, system controller only)
    send (i)nterface clear (system controller only)
    ta(k)e control (assert ATN line, system controller only)
    get bus (l)ine status (board only)
    go to local (m)ode
    change end (o)f transmission configuration
    (q)uit
    (r)ead string
    perform (s)erial poll (device only)
    change (t)imeout on io operations
    request ser(v)ice (board only)
    (w)rite data string
    send group e(x)ecute trigger (device only)
: w
enter a string to send to your device: id?
sending string: id?

gpib status is:
ibsta = 0x2100  < END CMPL >
iberr= 0

ibcntl = 4
You can:
    w(a)it for an event
    write (c)ommand bytes to bus (system controller only)
    send (d)evice clear (device only)
    change remote (e)nable line (system controller only)
    (g)o to standby (release ATN line, system controller only)
    send (i)nterface clear (system controller only)
    ta(k)e control (assert ATN line, system controller only)
    get bus (l)ine status (board only)
    go to local (m)ode
    change end (o)f transmission configuration
    (q)uit
    (r)ead string
    perform (s)erial poll (device only)
    change (t)imeout on io operations
    request ser(v)ice (board only)
    (w)rite data string
    send group e(x)ecute trigger (device only)
: r
enter maximum number of bytes to read [1024]: 23
trying to read 23 bytes from device...
received string: 'PM6666/016/32
VMAX   00'
Number of bytes read: 23
gpib status is:
ibsta = 0x100  < CMPL >
iberr= 0

ibcntl = 23
You can:
    w(a)it for an event
    write (c)ommand bytes to bus (system controller only)
    send (d)evice clear (device only)
    change remote (e)nable line (system controller only)
    (g)o to standby (release ATN line, system controller only)
    send (i)nterface clear (system controller only)
    ta(k)e control (assert ATN line, system controller only)
    get bus (l)ine status (board only)
    go to local (m)ode
    change end (o)f transmission configuration
    (q)uit
    (r)ead string
    perform (s)erial poll (device only)
    change (t)imeout on io operations
    request ser(v)ice (board only)
    (w)rite data string
    send group e(x)ecute trigger (device only)
: q
demo@antix1:~/gpib


On 10.06.2019 21:38, Frank Mori Hess wrote:
> On Mon, Jun 10, 2019 at 10:08 AM W <dat...@gm...> wrote:
>> Still no luck...some more tests/info: basically there is no communication between PC and device. The PCI board is recognized and communication seems to work between PC and board. I can confirm the device works but not via this board.
>>
>> Anything else I can check?
> Would you send the full console output of ibtest from when you first
> start it until the timeout?

Re: [Linux-gpib-general] PCI-GPIB board with TNT5004 chip from NI

[Frank M. H. <fm...@gm...>]

On Mon, Jun 10, 2019 at 10:08 AM W <dat...@gm...> wrote:
>
> Still no luck...some more tests/info: basically there is no communication between PC and device. The PCI board is recognized and communication seems to work between PC and board. I can confirm the device works but not via this board.
>
> Anything else I can check?

Would you send the full console output of ibtest from when you first
start it until the timeout?

Re: [Linux-gpib-general] PCI-GPIB board with TNT5004 chip from NI

[W <dat...@gm...>]

Still no luck...some more tests/info: basically there is no
communication between PC and device. The PCI board is recognized and
communication seems to work between PC and board. I can confirm the
device works but not via this board.

Anything else I can check?

Thanks

This is my gpib.conf file:

interface {
    minor = 0    /* board index, minor = 0 uses /dev/gpib0, minor = 1
uses /dev/gpib1, etc. */
    board_type = "ni_pci"    /* type of interface board being used */
    name = "teddy"    /* optional name, allows you to get a board
descriptor using ibfind() */
    pad = 2    /* primary address of interface             */
    sad = 0    /* secondary address of interface           */
    timeout = T30s    /* timeout for commands */

    eos = 0x0a    /* EOS Byte, 0xa is newline and 0xd is carriage return */
    set-reos = yes    /* Terminate read if EOS */
    set-bin = no    /* Compare EOS 8-bit */
    set-xeos = no    /* Assert EOI whenever EOS byte is sent */
    set-eot = yes    /* Assert EOI with last byte on writes */
    master = yes    /* interface board is system controller *

/* settings for boards that lack plug-n-play capability */
    /*base = 0*/    /* Base io ADDRESS                  */
    /*irq  = 0*/    /* Interrupt request level */
    /*dma  = 0*/    /* DMA channel (zero disables)      */

/* pci_bus and pci_slot can be used to distinguish two pci boards
supported by the same driver */
/*    pci_bus = 0 */
/*    pci_slot = 7 */

    /*master = yes*/    /* interface board is system controller */
}


Output of command lsmod | grep tnt:

tnt4882                16261  0
nec7210                 9372  1 tnt4882
gpib_common            26340  2 nec7210,tnt4882


Output command lspci -n: (last 3 lines with the board ID on the last one)

03:03.0 0c00: 1106:3044 (rev 80)
03:04.0 0104: 105a:3373 (rev 02)
03:0b.0 0780: 1093:c801 (rev 02)


Output ibtest just after sending a few strings to the device: (VN is the
command to get the software version)

enter a string to send to your device: VN
sending string: VN

gpib status is:
ibsta = 0xc100  < ERR TIMO CMPL >
iberr= 6
EABO 6: Operation aborted

ibcntl = 0


Output command uname -r:

4.9.160-antix.2-486-smp


On 07.06.2019 17:59, W wrote:
>
> Ok, thanks for the info
>
> Device is a 0xc801 and vendor is 0x1093.
> tnt4882.h was already set for that device, so didn't change anything.
>
> I built the 2 packages. At the first glance, no compilation error.
> However, at the very top of the compilation messages, there is an error:
>
> "ERROR: Kernel configuration is invalid.
> include/generated/autoconf.h or include/config/auto.conf are missing."
>
> I checked these 2 files and they are not missing.
>
> The GPIB install doc says that the linux kernel should be recompiled.
> That's something I haven't done. Is that necessary?
>
> Thanks
>
> On 07.06.2019 11:53, Ansgar Kueckes wrote:
>> TNT5004 is the full-featured version of NI's GPIB chip which also
>> includes GPIB controller functions (the TNT5002 just implements
>> Talker/Listener).
>>
>> There is no "official" documentation on the TNT5004, since it is not
>> intended for separate sale. But you may get back on the documentation
>> of the TNT5002, which is available here:
>> http://www.ni.com/pdf/manuals/370595b.pdf
>>
>> That manual covers most of the chip functions. GPIB Controller
>> functions are mostly identical to those of a TNT4882, including the
>> register programming.
>>
>> The TNT5004 is supported in the Linux GPIB package by the current
>> TNT4882 driver. It *may* happen that not all boards which are using
>> that chip (especially OEM boards) are properly identified with their
>> PCI device code. That code is board specific, not chip specific. If
>> required, add the device code of your board in tnt4882.h and re-build
>> the package. IIRC the standard PCI device code for the PCI-GPIB
>> boards is 0xc801.
>>
>> -Ansgar
>>
>>> I did not see the TNT5004 driver listed. That's why I assume it's
>>> not supported.
>>>
>>> I do have a PCI board, quite old,  dated year 2007. Strange enough,
>>> I can't find any datasheet about this TNT5004 chip.
>>>
>>> "pci device id":  you mean adding it in file tnt4882.h?
>>>
>>> On 06.06.2019 23:53, Frank Mori Hess wrote:
>>>> On Thu, Jun 6, 2019 at 12:44 PM Frank Mori Hess <fm...@gm...> wrote:
>>>>> On Thu, Jun 6, 2019 at 11:12 AM W <dat...@gm...> wrote:
>>>>>> I just got one of these boards. I had a quick look at the Supported Hardware Matrix and cannot find any kernel driver
>>>>>> that would match the TNT5004 chip. I guess this board is just not supported, right?
>>>>> You should try just adding your pci device id to the tnt4882 driver.
>>>>> It will probably just work.  In the worst case, they have dropped some
>>>>> backwards compatibility behavior from the tnt5004, and that will have
>>>>> to be worked around.
>>>> Hmm, actually I'm pretty sure your board is already supported.  Why do
>>>> you say it is not in the supported hardware matrix?  Is it because it
>>>> only lists "PCI-GPIB" and not "PCIe-GPIB"?
>>>>
>>>
>>>
>>> _______________________________________________
>>> Linux-gpib-general mailing list
>>> Lin...@li...
>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>>
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] PCI-GPIB board with TNT5004 chip from NI

[W <dat...@gm...>]

Ok, thanks for the info

Device is a 0xc801 and vendor is 0x1093.
tnt4882.h was already set for that device, so didn't change anything.

I built the 2 packages. At the first glance, no compilation error.
However, at the very top of the compilation messages, there is an error:

"ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing."

I checked these 2 files and they are not missing.

The GPIB install doc says that the linux kernel should be recompiled.
That's something I haven't done. Is that necessary?

Thanks

On 07.06.2019 11:53, Ansgar Kueckes wrote:
> TNT5004 is the full-featured version of NI's GPIB chip which also
> includes GPIB controller functions (the TNT5002 just implements
> Talker/Listener).
>
> There is no "official" documentation on the TNT5004, since it is not
> intended for separate sale. But you may get back on the documentation
> of the TNT5002, which is available here:
> http://www.ni.com/pdf/manuals/370595b.pdf
>
> That manual covers most of the chip functions. GPIB Controller
> functions are mostly identical to those of a TNT4882, including the
> register programming.
>
> The TNT5004 is supported in the Linux GPIB package by the current
> TNT4882 driver. It *may* happen that not all boards which are using
> that chip (especially OEM boards) are properly identified with their
> PCI device code. That code is board specific, not chip specific. If
> required, add the device code of your board in tnt4882.h and re-build
> the package. IIRC the standard PCI device code for the PCI-GPIB boards
> is 0xc801.
>
> -Ansgar
>
>> I did not see the TNT5004 driver listed. That's why I assume it's not
>> supported.
>>
>> I do have a PCI board, quite old,  dated year 2007. Strange enough, I
>> can't find any datasheet about this TNT5004 chip.
>>
>> "pci device id":  you mean adding it in file tnt4882.h?
>>
>> On 06.06.2019 23:53, Frank Mori Hess wrote:
>>> On Thu, Jun 6, 2019 at 12:44 PM Frank Mori Hess <fm...@gm...> wrote:
>>>> On Thu, Jun 6, 2019 at 11:12 AM W <dat...@gm...> wrote:
>>>>> I just got one of these boards. I had a quick look at the Supported Hardware Matrix and cannot find any kernel driver
>>>>> that would match the TNT5004 chip. I guess this board is just not supported, right?
>>>> You should try just adding your pci device id to the tnt4882 driver.
>>>> It will probably just work.  In the worst case, they have dropped some
>>>> backwards compatibility behavior from the tnt5004, and that will have
>>>> to be worked around.
>>> Hmm, actually I'm pretty sure your board is already supported.  Why do
>>> you say it is not in the supported hardware matrix?  Is it because it
>>> only lists "PCI-GPIB" and not "PCIe-GPIB"?
>>>
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] PCI-GPIB board with TNT5004 chip from NI

[Ansgar K. <an...@hp...>]

TNT5004 is the full-featured version of NI's GPIB chip which also 
includes GPIB controller functions (the TNT5002 just implements 
Talker/Listener).

There is no "official" documentation on the TNT5004, since it is not 
intended for separate sale. But you may get back on the documentation of 
the TNT5002, which is available here: 
http://www.ni.com/pdf/manuals/370595b.pdf

That manual covers most of the chip functions. GPIB Controller functions 
are mostly identical to those of a TNT4882, including the register 
programming.

The TNT5004 is supported in the Linux GPIB package by the current 
TNT4882 driver. It *may* happen that not all boards which are using that 
chip (especially OEM boards) are properly identified with their PCI 
device code. That code is board specific, not chip specific. If 
required, add the device code of your board in tnt4882.h and re-build 
the package. IIRC the standard PCI device code for the PCI-GPIB boards 
is 0xc801.

-Ansgar

> I did not see the TNT5004 driver listed. That's why I assume it's not 
> supported.
>
> I do have a PCI board, quite old,  dated year 2007. Strange enough, I 
> can't find any datasheet about this TNT5004 chip.
>
> "pci device id":  you mean adding it in file tnt4882.h?
>
> On 06.06.2019 23:53, Frank Mori Hess wrote:
>> On Thu, Jun 6, 2019 at 12:44 PM Frank Mori Hess<fm...@gm...>  wrote:
>>> On Thu, Jun 6, 2019 at 11:12 AM W<dat...@gm...>  wrote:
>>>> I just got one of these boards. I had a quick look at the Supported Hardware Matrix and cannot find any kernel driver
>>>> that would match the TNT5004 chip. I guess this board is just not supported, right?
>>> You should try just adding your pci device id to the tnt4882 driver.
>>> It will probably just work.  In the worst case, they have dropped some
>>> backwards compatibility behavior from the tnt5004, and that will have
>>> to be worked around.
>> Hmm, actually I'm pretty sure your board is already supported.  Why do
>> you say it is not in the supported hardware matrix?  Is it because it
>> only lists "PCI-GPIB" and not "PCIe-GPIB"?
>>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] PCI-GPIB board with TNT5004 chip from NI

[W <dat...@gm...>]

I did not see the TNT5004 driver listed. That's why I assume it's not
supported.

I do have a PCI board, quite old,  dated year 2007. Strange enough, I
can't find any datasheet about this TNT5004 chip.

"pci device id":  you mean adding it in file tnt4882.h?

On 06.06.2019 23:53, Frank Mori Hess wrote:
> On Thu, Jun 6, 2019 at 12:44 PM Frank Mori Hess <fm...@gm...> wrote:
>> On Thu, Jun 6, 2019 at 11:12 AM W <dat...@gm...> wrote:
>>> I just got one of these boards. I had a quick look at the Supported Hardware Matrix and cannot find any kernel driver
>>> that would match the TNT5004 chip. I guess this board is just not supported, right?
>> You should try just adding your pci device id to the tnt4882 driver.
>> It will probably just work.  In the worst case, they have dropped some
>> backwards compatibility behavior from the tnt5004, and that will have
>> to be worked around.
> Hmm, actually I'm pretty sure your board is already supported.  Why do
> you say it is not in the supported hardware matrix?  Is it because it
> only lists "PCI-GPIB" and not "PCIe-GPIB"?
>

Re: [Linux-gpib-general] PCI-GPIB board with TNT5004 chip from NI

[Frank M. H. <fm...@gm...>]

On Thu, Jun 6, 2019 at 12:44 PM Frank Mori Hess <fm...@gm...> wrote:
>
> On Thu, Jun 6, 2019 at 11:12 AM W <dat...@gm...> wrote:
> > I just got one of these boards. I had a quick look at the Supported Hardware Matrix and cannot find any kernel driver
> > that would match the TNT5004 chip. I guess this board is just not supported, right?
>
> You should try just adding your pci device id to the tnt4882 driver.
> It will probably just work.  In the worst case, they have dropped some
> backwards compatibility behavior from the tnt5004, and that will have
> to be worked around.

Hmm, actually I'm pretty sure your board is already supported.  Why do
you say it is not in the supported hardware matrix?  Is it because it
only lists "PCI-GPIB" and not "PCIe-GPIB"?

-- 
Frank