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

Re: [Linux-gpib-general] Problem with ibfind / ibask to get the minor number of controller

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

Hi Dave, the docs for ibask need to be updated after adding board
level support for bna.  For a board descriptor it is just returning
the index for the board itself which may or may not be a controller,
rather than the controller the device is being accessed through.

On Thu, Aug 12, 2021, 04:23 dave penkler <dpe...@gm...> wrote:
>
>  board descriptor support to ibask for IbaBNA added to SVN revision 1987
>

Re: [Linux-gpib-general] Problem with ibfind / ibask to get the minor number of controller

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

 board descriptor support to ibask for IbaBNA added to SVN revision 1987

On Thu, 12 Aug 2021 at 08:16, dave penkler <dpe...@gm...> wrote:
>
> Hi,
> ibask on IbaBNA is only supported for device descriptors, not board
> descriptors. This is a bit annoying but could be fixed. Why do you
> need to determine the minor from the board descriptor ?
> -dave
>
> On Mon, 9 Aug 2021 at 23:02, Michael K via Linux-gpib-general
> <lin...@li...> wrote:
> >
> > I have an interface defined in gpib.conf with ....
> >
> > interface {
> >     minor = 0
> >     board_type = "agilent_82357b"
> >     name = "hp82357b"
> >     pad = 0
> >     sad = 0
> >     timeout = T30s
> >
> > /* settings for boards that lack plug-n-play capability */
> >     base = 0
> >     irq  = 0
> >     dma  = 0
> >
> >     master = yes
> > }
> >
> > If my program uses ibfind ....
> > GPIBcontroller = ibfind( "hp82357b"  )
> >
> > GPIBcontroller is returned as 16
> > If I try to use ibask to get the minor number (needed to actually talk to a device on the controller)...
> >
> > GPIBstatus = ibask(GPIBcontroller, IbaBNA, &boardIndex);
> >
> > I get an error (4 - One or more arguments to the function call were invalid.) (status 0x8130).
> >
> > What am I doing wrong ??
> > Is there a better way to get the minor number from the interface name?
> >
> > Michael
> > _______________________________________________
> > Linux-gpib-general mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] Problem with ibfind / ibask to get the minor number of controller

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

Hi,
ibask on IbaBNA is only supported for device descriptors, not board
descriptors. This is a bit annoying but could be fixed. Why do you
need to determine the minor from the board descriptor ?
-dave

On Mon, 9 Aug 2021 at 23:02, Michael K via Linux-gpib-general
<lin...@li...> wrote:
>
> I have an interface defined in gpib.conf with ....
>
> interface {
>     minor = 0
>     board_type = "agilent_82357b"
>     name = "hp82357b"
>     pad = 0
>     sad = 0
>     timeout = T30s
>
> /* settings for boards that lack plug-n-play capability */
>     base = 0
>     irq  = 0
>     dma  = 0
>
>     master = yes
> }
>
> If my program uses ibfind ....
> GPIBcontroller = ibfind( "hp82357b"  )
>
> GPIBcontroller is returned as 16
> If I try to use ibask to get the minor number (needed to actually talk to a device on the controller)...
>
> GPIBstatus = ibask(GPIBcontroller, IbaBNA, &boardIndex);
>
> I get an error (4 - One or more arguments to the function call were invalid.) (status 0x8130).
>
> What am I doing wrong ??
> Is there a better way to get the minor number from the interface name?
>
> Michael
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Problem with ibfind / ibask to get the minor number of controller

[Michael K <vk...@ya...>]

I have an interface defined in gpib.conf with ....
interface {    minor = 0                           board_type = "agilent_82357b"      name = "hp82357b"                 pad = 0                        sad = 0                       timeout = T30s                
/* settings for boards that lack plug-n-play capability */    base = 0    irq  = 0    dma  = 0
    master = yes}
If my program uses ibfind ....GPIBcontroller = ibfind( "hp82357b"  )

GPIBcontroller is returned as 16If I try to use ibask to get the minor number (needed to actually talk to a device on the controller)...
GPIBstatus = ibask(GPIBcontroller, IbaBNA, &boardIndex);

I get an error (4 - One or more arguments to the function call were invalid.) (status 0x8130).
What am I doing wrong ??Is there a better way to get the minor number from the interface name?
Michael

Re: [Linux-gpib-general] hpdrive changes: dac holdoff

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

Hi Dave,

this is fine from my side. Even in case we still can't take changes over 
into the main stream, patching new releases for the use with HPDrive 
will become way easier if most others changes are included.

-Ansgar

On 2021-05-07 14:24, dave penkler wrote:
> HI Frank and Ansgar,
> It would be great to get hpdrive working with the stock package,
> especially for users who could then benefit from this functionality
> via the distro's that ship linux-gpib.
> We certainly don't want to break anything so I am all for working
> through the issues one by one until we get down to a minimal set of
> absolutely necessary hpdrive conflicts with the current (standard)
> behaviour.
> Then we can try to find a good way to package them to avoid affecting
> existing applications. If you agree, may I suggest we start with the
> tnt4882 driver with which I can test both my t&m and hpdrive use
> cases.
> 
> -Dave
> 
> On Thu, 6 May 2021 at 08:29, Ansgar Kueckes <an...@hp...> wrote:
> 
>> Frank,
>> 
>> thanks for the open words.
>> 
>> For me it looks like linux-gpib is mostly designed after NI's ni488
>> API,
>> which is proven for most GPIB applications and probably covers 99.9%
>> of
>> all use cases. Which is mostly data exchange with measuring
>> equipment.
>> That approach seems to be quite desirable, also because porting
>> existing
>> application code to Linux is pretty easy to achieve, since ni488
>> represents some kind of industry standard and has been adopted by a
>> large number of other chip vendors. My own tools all work out of the
>> box
>> with linux-gpib, HPDrive is the single exception. So the cool thing
>> with
>> linux-gpib is that all that is available for Linux, too. Which opens
>> up
>> a new world for open applications. I understand this is the main
>> outcome
>> of your great work.
>> 
>> HPDrive and the other HP tools step into another history of GPIB,
>> that
>> of HP, the inventor of the GPIB. They go a bit deeper into what HP
>> itself achieved with HP-IB, but the challenges are similar,
>> implementing
>> the diverse mechanisms with as many chip designs as possible. I
>> think
>> the general question is, stay at ni488 level, or go beyond and
>> implement
>> the full IEEE standard, or even support special chip features. I
>> cannot
>> answer that question, this is the primary task of the maintainers,
>> who
>> define the scope of the project. There are different approaches, CEC
>> for
>> instance simply added a general register access function in their
>> (ni488
>> based) API. HPDrive uses that function to add the functionality
>> which is
>> not provided by ni488 and works fine. But I am not sure whether this
>> is
>> the way to go for security reasons.
>> 
>> I see your concerns (1) to (3) and I fully agree. I'd suggest to go
>> with
>> you and Dave through those points where existing code will be
>> affected,
>> and see whether there is a good way for a standard behavior which
>> fits
>> all use cases. In no way should existing applications be affected.
>> If
>> that is not possible, we may think about a fork or leave it as it is
>> 
>> (create patches for new releases). Although the use of GPIB is still
>> 
>> quite spread, I feel we more and more also have to take into account
>> the
>> historic relevance of HP-IB and GPIB. And think about adding the
>> historic computing to the uses cases of linux-gpib, not just limited
>> to
>> data exchange with vintage measuring & control equipment. And there
>> is
>> growing base for this. The story would not be complete without what
>> HP's
>> engineering  did with HP-IB/GPIB during the 70s and 80s.
>> 
>> HPDrive in fact is one of the key enabler for everyone who is
>> dealing
>> with vintage HP systems. Without it you would be restricted to the
>> real
>> mass storage hardware, which is going to fade away. For me
>> linux-gpib is
>> a true gift, because most HPDrive users are on Windows and I have a
>> personal interest for changing this or at least offering an
>> alternative.
>> And of course it would be comfortable not to have to step through
>> all
>> changes coming with every new linux-gpib release and do all the
>> testing,
>> but it is a quite normal procedure. Whether refactoring is affecting
>> the
>> extensions, is probably mainly a matter of documentation.
>> 
>> -Ansgar
>> 
>>> Ok, and the dac holdoff requirement seems to come from AMIGO's
>> need to
>>> change the parallel poll response synchronously with reception of
>>> certain command bytes.
>>> 
>>> One of the more disturbing aspects of the hpdrive patches is they
>>> change the behavior of data read/writes on some of the boards,
>> such as
>>> the conditions under which they are interrupted and return early.
>>> There may or may not be good motivation for this, however:
>>> 1) know it WILL break people's existing code
>>> 2) there should be a clear and defensible rationale for the
>> change,
>>> and specification of exactly what the required behavior now is
>>> 3) if the behavior of data reads and writes is to be changed, it
>>> should be changed consistently for all boards
>>> 
>>> Whether the patches are merged is up to Dave, as I am not the
>> primary
>>> maintainer of linux-gpib any more.  However, I feel I should fully
>>> disclose what my position on all this is.  I don't particularly
>> care
>>> about HPDRIVE or AMIGO, etc.  The patches in their current state
>>> introduce finely-tuned behavior in scattered locations for no
>> clear
>>> reason other than they are apparently required to make hpdrive
>> work.
>>> That makes linux-gpib support for hpdrive likely to be broken by
>>> anyone refactoring the code, especially anyone who doesn't have a
>>> strong interest and knowledge of hpdrive and associate protocols,
>> such
>>> as myself.  There are parts of the patches which are just general
>>> improvements and could be cherry picked out, but if all the
>> patches
>>> are merged in anything like their current state, my response will
>> be
>>> to abandon main line linux-gpib completely, and just make a
>> minimally
>>> maintained pre-merge fork for use in my own work.  Maybe this is
>> fine
>>> though, as I haven't done much development on linux-gpib for a
>> long
>>> time, except when I needed to fix something for work.
>>> 
>>> On Wed, May 5, 2021 at 2:21 PM Ansgar Kueckes <an...@hp...>
>> wrote:
>>>> See the files attached.
>>>> 
>>>> The Identify command was some kind of extension to the HP-IB
>> standard.
>>>> HP realized that the HP-IB standard lacked a device
>> identification
>>>> mechanism (comparable to the PCI Device Id). So they implemented
>> a
>>>> special circuit in their HP-IB controllers which worked similar
>> to a
>>>> poll where the addressed device's controller replied with a
>> defined
>>>> two-byte ID. It works by sending an UNT followed by the primary
>> address
>>>> of the queried device as secondary address. However, the
>> mechanism never
>>>> became part of the IEEE standard and was implemented in HP's own
>> HP-IB
>>>> controller chips only.
>>>> 
>>>> The only other chip that can detect and handle the Identify is a
>> nec7210
>>>> by activating secondary addressing and using the UNT as TALK to
>> address
>>>> 31. Which normally is an invalid address, but the nec7210 is
>> implemented
>>>> entering talker state when being configured to 31 as second
>> primary
>>>> address when in dual extended addressing mode. Actually this is a
>> flaw
>>>> in the nec7210 design, but for the sake of compatibility all 7210
>>>> implementations also implement that special behavior.
>>>> 
>>>> -Ansgar
>>>> 
>>>>> Where can I find a description of the AMIGO or CS/80 protocols?
>> Some
>>>>> blurb I found sounded like the AMIGO identify command is UNT
>> followed
>>>>> by MTA, but then said it was implemented by setting the
>> secondary
>>>>> address of a nec7210 to UNT, which would suggest MTA followed by
>> UNT?
>>>>> Anyways I'd like a specific problematic protocol example.
>>>>> 
>>> 
>> 
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] hpdrive changes: dac holdoff

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

HI Frank and Ansgar,
It would be great to get hpdrive working with the stock package, especially
for users who could then benefit from this functionality via the distro's
that ship linux-gpib.
We certainly don't want to break anything so I am all for working through
the issues one by one until we get down to a minimal set of  absolutely
necessary hpdrive conflicts with the current (standard) behaviour.
Then we can try to find a good way to package them to avoid affecting
existing applications. If you agree, may I suggest we start with the
tnt4882 driver with which I can test both my t&m and hpdrive use cases.

-Dave


On Thu, 6 May 2021 at 08:29, Ansgar Kueckes <an...@hp...> wrote:

> Frank,
>
> thanks for the open words.
>
> For me it looks like linux-gpib is mostly designed after NI's ni488 API,
> which is proven for most GPIB applications and probably covers 99.9% of
> all use cases. Which is mostly data exchange with measuring equipment.
> That approach seems to be quite desirable, also because porting existing
> application code to Linux is pretty easy to achieve, since ni488
> represents some kind of industry standard and has been adopted by a
> large number of other chip vendors. My own tools all work out of the box
> with linux-gpib, HPDrive is the single exception. So the cool thing with
> linux-gpib is that all that is available for Linux, too. Which opens up
> a new world for open applications. I understand this is the main outcome
> of your great work.
>
> HPDrive and the other HP tools step into another history of GPIB, that
> of HP, the inventor of the GPIB. They go a bit deeper into what HP
> itself achieved with HP-IB, but the challenges are similar, implementing
> the diverse mechanisms with as many chip designs as possible. I think
> the general question is, stay at ni488 level, or go beyond and implement
> the full IEEE standard, or even support special chip features. I cannot
> answer that question, this is the primary task of the maintainers, who
> define the scope of the project. There are different approaches, CEC for
> instance simply added a general register access function in their (ni488
> based) API. HPDrive uses that function to add the functionality which is
> not provided by ni488 and works fine. But I am not sure whether this is
> the way to go for security reasons.
>
> I see your concerns (1) to (3) and I fully agree. I'd suggest to go with
> you and Dave through those points where existing code will be affected,
> and see whether there is a good way for a standard behavior which fits
> all use cases. In no way should existing applications be affected. If
> that is not possible, we may think about a fork or leave it as it is
> (create patches for new releases). Although the use of GPIB is still
> quite spread, I feel we more and more also have to take into account the
> historic relevance of HP-IB and GPIB. And think about adding the
> historic computing to the uses cases of linux-gpib, not just limited to
> data exchange with vintage measuring & control equipment. And there is
> growing base for this. The story would not be complete without what HP's
> engineering  did with HP-IB/GPIB during the 70s and 80s.
>
> HPDrive in fact is one of the key enabler for everyone who is dealing
> with vintage HP systems. Without it you would be restricted to the real
> mass storage hardware, which is going to fade away. For me linux-gpib is
> a true gift, because most HPDrive users are on Windows and I have a
> personal interest for changing this or at least offering an alternative.
> And of course it would be comfortable not to have to step through all
> changes coming with every new linux-gpib release and do all the testing,
> but it is a quite normal procedure. Whether refactoring is affecting the
> extensions, is probably mainly a matter of documentation.
>
> -Ansgar
>
> > Ok, and the dac holdoff requirement seems to come from AMIGO's need to
> > change the parallel poll response synchronously with reception of
> > certain command bytes.
> >
> > One of the more disturbing aspects of the hpdrive patches is they
> > change the behavior of data read/writes on some of the boards, such as
> > the conditions under which they are interrupted and return early.
> > There may or may not be good motivation for this, however:
> > 1) know it WILL break people's existing code
> > 2) there should be a clear and defensible rationale for the change,
> > and specification of exactly what the required behavior now is
> > 3) if the behavior of data reads and writes is to be changed, it
> > should be changed consistently for all boards
> >
> > Whether the patches are merged is up to Dave, as I am not the primary
> > maintainer of linux-gpib any more.  However, I feel I should fully
> > disclose what my position on all this is.  I don't particularly care
> > about HPDRIVE or AMIGO, etc.  The patches in their current state
> > introduce finely-tuned behavior in scattered locations for no clear
> > reason other than they are apparently required to make hpdrive work.
> > That makes linux-gpib support for hpdrive likely to be broken by
> > anyone refactoring the code, especially anyone who doesn't have a
> > strong interest and knowledge of hpdrive and associate protocols, such
> > as myself.  There are parts of the patches which are just general
> > improvements and could be cherry picked out, but if all the patches
> > are merged in anything like their current state, my response will be
> > to abandon main line linux-gpib completely, and just make a minimally
> > maintained pre-merge fork for use in my own work.  Maybe this is fine
> > though, as I haven't done much development on linux-gpib for a long
> > time, except when I needed to fix something for work.
> >
> > On Wed, May 5, 2021 at 2:21 PM Ansgar Kueckes <an...@hp...> wrote:
> >> See the files attached.
> >>
> >> The Identify command was some kind of extension to the HP-IB standard.
> >> HP realized that the HP-IB standard lacked a device identification
> >> mechanism (comparable to the PCI Device Id). So they implemented a
> >> special circuit in their HP-IB controllers which worked similar to a
> >> poll where the addressed device's controller replied with a defined
> >> two-byte ID. It works by sending an UNT followed by the primary address
> >> of the queried device as secondary address. However, the mechanism never
> >> became part of the IEEE standard and was implemented in HP's own HP-IB
> >> controller chips only.
> >>
> >> The only other chip that can detect and handle the Identify is a nec7210
> >> by activating secondary addressing and using the UNT as TALK to address
> >> 31. Which normally is an invalid address, but the nec7210 is implemented
> >> entering talker state when being configured to 31 as second primary
> >> address when in dual extended addressing mode. Actually this is a flaw
> >> in the nec7210 design, but for the sake of compatibility all 7210
> >> implementations also implement that special behavior.
> >>
> >> -Ansgar
> >>
> >>> Where can I find a description of the AMIGO or CS/80 protocols?  Some
> >>> blurb I found sounded like the AMIGO identify command is UNT followed
> >>> by MTA, but then said it was implemented by setting the secondary
> >>> address of a nec7210 to UNT, which would suggest MTA followed by UNT?
> >>> Anyways I'd like a specific problematic protocol example.
> >>>
> >
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] hpdrive changes: dac holdoff

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

Frank,

thanks for the open words.

For me it looks like linux-gpib is mostly designed after NI's ni488 API, 
which is proven for most GPIB applications and probably covers 99.9% of 
all use cases. Which is mostly data exchange with measuring equipment. 
That approach seems to be quite desirable, also because porting existing 
application code to Linux is pretty easy to achieve, since ni488 
represents some kind of industry standard and has been adopted by a 
large number of other chip vendors. My own tools all work out of the box 
with linux-gpib, HPDrive is the single exception. So the cool thing with 
linux-gpib is that all that is available for Linux, too. Which opens up 
a new world for open applications. I understand this is the main outcome 
of your great work.

HPDrive and the other HP tools step into another history of GPIB, that 
of HP, the inventor of the GPIB. They go a bit deeper into what HP 
itself achieved with HP-IB, but the challenges are similar, implementing 
the diverse mechanisms with as many chip designs as possible. I think 
the general question is, stay at ni488 level, or go beyond and implement 
the full IEEE standard, or even support special chip features. I cannot 
answer that question, this is the primary task of the maintainers, who 
define the scope of the project. There are different approaches, CEC for 
instance simply added a general register access function in their (ni488 
based) API. HPDrive uses that function to add the functionality which is 
not provided by ni488 and works fine. But I am not sure whether this is 
the way to go for security reasons.

I see your concerns (1) to (3) and I fully agree. I'd suggest to go with 
you and Dave through those points where existing code will be affected, 
and see whether there is a good way for a standard behavior which fits 
all use cases. In no way should existing applications be affected. If 
that is not possible, we may think about a fork or leave it as it is 
(create patches for new releases). Although the use of GPIB is still 
quite spread, I feel we more and more also have to take into account the 
historic relevance of HP-IB and GPIB. And think about adding the 
historic computing to the uses cases of linux-gpib, not just limited to 
data exchange with vintage measuring & control equipment. And there is 
growing base for this. The story would not be complete without what HP's 
engineering  did with HP-IB/GPIB during the 70s and 80s.

HPDrive in fact is one of the key enabler for everyone who is dealing 
with vintage HP systems. Without it you would be restricted to the real 
mass storage hardware, which is going to fade away. For me linux-gpib is 
a true gift, because most HPDrive users are on Windows and I have a 
personal interest for changing this or at least offering an alternative. 
And of course it would be comfortable not to have to step through all 
changes coming with every new linux-gpib release and do all the testing, 
but it is a quite normal procedure. Whether refactoring is affecting the 
extensions, is probably mainly a matter of documentation.

-Ansgar

> Ok, and the dac holdoff requirement seems to come from AMIGO's need to
> change the parallel poll response synchronously with reception of
> certain command bytes.
>
> One of the more disturbing aspects of the hpdrive patches is they
> change the behavior of data read/writes on some of the boards, such as
> the conditions under which they are interrupted and return early.
> There may or may not be good motivation for this, however:
> 1) know it WILL break people's existing code
> 2) there should be a clear and defensible rationale for the change,
> and specification of exactly what the required behavior now is
> 3) if the behavior of data reads and writes is to be changed, it
> should be changed consistently for all boards
>
> Whether the patches are merged is up to Dave, as I am not the primary
> maintainer of linux-gpib any more.  However, I feel I should fully
> disclose what my position on all this is.  I don't particularly care
> about HPDRIVE or AMIGO, etc.  The patches in their current state
> introduce finely-tuned behavior in scattered locations for no clear
> reason other than they are apparently required to make hpdrive work.
> That makes linux-gpib support for hpdrive likely to be broken by
> anyone refactoring the code, especially anyone who doesn't have a
> strong interest and knowledge of hpdrive and associate protocols, such
> as myself.  There are parts of the patches which are just general
> improvements and could be cherry picked out, but if all the patches
> are merged in anything like their current state, my response will be
> to abandon main line linux-gpib completely, and just make a minimally
> maintained pre-merge fork for use in my own work.  Maybe this is fine
> though, as I haven't done much development on linux-gpib for a long
> time, except when I needed to fix something for work.
>
> On Wed, May 5, 2021 at 2:21 PM Ansgar Kueckes <an...@hp...> wrote:
>> See the files attached.
>>
>> The Identify command was some kind of extension to the HP-IB standard.
>> HP realized that the HP-IB standard lacked a device identification
>> mechanism (comparable to the PCI Device Id). So they implemented a
>> special circuit in their HP-IB controllers which worked similar to a
>> poll where the addressed device's controller replied with a defined
>> two-byte ID. It works by sending an UNT followed by the primary address
>> of the queried device as secondary address. However, the mechanism never
>> became part of the IEEE standard and was implemented in HP's own HP-IB
>> controller chips only.
>>
>> The only other chip that can detect and handle the Identify is a nec7210
>> by activating secondary addressing and using the UNT as TALK to address
>> 31. Which normally is an invalid address, but the nec7210 is implemented
>> entering talker state when being configured to 31 as second primary
>> address when in dual extended addressing mode. Actually this is a flaw
>> in the nec7210 design, but for the sake of compatibility all 7210
>> implementations also implement that special behavior.
>>
>> -Ansgar
>>
>>> Where can I find a description of the AMIGO or CS/80 protocols?  Some
>>> blurb I found sounded like the AMIGO identify command is UNT followed
>>> by MTA, but then said it was implemented by setting the secondary
>>> address of a nec7210 to UNT, which would suggest MTA followed by UNT?
>>> Anyways I'd like a specific problematic protocol example.
>>>
>

Re: [Linux-gpib-general] hpdrive changes: dac holdoff

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

Ok, and the dac holdoff requirement seems to come from AMIGO's need to
change the parallel poll response synchronously with reception of
certain command bytes.

One of the more disturbing aspects of the hpdrive patches is they
change the behavior of data read/writes on some of the boards, such as
the conditions under which they are interrupted and return early.
There may or may not be good motivation for this, however:
1) know it WILL break people's existing code
2) there should be a clear and defensible rationale for the change,
and specification of exactly what the required behavior now is
3) if the behavior of data reads and writes is to be changed, it
should be changed consistently for all boards

Whether the patches are merged is up to Dave, as I am not the primary
maintainer of linux-gpib any more.  However, I feel I should fully
disclose what my position on all this is.  I don't particularly care
about HPDRIVE or AMIGO, etc.  The patches in their current state
introduce finely-tuned behavior in scattered locations for no clear
reason other than they are apparently required to make hpdrive work.
That makes linux-gpib support for hpdrive likely to be broken by
anyone refactoring the code, especially anyone who doesn't have a
strong interest and knowledge of hpdrive and associate protocols, such
as myself.  There are parts of the patches which are just general
improvements and could be cherry picked out, but if all the patches
are merged in anything like their current state, my response will be
to abandon main line linux-gpib completely, and just make a minimally
maintained pre-merge fork for use in my own work.  Maybe this is fine
though, as I haven't done much development on linux-gpib for a long
time, except when I needed to fix something for work.

On Wed, May 5, 2021 at 2:21 PM Ansgar Kueckes <an...@hp...> wrote:
>
> See the files attached.
>
> The Identify command was some kind of extension to the HP-IB standard.
> HP realized that the HP-IB standard lacked a device identification
> mechanism (comparable to the PCI Device Id). So they implemented a
> special circuit in their HP-IB controllers which worked similar to a
> poll where the addressed device's controller replied with a defined
> two-byte ID. It works by sending an UNT followed by the primary address
> of the queried device as secondary address. However, the mechanism never
> became part of the IEEE standard and was implemented in HP's own HP-IB
> controller chips only.
>
> The only other chip that can detect and handle the Identify is a nec7210
> by activating secondary addressing and using the UNT as TALK to address
> 31. Which normally is an invalid address, but the nec7210 is implemented
> entering talker state when being configured to 31 as second primary
> address when in dual extended addressing mode. Actually this is a flaw
> in the nec7210 design, but for the sake of compatibility all 7210
> implementations also implement that special behavior.
>
> -Ansgar
>
> > Where can I find a description of the AMIGO or CS/80 protocols?  Some
> > blurb I found sounded like the AMIGO identify command is UNT followed
> > by MTA, but then said it was implemented by setting the secondary
> > address of a nec7210 to UNT, which would suggest MTA followed by UNT?
> > Anyways I'd like a specific problematic protocol example.
> >
>


-- 
Frank

Re: [Linux-gpib-general] hpdrive changes: dac holdoff

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

Where can I find a description of the AMIGO or CS/80 protocols?  Some
blurb I found sounded like the AMIGO identify command is UNT followed
by MTA, but then said it was implemented by setting the secondary
address of a nec7210 to UNT, which would suggest MTA followed by UNT?
Anyways I'd like a specific problematic protocol example.

On Wed, May 5, 2021 at 12:52 AM Ansgar Kueckes <an...@hp...> wrote:
>
> Hi Frank,
>
> from the user space I guess it would be cool to merge data & events in a
> logical queue, so that the correct sequence is visible to the
> application. Most applications probably still won't need it because of
> simple transfer schemes, but those who rely on GPIB signalling will take
> advantage out of it.
>
> HP's AMIGO and CS/80 protocols, however, unfortunately mix up HP-IB
> signalling and logical commands (sent as data) for flow control, so
> there is still a need for synchronous use of GPIB commands controlled by
> the application. The GPIB controller FIFOs cannot run fully independent
> of the application, the hold-offs for the source/acceptor handshake
> (which is the best way to pause the FIFOs) still have to be functional
> in order to implement the AMIGO and CS/80 protocols.
>
> -Ansgar
>
>
> > Actually I was confused, thinking of RFD holdoffs rather than DAC
> > holdoffs.  What if linux-gpib maintained a unified input queue
> > combining data bytes and events, in the order they were received?
> > "Events" would be expanded to include unrecognized command bytes
> > (which would include secondary address bytes when the device is
> > primary addressed but not configured to use secondary addressing), and
> > device state changes related to reception of command bytes (like being
> > addressed/unaddressed etc).  Then would you really need to fiddle with
> > low level bus operation (DAC holdoffs) from user space?
> >
> > On Tue, May 4, 2021 at 1:57 AM Ansgar Kueckes <an...@hp...> wrote:
> >> Hi Dave,
> >>
> >> yes, it is true that the hold-off is a bit tricky (not well documented,
> >> different hold-off types & registers to deal with hold-offs, the later
> >> NI ASICs make it even worse, and almost no sample code available), and I
> >> had in fact to do a lot of experimental work on it, so I can agree
> >> Franks concerns.
> >>
> >> However, as it is implemented now it works quite well with hpdrive for a
> >> pretty long time now for all 7210 style controller chips (at least there
> >> was no report yet that it didn't work), and in fact I don't know many
> >> other applications around which make use of the function. For the AMIGO
> >> and CS/80 protocols, the DAC hold-off is an essential part of the
> >> mechanism, and works quite reliably, even under the harsh timing
> >> conditions of those protocols. So I guess we can assume, if it works
> >> with hpdrive, it should work with all others as well.
> >>
> >> Those protocols work asynchronously and send a secondary address from
> >> the controller to the device as command. After receiving the secondary,
> >> each device needs time for preparing itself for the next step (e.g.
> >> transfers to/from media). So the device has to keep the controller off
> >> until it is ready. It does so by activating the DAC hold-off, so that
> >> the controller has to wait on the bus, until the device is ready for the
> >> next steps and releases the hold-off. The controller can now continue
> >> with e.g. sending data to the device.
> >>
> >> Today we would use other mechanisms, because mixing the GPIB features
> >> for the handshakes on device level isn't the best idea of all. Also, the
> >> original purpose of the secondary address is not being used as device
> >> command. But at that time HP-IB was quite new and HP probably was proud
> >> of the elegant design, so made more use of the features than others. I
> >> don't think there are many other applications using GPIB hold-offs.
> >>
> >> Hope this shows a bit how it works. I would be glad to give more insights.
> >>
> >> -Ansgar
> >>
> >>> Hi Dave,
> >>>
> >>> I predict exposing a dac holdoff release function is going to cause
> >>> difficulties.  Every "nec7210 compatible" chip handles dac
> >>> holdoff/release slightly differently and it was a nightmare trying to
> >>> reach some lowest common denominator in the nec7210 driver where no
> >>> bytes would get thrown away and the holdoff would reliably be
> >>> released.
> >>>
> >>> Is there anywhere I could get info on why dac holdoff release control
> >>> is required by hpdrive emulation?  Also, why does it care about
> >>> secondary addressing state?
> >>>
> >
>


--
Frank

[Linux-gpib-general] hpdrive changes: dac holdoff

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

Hi Dave,

I predict exposing a dac holdoff release function is going to cause
difficulties.  Every "nec7210 compatible" chip handles dac
holdoff/release slightly differently and it was a nightmare trying to
reach some lowest common denominator in the nec7210 driver where no
bytes would get thrown away and the holdoff would reliably be
released.

Is there anywhere I could get info on why dac holdoff release control
is required by hpdrive emulation?  Also, why does it care about
secondary addressing state?

-- 
Frank

[Linux-gpib-general] hpdrive changes: parallel poll config

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

Hi Dave,

Why do the new hpdrive changes include new functions and ioctls for
configuring local parallel poll?  A board level ibppc call is already
supposed to do a local parallel poll configuration, when used along
with ibconfig option IbcPP2.

-- 
Frank

Re: [Linux-gpib-general] Patch for linux-gpib GPIO bitbanging driver

[Thomas K. <ele...@gm...>]

Dear Marcello,

you are probably right setting the sn7516x_used flags to on by default.
I wanted to avoid hogging unused GPIO pins, but it is probably better
to have a safe default rather than having to tell every user to use
this obscure module parameter ... I'll document the whole thing
properly on my homepage in the next days.
The led was also a good find, i toggled it as an activity led in my old
code but this makes much more sense!

Thanks!
Thomas

On Sat, 24 Apr 2021 11:52:49 +0200
"marcello carla'" <ca...@fi...> wrote:

> hello,
> 
> Many thanks to Thomas Klima for the latest version of
> the gpib_bitbang driver with the upgrades.
> 
> I suggest two further little adjustments:
> 
> -------------------------------------------------
> diff  gpib_bitbang.c-thomas-latest gpib_bitbang.c
> 73c73
> < static int sn7516x_used=0;
> ---
>  > static int sn7516x_used=1;  
> 784c784
> <         gpiod_direction_output(ACT_LED, 0);
> ---
>  >         gpiod_direction_output(ACT_LED, 1);  
> 816a817
>  >         gpiod_direction_input(ACT_LED);  
> --------------------------------------------------
> 
> The first one sets the use of the SN75160/161 bus drivers
> by default. Everything will work fine in any case, either
> the chips are actually used or the gpib bus is directly
> connected to the Raspberry gpios.
> sn7516x_used=0, instead, leaves the four gpio lines that
> control the bus drivers uncommitted (available for another
> use) and only the direct gpib-gpios connection will work.
> 
> The second one makes the green led on thomas' board light
> when the module is loaded and switch off when unloaded.
> 
> =====================================================
> 
> I have made a test with the gpib lines connected to the
> gpios pins through resistors of 10 (ten) ohm value, with
> four instruments on the bus. Here are the results:
> 
> Line DIO4 (representative of all data lines):
> 
> Low: -9 mA  (the gpio line is sinking current) @ 270 mV
> High: 2 mA
> 
> Line NRFD (representative of all control lines):
> 
> Low: -10 mA @ 280 mV
> High: 1 mA
> 
> According to the numbers, operation of the Raspberry in
> this condition is safe and there is room also for some more
> instrument. I will test and report about this as soon as I
> can.
> 
> Operation with the SN7516x bus drivers though is safer and by
> far more advisable if one is not 100% certain of what can be
> going on his gpib bus.
> 
> Good bye
> 
> Marcello Carla'
> 
> 
> 
> 
> On 4/22/21 3:21 PM, dave penkler wrote:
> > Hi Thomas,
> > Excellent, thank you. Will apply your patch and test builds on the
> > weekend. cheers,
> > -Dave
> > 
> > On Thu, 22 Apr 2021, 13:16 Thomas Klima, <ele...@gm... 
> > <mailto:ele...@gm...>> wrote:
> > 
> >     Hi,
> > 
> >     congratulations on the newest release of linux-gpib - I love
> > that the bitbanging driver is now included in linux-gpib!
> > 
> >     Since 2016 i developed a GPIB-shield for the raspberry pi and a
> >     patch to linux-gpib as driver on my project page
> > (elektronomikon.org <http://elektronomikon.org>).
> > 
> >     Marcello helped me with an interrupt-driven design, and his
> > current version is much more elegant than mine but is missing two
> > features which imho would warrant looking after:
> > 
> >     1, The driver in linux-gpib V4.3.4 is uses the legacy gpio
> > kernel interface which is marked deprecated for some time now. The
> >         raspi_gpib driver uses the GPIO descriptor based interface.
> >     2, My project includes SN75160/161 driver IC's which need three
> >         extra pins and are unused in the upstream driver.
> > 
> >     So i added both changes to the upstream version, which yields
> > the following file:
> >     https://github.com/elektronomikon/raspi_gpib_driver/blob/master/for_linux-gpib-4.3.4/gpib_bitbang.c
> > 
> >     Marcello tested this on his hardware which ran fine.
> > 
> >     The use of SN75160/161 is currently en/disabled via a module
> > parameter, which i think is an acceptable solution. Aa config file
> > switch would be another possibility, but i dont know how to
> > implement this... Any hints are appreciated :-)
> > 
> >     Patch is attached, please apply.
> > 
> >     Greetings,
> >     Thomas Klima
> >     _______________________________________________
> >     Linux-gpib-general mailing list
> >     Lin...@li...
> >     <mailto: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] Patch for linux-gpib GPIO bitbanging driver

[marcello c. <ca...@fi...>]

hello,

Many thanks to Thomas Klima for the latest version of
the gpib_bitbang driver with the upgrades.

I suggest two further little adjustments:

-------------------------------------------------
diff  gpib_bitbang.c-thomas-latest gpib_bitbang.c
73c73
< static int sn7516x_used=0;
---
 > static int sn7516x_used=1;
784c784
<         gpiod_direction_output(ACT_LED, 0);
---
 >         gpiod_direction_output(ACT_LED, 1);
816a817
 >         gpiod_direction_input(ACT_LED);
--------------------------------------------------

The first one sets the use of the SN75160/161 bus drivers
by default. Everything will work fine in any case, either
the chips are actually used or the gpib bus is directly
connected to the Raspberry gpios.
sn7516x_used=0, instead, leaves the four gpio lines that
control the bus drivers uncommitted (available for another
use) and only the direct gpib-gpios connection will work.

The second one makes the green led on thomas' board light
when the module is loaded and switch off when unloaded.

=====================================================

I have made a test with the gpib lines connected to the
gpios pins through resistors of 10 (ten) ohm value, with
four instruments on the bus. Here are the results:

Line DIO4 (representative of all data lines):

Low: -9 mA  (the gpio line is sinking current) @ 270 mV
High: 2 mA

Line NRFD (representative of all control lines):

Low: -10 mA @ 280 mV
High: 1 mA

According to the numbers, operation of the Raspberry in
this condition is safe and there is room also for some more
instrument. I will test and report about this as soon as I
can.

Operation with the SN7516x bus drivers though is safer and by
far more advisable if one is not 100% certain of what can be
going on his gpib bus.

Good bye

Marcello Carla'




On 4/22/21 3:21 PM, dave penkler wrote:
> Hi Thomas,
> Excellent, thank you. Will apply your patch and test builds on the weekend.
> cheers,
> -Dave
> 
> On Thu, 22 Apr 2021, 13:16 Thomas Klima, <ele...@gm... 
> <mailto:ele...@gm...>> wrote:
> 
>     Hi,
> 
>     congratulations on the newest release of linux-gpib - I love that the
>     bitbanging driver is now included in linux-gpib!
> 
>     Since 2016 i developed a GPIB-shield for the raspberry pi and a
>     patch to linux-gpib as driver on my project page (elektronomikon.org
>     <http://elektronomikon.org>).
> 
>     Marcello helped me with an interrupt-driven design, and his current
>     version is much more elegant than mine but is missing two features
>     which imho would warrant looking after:
> 
>     1, The driver in linux-gpib V4.3.4 is uses the legacy gpio kernel
>         interface which is marked deprecated for some time now. The
>         raspi_gpib driver uses the GPIO descriptor based interface.
>     2, My project includes SN75160/161 driver IC's which need three
>         extra pins and are unused in the upstream driver.
> 
>     So i added both changes to the upstream version, which yields the
>     following file:
>     https://github.com/elektronomikon/raspi_gpib_driver/blob/master/for_linux-gpib-4.3.4/gpib_bitbang.c
> 
>     Marcello tested this on his hardware which ran fine.
> 
>     The use of SN75160/161 is currently en/disabled via a module parameter,
>     which i think is an acceptable solution. Aa config file switch would be
>     another possibility, but i dont know how to implement this... Any hints
>     are appreciated :-)
> 
>     Patch is attached, please apply.
> 
>     Greetings,
>     Thomas Klima
>     _______________________________________________
>     Linux-gpib-general mailing list
>     Lin...@li...
>     <mailto: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
> 

-- 
Marcello Carla'
(ca...@fi...)

Re: [Linux-gpib-general] Patch for linux-gpib GPIO bitbanging driver

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

Hi Thomas,
Excellent, thank you. Will apply your patch and test builds on the weekend.
cheers,
-Dave

On Thu, 22 Apr 2021, 13:16 Thomas Klima, <ele...@gm...> wrote:

> Hi,
>
> congratulations on the newest release of linux-gpib - I love that the
> bitbanging driver is now included in linux-gpib!
>
> Since 2016 i developed a GPIB-shield for the raspberry pi and a
> patch to linux-gpib as driver on my project page (elektronomikon.org).
>
> Marcello helped me with an interrupt-driven design, and his current
> version is much more elegant than mine but is missing two features
> which imho would warrant looking after:
>
> 1, The driver in linux-gpib V4.3.4 is uses the legacy gpio kernel
>    interface which is marked deprecated for some time now. The
>    raspi_gpib driver uses the GPIO descriptor based interface.
> 2, My project includes SN75160/161 driver IC's which need three
>    extra pins and are unused in the upstream driver.
>
> So i added both changes to the upstream version, which yields the
> following file:
>
> https://github.com/elektronomikon/raspi_gpib_driver/blob/master/for_linux-gpib-4.3.4/gpib_bitbang.c
>
> Marcello tested this on his hardware which ran fine.
>
> The use of SN75160/161 is currently en/disabled via a module parameter,
> which i think is an acceptable solution. Aa config file switch would be
> another possibility, but i dont know how to implement this... Any hints
> are appreciated :-)
>
> Patch is attached, please apply.
>
> Greetings,
> Thomas Klima
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Patch for linux-gpib GPIO bitbanging driver

[Thomas K. <ele...@gm...>]

Hi,

congratulations on the newest release of linux-gpib - I love that the
bitbanging driver is now included in linux-gpib!

Since 2016 i developed a GPIB-shield for the raspberry pi and a
patch to linux-gpib as driver on my project page (elektronomikon.org).

Marcello helped me with an interrupt-driven design, and his current
version is much more elegant than mine but is missing two features
which imho would warrant looking after:

1, The driver in linux-gpib V4.3.4 is uses the legacy gpio kernel
   interface which is marked deprecated for some time now. The
   raspi_gpib driver uses the GPIO descriptor based interface.
2, My project includes SN75160/161 driver IC's which need three
   extra pins and are unused in the upstream driver.

So i added both changes to the upstream version, which yields the
following file:
https://github.com/elektronomikon/raspi_gpib_driver/blob/master/for_linux-gpib-4.3.4/gpib_bitbang.c

Marcello tested this on his hardware which ran fine.

The use of SN75160/161 is currently en/disabled via a module parameter,
which i think is an acceptable solution. Aa config file switch would be
another possibility, but i dont know how to implement this... Any hints
are appreciated :-)

Patch is attached, please apply.

Greetings,
Thomas Klima

Re: [Linux-gpib-general] Need help with linux-gpib on Raspberry Pi 4

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

Hi Edevaldo,
Everything looks alright. When you did the ./configure did you specify
--sysconfdir=/etc ?
If not, please try gpib_config with your gpib.conf in the default
location /usr/local/etc/gpib.conf or
gpib_config -f /etc/gpib.conf
cheers,
-Dave


On Thu, 25 Mar 2021 at 06:26, Edevaldo Pereira da Silva Junior
<ede...@gm...> wrote:
>
> I tried to install the NI GPIB-USB-HS device and use it on a Raspberry Pi 4. But I cannot get to communicate with devices connected to it.
>
> Compiling and installing linux-gpib seems to have worked well. I didn't see any errors.
> When I connect the device to the Pi and run dmesg I see:
>
> [ 3184.306689] usb 1-1.1: new high-speed USB device number 7 using xhci_hcd
> [ 3184.547108] usb 1-1.1: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 7
> [ 3184.547619] usb 1-1.1: New USB device found, idVendor=3923, idProduct=709b, bcdDevice= 1.01
> [ 3184.547632] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 3184.547645] usb 1-1.1: Product: GPIB-USB-HS
> [ 3184.547657] usb 1-1.1: Manufacturer: National Instruments
> [ 3184.547668] usb 1-1.1: SerialNumber: 0184AC93
> [ 3184.551672] ni_usb_gpib: probe succeeded for path: usb-0000:01:00.0-1.1
>
> Typing lsusb I see:
> Bus 001 Device 007: ID 3923:709b National Instruments Corp. GPIB-USB-HS
>
> And "lsmod | grep gpib" results in:
> ni_usb_gpib            40960  0
> gpib_common            49152  1 ni_usb_gpib
>
> My /etc/gpib.conf looks:
>
> interface {
>     minor       = 0             /* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1 */
>     board_type  = "ni_usb_b"    /* type of interface board being used */
>     name        = "violet"      /* optional name, allows you to get a board descriptor using ibfind() */
>     pad         = 0             /* 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 */
> }
>
> device {
>     minor = 0          /* minor number for interface this device is connected to */
>     pad = 17           /* Primary address */
>     name = "K2000"     /* device mnemonic */
>     sad = 0            /* Secondary address */
>     eos = 0xa          /* EOS byte, 0xa is newline and 0xd is carriage return */
>     set-reos = yes     /* Terminate read if EOS */
>     set-bin = yes      /* Compare EOS 8-bit */
>     set-xeos = no      /* Assert EOI whenever EOS byte is sent */
>     set-eot = yes      /* Assert EOI with last byte on writes */
> }
>
>
> device {
>     minor = 0          /* minor number for interface this device is connected to */
>     pad = 16           /* Primary address */
>     name = "K2001M"    /* device mnemonic */
>     sad = 0            /* Secondary address */
>     eos = 0xa          /* EOS byte, 0xa is newline and 0xd is carriage return */
>     set-reos = yes     /* Terminate read if EOS */
>     set-bin = yes      /* Compare EOS 8-bit */
>     set-xeos = no      /* Assert EOI whenever EOS byte is sent */
>     set-eot = yes      /* Assert EOI with last byte on writes */
> }
>
> But running "sudo gpib_config" results in:
> failed to configure boardtype: ni_pci
> failed to configure board
> main: Invalid argument
>
> If I run something like "sudo gpib_config -t ni_usb_b --sre --ifc" I get no errors.
> And after I run it "sudo ibtest" seems to start but I get get any response from devices on the bus:
> 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]: 16
> trying to open pad = 16 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: *IDN?
> sending string: *IDN?
>
> gpib status is:
> ibsta = 0xc100  < ERR TIMO CMPL >
> iberr= 6
> EABO 6: Operation aborted
>
> ibcntl = 0
>
> Any ideas on what I could try to fix the problem? The GPIB card works ok on windows. I have no other linux machines to test it.
>
> Thanks a lot!
>
> Edevaldo
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Need help with linux-gpib on Raspberry Pi 4

[Edevaldo P. da S. J. <ede...@gm...>]

I tried to install the NI GPIB-USB-HS device and use it on a Raspberry Pi
4. But I cannot get to communicate with devices connected to it.

Compiling and installing linux-gpib seems to have worked well. I didn't see
any errors.
When I connect the device to the Pi and run dmesg I see:








*[ 3184.306689] usb 1-1.1: new high-speed USB device number 7 using
xhci_hcd[ 3184.547108] usb 1-1.1: config 1 interface 0 altsetting 0
endpoint 0x81 has an invalid bInterval 0, changing to 7[ 3184.547619] usb
1-1.1: New USB device found, idVendor=3923, idProduct=709b, bcdDevice=
1.01[ 3184.547632] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3[ 3184.547645] usb 1-1.1: Product: GPIB-USB-HS[ 3184.547657]
usb 1-1.1: Manufacturer: National Instruments[ 3184.547668] usb 1-1.1:
SerialNumber: 0184AC93[ 3184.551672] ni_usb_gpib: probe succeeded for path:
usb-0000:01:00.0-1.1*

Typing lsusb I see:
*Bus 001 Device 007: ID 3923:709b National Instruments Corp. GPIB-USB-HS*

And "lsmod | grep gpib" results in:

*ni_usb_gpib            40960  0gpib_common            49152  1 ni_usb_gpib*

My /etc/gpib.conf looks:







































*interface {    minor       = 0             /* board index, minor = 0 uses
/dev/gpib0, minor = 1 uses /dev/gpib1 */    board_type  = "ni_usb_b"    /*
type of interface board being used */    name        = "violet"      /*
optional name, allows you to get a board descriptor using ibfind() */
pad         = 0             /* 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 */}device {    minor = 0          /*
minor number for interface this device is connected to */    pad = 17
    /* Primary address */    name = "K2000"     /* device mnemonic */
sad = 0            /* Secondary address */    eos = 0xa          /* EOS
byte, 0xa is newline and 0xd is carriage return */    set-reos = yes     /*
Terminate read if EOS */    set-bin = yes      /* Compare EOS 8-bit */
set-xeos = no      /* Assert EOI whenever EOS byte is sent */    set-eot =
yes      /* Assert EOI with last byte on writes */}device {    minor = 0
       /* minor number for interface this device is connected to */    pad
= 16           /* Primary address */    name = "K2001M"    /* device
mnemonic */    sad = 0            /* Secondary address */    eos = 0xa
     /* EOS byte, 0xa is newline and 0xd is carriage return */    set-reos
= yes     /* Terminate read if EOS */    set-bin = yes      /* Compare EOS
8-bit */    set-xeos = no      /* Assert EOI whenever EOS byte is sent */
  set-eot = yes      /* Assert EOI with last byte on writes */}*

But running "sudo gpib_config" results in:


*failed to configure boardtype: ni_pcifailed to configure boardmain:
Invalid argument*

If I run something like "sudo gpib_config -t ni_usb_b --sre --ifc" I get no
errors.
And after I run it "sudo ibtest" seems to start but I get get any response
from devices on the bus:





*Do you wish to open a (d)evice or an interface (b)oard? (you probably want
to open a device): denter primary gpib address for device you wish to open
[0-30]: 16trying to open pad = 16 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)*










*: wenter a string to send to your device: *IDN?sending string: *IDN?gpib
status is: ibsta = 0xc100  < ERR TIMO CMPL >iberr= 6EABO 6: Operation
abortedibcntl = 0*

Any ideas on what I could try to fix the problem? The GPIB card works ok on
windows. I have no other linux machines to test it.

Thanks a lot!

Edevaldo

Re: [Linux-gpib-general] Agilent 82357B Timeout error 14

[Evan F. <eva...@gm...>]

Hi Dave,

Apologies I went to repeat the tests today and run the dmesg check you
wanted. The problem is that I can't reproduce the error now.

Thanks,
Evan

On Fri, Feb 19, 2021 at 3:39 AM dave penkler <dpe...@gm...> wrote:
>
> Hi Evan,
> From what you have sent everything looks correct.
> After you get the timeout error please run the following command and send the output:
> sudo dmesg | grep -i -e gpib -e agilent
> Perhaps we will find a clue there.
> cheers,
> -Dave
>
> On Fri, 19 Feb 2021 at 05:08, Evan Foss <eva...@gm...> wrote:
>>
>> Hi GPIB-List,
>>
>> I am trying to use an Agilent 82357B which I believe is a clone.
>> After using fxload to push the firmware to the device I have this in my lsusb
>> Bus 001 Device 009: ID 0957:0718 Agilent Technologies, Inc.
>>
>> The following is my /etc/gpib.conf
>> interface {
>>     minor = 0
>>     pad = 0
>>     board_type = "agilent_82357a"
>>     name = "violet"
>>     timeout = T100s
>>     master = yes
>> }
>>
>> device {
>>     minor = 0
>>     pad = 10
>>     name = "HP3325B1"
>>     sad = 0
>> }
>>
>> gpib_config runs cleanly but ibtest is problematic. I can talk to the adapter
>> sudo ibtest
>> Do you wish to open a (d)evice or an interface (b)oard?
>>     (you probably want to open a device): b
>> enter name of interface board (or device) you wish to open: violet
>> trying to open board named 'violet'
>> 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)
>> : l
>> DAV off
>> NDAC off
>> NRFD off
>> IFC off
>> REN on
>> SRQ off
>> ATN off
>> EOI off
>> gpib status is:
>> ibsta = 0x120  < CMPL CIC >
>> iberr= 0
>>
>> ibcntl = 0
>>
>> but when I try to talk to the devices, any of them (I have tried
>> others) this is what happens.
>> 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]: 10
>> trying to open pad = 10 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: DISP OFF
>> sending string: DISP OFF
>>
>> gpib status is:
>> ibsta = 0xc100  < ERR TIMO CMPL >
>> iberr= 14
>> EBUS 14: Bus error
>>
>> Would one of you please explain to me what I am doing wrong here?
>>
>> Thanks,
>> Evan
>>
>> --
>> https://github.com/evanfoss
>>
>> -----BEGIN PGP PUBLIC KEY BLOCK-----
>> Version: GnuPG v2
>>
>> mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
>> VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
>> hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
>> JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
>> stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
>> bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
>> cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
>> ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
>> bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
>> tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
>> XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
>> APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
>> 3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
>> qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
>> SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
>> K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
>> A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
>> 5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
>> xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
>> ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
>> Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
>> 0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
>> gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
>> CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
>> fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
>> EY347EidAw==
>> =Ta4p
>> -----END PGP PUBLIC KEY BLOCK-----
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general



-- 
https://github.com/evanfoss

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----

Re: [Linux-gpib-general] Agilent 82357B Timeout error 14

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

Hi Evan,
>From what you have sent everything looks correct.
After you get the timeout error please run the following command and send
the output:
sudo dmesg | grep -i -e gpib -e agilent
Perhaps we will find a clue there.
cheers,
-Dave

On Fri, 19 Feb 2021 at 05:08, Evan Foss <eva...@gm...> wrote:

> Hi GPIB-List,
>
> I am trying to use an Agilent 82357B which I believe is a clone.
> After using fxload to push the firmware to the device I have this in my
> lsusb
> Bus 001 Device 009: ID 0957:0718 Agilent Technologies, Inc.
>
> The following is my /etc/gpib.conf
> interface {
>     minor = 0
>     pad = 0
>     board_type = "agilent_82357a"
>     name = "violet"
>     timeout = T100s
>     master = yes
> }
>
> device {
>     minor = 0
>     pad = 10
>     name = "HP3325B1"
>     sad = 0
> }
>
> gpib_config runs cleanly but ibtest is problematic. I can talk to the
> adapter
> sudo ibtest
> Do you wish to open a (d)evice or an interface (b)oard?
>     (you probably want to open a device): b
> enter name of interface board (or device) you wish to open: violet
> trying to open board named 'violet'
> 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)
> : l
> DAV off
> NDAC off
> NRFD off
> IFC off
> REN on
> SRQ off
> ATN off
> EOI off
> gpib status is:
> ibsta = 0x120  < CMPL CIC >
> iberr= 0
>
> ibcntl = 0
>
> but when I try to talk to the devices, any of them (I have tried
> others) this is what happens.
> 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]: 10
> trying to open pad = 10 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: DISP OFF
> sending string: DISP OFF
>
> gpib status is:
> ibsta = 0xc100  < ERR TIMO CMPL >
> iberr= 14
> EBUS 14: Bus error
>
> Would one of you please explain to me what I am doing wrong here?
>
> Thanks,
> Evan
>
> --
> https://github.com/evanfoss
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v2
>
> mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
> VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
> hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
> JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
> stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
> bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
> cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
> ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
> bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
> tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
> XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
> APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
> 3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
> qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
> SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
> K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
> A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
> 5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
> xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
> ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
> Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
> 0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
> gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
> CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
> fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
> EY347EidAw==
> =Ta4p
> -----END PGP PUBLIC KEY BLOCK-----
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Agilent 82357B Timeout error 14

[Evan F. <eva...@gm...>]

Hi GPIB-List,

I am trying to use an Agilent 82357B which I believe is a clone.
After using fxload to push the firmware to the device I have this in my lsusb
Bus 001 Device 009: ID 0957:0718 Agilent Technologies, Inc.

The following is my /etc/gpib.conf
interface {
    minor = 0
    pad = 0
    board_type = "agilent_82357a"
    name = "violet"
    timeout = T100s
    master = yes
}

device {
    minor = 0
    pad = 10
    name = "HP3325B1"
    sad = 0
}

gpib_config runs cleanly but ibtest is problematic. I can talk to the adapter
sudo ibtest
Do you wish to open a (d)evice or an interface (b)oard?
    (you probably want to open a device): b
enter name of interface board (or device) you wish to open: violet
trying to open board named 'violet'
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)
: l
DAV off
NDAC off
NRFD off
IFC off
REN on
SRQ off
ATN off
EOI off
gpib status is:
ibsta = 0x120  < CMPL CIC >
iberr= 0

ibcntl = 0

but when I try to talk to the devices, any of them (I have tried
others) this is what happens.
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]: 10
trying to open pad = 10 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: DISP OFF
sending string: DISP OFF

gpib status is:
ibsta = 0xc100  < ERR TIMO CMPL >
iberr= 14
EBUS 14: Bus error

Would one of you please explain to me what I am doing wrong here?

Thanks,
Evan

-- 
https://github.com/evanfoss

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----

Re: [Linux-gpib-general] Python3 library not found

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

On my system:
>>> import sys
>>> sys.path.append('/usr/local/lib64/python3.9/site-packages')
>>> import gpib
>>> gpib.version()
b'4.3.4-rc1'
>>>


On Thu, 31 Dec 2020 at 01:42, Roel Jordans <r.j...@sc...> wrote:
>
> I'm not sure what you're missing in your setup.
>
> I've been using linux-gpib together with pyvisa-py and skipped the
> supplied python gpib library.  That works well enough for my purposes
> (not sure what I may be missing out on though).  I remember also trying
> the gpib library but am not sure anymore what made me use the
> alternative.
>
> Cheers,
>  Roel
>
>
> -----Original Message-----
> From: Michael K via Linux-gpib-general <
> lin...@li...>
> Reply-To: Michael K <vk...@ya...>
> To: lin...@li... <
> lin...@li...>
> Subject: [Linux-gpib-general] Python3 library not found
> Date: Wed, 30 Dec 2020 23:13:37 +0000 (UTC)
>
> I've installed the linux-gpib (user and kernel) package and can
> communicate with devices with ibtest and ibterm but cannot get python
> to find the library.
>
> I see that Python files are installed but when I "import gpib" I get a
> complaint...
>
> /usr/lib/python3.7/site-packages/gpib-1.0-py3.7.egg-info
> /usr/lib/python3.7/site-packages/gpib.cpython-37m-aarch64-linux-gnu.so
>
> michael@schrodinger:~/GPIB $ python3
> Python 3.7.3 (default, Jul 25 2020, 13:03:44)
> [GCC 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import gpib
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ModuleNotFoundError: No module named 'gpib'
> >>>
>
> What am I missing ?
>
> Michael
>
> _______________________________________________
> 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] Python3 library not found

[Roel J. <r.j...@sc...>]

I'm not sure what you're missing in your setup.

I've been using linux-gpib together with pyvisa-py and skipped the
supplied python gpib library.  That works well enough for my purposes
(not sure what I may be missing out on though).  I remember also trying
the gpib library but am not sure anymore what made me use the
alternative.

Cheers,
 Roel


-----Original Message-----
From: Michael K via Linux-gpib-general <
lin...@li...>
Reply-To: Michael K <vk...@ya...>
To: lin...@li... <
lin...@li...>
Subject: [Linux-gpib-general] Python3 library not found
Date: Wed, 30 Dec 2020 23:13:37 +0000 (UTC)

I've installed the linux-gpib (user and kernel) package and can
communicate with devices with ibtest and ibterm but cannot get python
to find the library.

I see that Python files are installed but when I "import gpib" I get a
complaint...

/usr/lib/python3.7/site-packages/gpib-1.0-py3.7.egg-info
/usr/lib/python3.7/site-packages/gpib.cpython-37m-aarch64-linux-gnu.so

michael@schrodinger:~/GPIB $ python3
Python 3.7.3 (default, Jul 25 2020, 13:03:44) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gpib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'gpib'
>>> 

What am I missing ?

Michael

_______________________________________________
Linux-gpib-general mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Python3 library not found

[Michael K <vk...@ya...>]

I've installed the linux-gpib (user and kernel) package and can communicate with devices with ibtest and ibterm but cannot get python to find the library.
I see that Python files are installed but when I "import gpib" I get a complaint...
/usr/lib/python3.7/site-packages/gpib-1.0-py3.7.egg-info/usr/lib/python3.7/site-packages/gpib.cpython-37m-aarch64-linux-gnu.so
michael@schrodinger:~/GPIB $ python3
Python 3.7.3 (default, Jul 25 2020, 13:03:44) [GCC 8.3.0] on linuxType "help", "copyright", "credits" or "license" for more information.>>> import gpibTraceback (most recent call last):  File "<stdin>", line 1, in <module>ModuleNotFoundError: No module named 'gpib'>>> 
What am I missing ?
Michael

[Linux-gpib-general] 4.3.4-rc1 package posted

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

Hi,
A new package generated from the latest svn [r1945] has been posted for testing.
https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/4.3.4/
cheers,
-Dave

Re: [Linux-gpib-general] PCMCIA issue on kernel 5.4.0-54-generic (Linux Mint 19.3)

[Mitchell C. <mo....@gm...>]

Dave,

Worked like a charm, thanks.

Mitchell

On Mon, Nov 30, 2020 at 2:32 AM dave penkler <dpe...@gm...> wrote:

> Hi Mitchell,
> Looks like a registration issue. The fix below seems to work.
>
> Please add the following line after line number 260 in tnt4882_cs.c and
> rebuild:  make clean; make ENABLE_PCMCIA=1; sudo make install; sudo
> modprobe tnt4882
> .*name = "ni_gpib_cs",*
>
> The first lines of the struct should look like this:
>
>
>
>
>
>
> *static struct pcmcia_driver ni_gpib_cs_driver ={ .name           =
> "ni_gpib_cs", .owner = THIS_MODULE,....*
>
> *};*
> Let me know if it works for you.
> cheers,
> -Dave
>
> On Mon, 30 Nov 2020 at 01:45, Mitchell Clement <mo....@gm...>
> wrote:
>
>> Hi,
>>
>> I am trying to build the linux-gpib kernel module with PCMCIA enabled for
>> Linux Mint 19.3 with kernel 5.4.0-54-generic, with a National Instruments
>> PCMCIA-GPIB card. When I try to modprobe the tnt4882 driver into the
>> kernel, I get:
>> $ sudo modprobe -fvv tnt4882
>> modprobe: INFO: ../libkmod/libkmod.c:364 kmod_set_log_fn() custom logging
>> function 0x55eae3517750 registered
>> insmod /lib/modules/5.4.0-54-generic/gpib/tnt4882/tnt4882.ko
>> modprobe: INFO: ../libkmod/libkmod-module.c:886
>> kmod_module_insert_module() Failed to insert module
>> '/lib/modules/5.4.0-54-generic/gpib/tnt4882/tnt4882.ko': Exec format error
>> modprobe: ERROR: could not insert 'tnt4882': Exec format error
>> modprobe: INFO: ../libkmod/libkmod.c:331 kmod_unref() context
>> 0x55eae482e420 released
>>
>> with dmesg output:
>> $ dmesg | tail
>> [ 7116.877246] gpib: registered ni_isa_accel interface
>> [ 7116.877247] gpib: registered ni_nat4882_isa interface
>> [ 7116.877248] gpib: registered ni_nat4882_isa_accel interface
>> [ 7116.877249] gpib: registered ni_nec_isa interface
>> [ 7116.877250] gpib: registered ni_nec_isa_accel interface
>> [ 7116.877250] gpib: registered ni_pci interface
>> [ 7116.877251] gpib: registered ni_pci_accel interface
>> [ 7116.877252] gpib: registered ni_pcmcia interface
>> [ 7116.877253] gpib: registered ni_pcmcia_accel interface
>> [ 7116.877256] kobject: can not set name properly!
>>
>> I don't think this is an issue of compiling against an incomplete symbol
>> table, as the gpib_common and nec7210 drivers are in my kernel:
>> $ lsmod | grep nec7210
>> nec7210                24576  0
>> gpib_common            45056  1 nec7210
>>
>> and so is the pcmcia driver:
>> $ lsmod | grep pcmcia
>> pcmcia                 65536  0
>> pcmcia_rsrc            24576  1 yenta_socket
>> pcmcia_core            28672  3 pcmcia,pcmcia_rsrc,yenta_socket
>>
>> I have no issues inserting tnt4882 into the kernel if I build it without
>> PCMCIA enabled (i.e. make ENABLE_PCMCIA=0). Does anyone have any idea what
>> is going on? Thanks.
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>