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

Re: [Linux-gpib-general] (no subject)

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

On Wed, Nov 6, 2019 at 10:20 AM Mike King <mk...@gm...> wrote:
>
> Does anyone know the base memory address of the Agilent 82335 HPIB card or know of a solution to my problem?
> _______________________________________________

Read the file linux-gpib-user/README.hp82355 it describes the base
address and interrupt switches of the card.

-- 
Frank

[Linux-gpib-general] (no subject)

[Mike K. <mk...@gm...>]

Hello Linux GPIB mailing list,

I have a strange question.  I have an old piece of equipment (HP 3048A)
that runs MSDOS and uses an Agilent 82335 HPIB card.  I am trying to
upgrade the PC so I can use a modern operating system.  The DOS program
that operates the equipment writes directly to the card.  I am hoping to
found out the base memory address of the card so that I can modify DOSBOX
to intercept the reads and writes to and from the memory of the card.  The
card uses the TMS9914A HPIB chip.

Does anyone know the base memory address of the Agilent 82335 HPIB card or
know of a solution to my problem?

Re: [Linux-gpib-general] Dockerize Python Application

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

I would expect that you can get this working with docker's --device 
option, haven't tried this myself though.

Cheers,

  Roel

On 28-10-19 23:11, John Gooding wrote:
> I am using a NI GPIB ENET 1000 device with NI linux drivers and the pyvisa library with python to talk to my instruments. It works great, however I would like to dockerize it, but I don't know what files or resources to give docker access to so that pyvisa can find the GPIB instruments inside docker. I do not see anything gpib related in the /dev/ directory. The people over at pyvisa suggested this mailing list might know. Thank you.
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Dockerize Python Application

[John G. <ja....@gm...>]

I am using a NI GPIB ENET 1000 device with NI linux drivers and the pyvisa library with python to talk to my instruments. It works great, however I would like to dockerize it, but I don't know what files or resources to give docker access to so that pyvisa can find the GPIB instruments inside docker. I do not see anything gpib related in the /dev/ directory. The people over at pyvisa suggested this mailing list might know. Thank you.

Re: [Linux-gpib-general] Configure NI GPIB-USB-HS based on serial number

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

On Fri, Sep 20, 2019 at 11:08 AM dave penkler <dpe...@gm...> wrote:
> Syntactically your files look fine so in principle it should work. Please send the output of sudo grep gpib /var/log/messages after booting with the three adaptors plugged in.

I think the problem is we need to use ACTION="add|change" in
98-gpib-generic.rules, since gpib_config will get run on a change
event for the case when the modules aren't already loaded.

-- 
Frank

Re: [Linux-gpib-general] Configure NI GPIB-USB-HS based on serial number

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

Hi Ron,
Syntactically your files look fine so in principle it should work. Please
send the output of sudo grep gpib /var/log/messages after booting with the
three adaptors plugged in.
cheers,
-Dave

On Fri, 20 Sep 2019 at 16:46, <ron...@uf...> wrote:

> Greetings,
>
> I have multiple NI GPIB-USB-HS controllers that I need to use (Ubuntu
> 18.04 LTS, linux-gpib-4.3.0). I've attached my /etc/gpib.conf and
> /etc/udev/rules.d/98-gpib-generic.rules files to show what I currently have
> on my system. I was hoping to have a specific serial number controller
> assigned to a specific /dev/gpib port. Instead, what I am seeing is that
> the first controller that I plug in gets assigned to /dev/gpib0 and the
> second gets assigned to /dev/gpib1. So, either I am doing something wrong,
> or I totally misunderstand the idea of configuring the devices based on
> their serial numbers.
>
> FYI, whenever I've made edits to the config files, I reboot the computer
> to ensure that everything starts fresh. I am hoping that someone can assist
> me with this issue. Is it possible to use the serial numbers to assign a
> controller to a specified /dev/gpib port?
>
> Regards,
>
> Ron
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Configure NI GPIB-USB-HS based on serial number

[<ron...@uf...>]

Greetings, 

I have multiple NI GPIB-USB-HS controllers that I need to use (Ubuntu
18.04 LTS, linux-gpib-4.3.0). I've attached my /etc/gpib.conf and
/etc/udev/rules.d/98-gpib-generic.rules files to show what I currently
have on my system. I was hoping to have a specific serial number
controller assigned to a specific /dev/gpib port. Instead, what I am
seeing is that the first controller that I plug in gets assigned to
/dev/gpib0 and the second gets assigned to /dev/gpib1. So, either I am
doing something wrong, or I totally misunderstand the idea of
configuring the devices based on their serial numbers. 

FYI, whenever I've made edits to the config files, I reboot the computer
to ensure that everything starts fresh. I am hoping that someone can
assist me with this issue. Is it possible to use the serial numbers to
assign a controller to a specified /dev/gpib port? 

Regards, 

Ron

Re: [Linux-gpib-general] linux-gpib-4.3.0 on Ubuntu 18..04 LTS with multiple NI-GPIB-HS (help please)

[Rob L. <ro...@pd...>]

Hi,

For your information, this was my issue:

My libgpib stuff is located in /usr/local/lib and file 
/etc/ld.so.conf.d/libc.conf was available and refers to /usr/local/lib, 
but I did not run ldconfig and logout/login!


Greetings,

Rob Lassche


On 9/17/19 2:37 PM, ron...@uf... wrote:
>
> Dave and Roel,
>
> Thank you very much for your quick and informative responses.
>
> Dave: I ran the lsmod | grep gpib command, and didn't see anything.
>
> Roel: In conjunction with Dave's response about looking at the console 
> log, and your keying in on the depmod issue, I paid better attention 
> when I ran the sudo make install command on the linux-kernel stuff. I 
> missed an important error about a missing System.map file
>
> After poking around a bit, I found out I had the two following 
> directories:
>
> /usr/src/linux-headers-5.0.0-27 and 
> /usr/src/linux-headers-5.0.0-27-generic
>
> The first one had a symbolic link from System.map back to 
> /boot/System.map-5.0.0-27-generic, while the second directory did not. 
> So, not really knowing if it would work, I created the symbolic link 
> in the /usr/src/linux-headers-5.0.0-27-generic directory.
>
> I then did the make, sudo make install on the linux-gpib-kernel stuff 
> and that error went away.  I now get the following when I run the 
> lsmod command
>
> lsmod | grep gpib
> ni_usb_gpib 36864 1
> gpib_common 45056 3 ni_usb_gpib
>
> I have edited the 98-gpib-generic.rules file for the two different 
> NI-USB-HS devices that I have based on serial number, and when I watch 
> the logs they are attaching to the correct bus interfaces (0 or 1 
> depending on the serial number).
>
> From what I can tell, things appear to be working. I wouldn't have 
> reached this step without your assistance. Thank you!
>
> Ron
>
> On 2019-09-17 06:37, Roel Jordans wrote:
>
>> Hi Ron
>>
>> If your modules are missing see if it helps to run depmod as root 
>> again.  I've seen some cases where the module dependency list of the 
>> kernel wasn't properly updated on Ubuntu 18.04 after an install which 
>> resulted in it not being able to load the modules.
>>
>> Cheers,
>>
>>  Roel
>>
>> On 17-09-19 11:33, dave penkler wrote:
>>> Hi Ron,
>>> Your build steps look fine.
>>> To see whether the udev scripts are being run: sudo grep gpib 
>>> /var/log/messages
>>> If you do:lsmod | grep gpib
>>> do you see the modules gpib_common and ni_usb_gpib ?
>>> If not there was probably an issue with the build of the kernel 
>>> modules in which case please send the kernel module build console log.
>>> cheers,
>>> -Dave
>>>
>>> On Tue, 17 Sep 2019 at 08:35, <ron...@uf... 
>>> <mailto:ron...@uf...>> wrote:
>>>
>>>     Greetings,
>>>
>>>     My apologies in advance for asking a general question. I'm
>>>     struggling with installing linux-gpib-4.3.0 on Ubuntu-18.04LTS
>>>     and getting a single NI-GPIB-HS controller to work (and I need
>>>     to run two at the same time). Has anyone had success doing this?
>>>     If so, I'm hoping you can help me figure out what I'm doing wrong.
>>>
>>>     I've had linux-gpib-4.2.0 running in the past on Ubuntu 16.04
>>>     LTS with a single NI-GPIB-HS, but it has been a long time since
>>>     I set that up, and my notes of that installation process aren't
>>>     the best.
>>>
>>>     The general outline of what I have done for this 4.3.0 attempt is:
>>>
>>>     1) tar -zxvf linux-gpib-4.3.0.tar.gz, and then changed to the
>>>     created directory and performed similar tar operation for the
>>>     kernel and user files
>>>
>>>     2) in the kernel directory: make followed by sudo make install.
>>>     I saw something on the output about SSL errors, but things were
>>>     created in the /lib/modules/kernel_version/gpib directory so I
>>>     thought I was okay. Maybe that is a false assumption
>>>
>>>     3) in the user directory: ./configure --sysconfdir=/etc then
>>>     make followed by sudo make install
>>>
>>>     4) created the gpib group and added myself to that group
>>>
>>>     5) Edited the contents of the 98-gpib-generic.rules file to set
>>>     the serial number for the first NI-GPIB-HS controller
>>>
>>>     6) rebooted the computer
>>>
>>>     I've tried the gpib_config command with the NI-GPIB-HS plugged
>>>     in, and I get the following: failed to open device file '/dev/gpib0'
>>>     main: No such file or directory
>>>
>>>     I've tried using "udevadm monitor -e"  and I can see when the
>>>     device gets plugged in, but I'm not sure what I should be seeing
>>>     that shows me that the udev rules were processed correctly.
>>>
>>>     Any suggestions on how to further diagnose what I've done wrong
>>>     are greatly appreciated. If attachments are allowed, I will
>>>     gladly send the contents of the configuration files and the
>>>     captured output from my attempt at monitoring udev.
>>>
>>>     Regards,
>>>
>>>     Ron
>>>
>>>
>>>     _______________________________________________
>>>     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
>>
>> _______________________________________________
>> 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] linux-gpib-4.3.0 on Ubuntu 18..04 LTS with multiple NI-GPIB-HS (help please)

[<ron...@uf...>]

Dave and Roel, 

Thank you very much for your quick and informative responses. 

Dave: I ran the lsmod | grep gpib command, and didn't see anything. 

Roel: In conjunction with Dave's response about looking at the console
log, and your keying in on the depmod issue, I paid better attention
when I ran the sudo make install command on the linux-kernel stuff. I
missed an important error about a missing System.map file 

After poking around a bit, I found out I had the two following
directories: 

/usr/src/linux-headers-5.0.0-27 and
/usr/src/linux-headers-5.0.0-27-generic 

The first one had a symbolic link from System.map back to
/boot/System.map-5.0.0-27-generic, while the second directory did not.
So, not really knowing if it would work, I created the symbolic link in
the /usr/src/linux-headers-5.0.0-27-generic directory. 

I then did the make, sudo make install on the linux-gpib-kernel stuff
and that error went away.  I now get the following when I run the lsmod
command 

lsmod | grep gpib
ni_usb_gpib 36864 1
gpib_common 45056 3 ni_usb_gpib

I have edited the 98-gpib-generic.rules file for the two different
NI-USB-HS devices that I have based on serial number, and when I watch
the logs they are attaching to the correct bus interfaces (0 or 1
depending on the serial number). 

>From what I can tell, things appear to be working. I wouldn't have
reached this step without your assistance. Thank you! 

Ron 

On 2019-09-17 06:37, Roel Jordans wrote:

> Hi Ron 
> 
> If your modules are missing see if it helps to run depmod as root again.  I've seen some cases where the module dependency list of the kernel wasn't properly updated on Ubuntu 18.04 after an install which resulted in it not being able to load the modules. 
> 
> Cheers, 
> 
> Roel
> 
> On 17-09-19 11:33, dave penkler wrote: 
> Hi Ron, 
> Your build steps look fine.
> To see whether the udev scripts are being run: sudo grep gpib /var/log/messages  If you do: lsmod | grep gpib 
> do you see the modules gpib_common and ni_usb_gpib ? 
> If not there was probably an issue with the build of the kernel modules in which case please send the kernel module build console log. 
> cheers, 
> -Dave 
> 
> On Tue, 17 Sep 2019 at 08:35, <ron...@uf...> wrote: 
> 
> Greetings, 
> 
> My apologies in advance for asking a general question. I'm struggling with installing linux-gpib-4.3.0 on Ubuntu-18.04LTS and getting a single NI-GPIB-HS controller to work (and I need to run two at the same time). Has anyone had success doing this? If so, I'm hoping you can help me figure out what I'm doing wrong. 
> 
> I've had linux-gpib-4.2.0 running in the past on Ubuntu 16.04 LTS with a single NI-GPIB-HS, but it has been a long time since I set that up, and my notes of that installation process aren't the best. 
> 
> The general outline of what I have done for this 4.3.0 attempt is: 
> 
> 1) tar -zxvf linux-gpib-4.3.0.tar.gz, and then changed to the created directory and performed similar tar operation for the kernel and user files 
> 
> 2) in the kernel directory: make followed by sudo make install. I saw something on the output about SSL errors, but things were created in the /lib/modules/kernel_version/gpib directory so I thought I was okay. Maybe that is a false assumption 
> 
> 3) in the user directory: ./configure --sysconfdir=/etc then make followed by sudo make install 
> 
> 4) created the gpib group and added myself to that group 
> 
> 5) Edited the contents of the 98-gpib-generic.rules file to set the serial number for the first NI-GPIB-HS controller 
> 
> 6) rebooted the computer 
> 
> I've tried the gpib_config command with the NI-GPIB-HS plugged in, and I get the following: failed to open device file '/dev/gpib0'
> main: No such file or directory 
> 
> I've tried using "udevadm monitor -e"  and I can see when the device gets plugged in, but I'm not sure what I should be seeing that shows me that the udev rules were processed correctly. 
> 
> Any suggestions on how to further diagnose what I've done wrong are greatly appreciated. If attachments are allowed, I will gladly send the contents of the configuration files and the captured output from my attempt at monitoring udev. 
> 
> Regards, 
> 
> Ron 
> 
> _______________________________________________
> 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

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

Re: [Linux-gpib-general] linux-gpib-4.3.0 on Ubuntu 18..04 LTS with multiple NI-GPIB-HS (help please)

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

Hi Ron

If your modules are missing see if it helps to run depmod as root 
again.  I've seen some cases where the module dependency list of the 
kernel wasn't properly updated on Ubuntu 18.04 after an install which 
resulted in it not being able to load the modules.

Cheers,

  Roel

On 17-09-19 11:33, dave penkler wrote:
> Hi Ron,
> Your build steps look fine.
> To see whether the udev scripts are being run: sudo grep gpib 
> /var/log/messages
> If you do:lsmod | grep gpib
> do you see the modules gpib_common and ni_usb_gpib ?
> If not there was probably an issue with the build of the kernel 
> modules in which case please send the kernel module build console log.
> cheers,
> -Dave
>
> On Tue, 17 Sep 2019 at 08:35, <ron...@uf... 
> <mailto:ron...@uf...>> wrote:
>
>     Greetings,
>
>     My apologies in advance for asking a general question. I'm
>     struggling with installing linux-gpib-4.3.0 on Ubuntu-18.04LTS and
>     getting a single NI-GPIB-HS controller to work (and I need to run
>     two at the same time). Has anyone had success doing this? If so,
>     I'm hoping you can help me figure out what I'm doing wrong.
>
>     I've had linux-gpib-4.2.0 running in the past on Ubuntu 16.04 LTS
>     with a single NI-GPIB-HS, but it has been a long time since I set
>     that up, and my notes of that installation process aren't the best.
>
>     The general outline of what I have done for this 4.3.0 attempt is:
>
>     1) tar -zxvf linux-gpib-4.3.0.tar.gz, and then changed to the
>     created directory and performed similar tar operation for the
>     kernel and user files
>
>     2) in the kernel directory: make followed by sudo make install. I
>     saw something on the output about SSL errors, but things were
>     created in the /lib/modules/kernel_version/gpib directory so I
>     thought I was okay. Maybe that is a false assumption
>
>     3) in the user directory: ./configure --sysconfdir=/etc then make
>     followed by sudo make install
>
>     4) created the gpib group and added myself to that group
>
>     5) Edited the contents of the 98-gpib-generic.rules file to set
>     the serial number for the first NI-GPIB-HS controller
>
>     6) rebooted the computer
>
>     I've tried the gpib_config command with the NI-GPIB-HS plugged in,
>     and I get the following: failed to open device file '/dev/gpib0'
>     main: No such file or directory
>
>     I've tried using "udevadm monitor -e"  and I can see when the
>     device gets plugged in, but I'm not sure what I should be seeing
>     that shows me that the udev rules were processed correctly.
>
>     Any suggestions on how to further diagnose what I've done wrong
>     are greatly appreciated. If attachments are allowed, I will gladly
>     send the contents of the configuration files and the captured
>     output from my attempt at monitoring udev.
>
>     Regards,
>
>     Ron
>
>
>     _______________________________________________
>     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] linux-gpib-4.3.0 on Ubuntu 18..04 LTS with multiple NI-GPIB-HS (help please)

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

Hi Ron,
Your build steps look fine.
To see whether the udev scripts are being run: sudo grep gpib
/var/log/messages
If you do: lsmod | grep gpib
do you see the modules gpib_common and ni_usb_gpib ?
If not there was probably an issue with the build of the kernel modules in
which case please send the kernel module build console log.
cheers,
-Dave

On Tue, 17 Sep 2019 at 08:35, <ron...@uf...> wrote:

> Greetings,
>
> My apologies in advance for asking a general question. I'm struggling with
> installing linux-gpib-4.3.0 on Ubuntu-18.04LTS and getting a single
> NI-GPIB-HS controller to work (and I need to run two at the same time). Has
> anyone had success doing this? If so, I'm hoping you can help me figure out
> what I'm doing wrong.
>
> I've had linux-gpib-4.2.0 running in the past on Ubuntu 16.04 LTS with a
> single NI-GPIB-HS, but it has been a long time since I set that up, and my
> notes of that installation process aren't the best.
>
> The general outline of what I have done for this 4.3.0 attempt is:
>
> 1) tar -zxvf linux-gpib-4.3.0.tar.gz, and then changed to the created
> directory and performed similar tar operation for the kernel and user files
>
> 2) in the kernel directory: make followed by sudo make install. I saw
> something on the output about SSL errors, but things were created in the
> /lib/modules/kernel_version/gpib directory so I thought I was okay. Maybe
> that is a false assumption
>
> 3) in the user directory: ./configure --sysconfdir=/etc then make followed
> by sudo make install
>
> 4) created the gpib group and added myself to that group
>
> 5) Edited the contents of the 98-gpib-generic.rules file to set the serial
> number for the first NI-GPIB-HS controller
>
> 6) rebooted the computer
>
> I've tried the gpib_config command with the NI-GPIB-HS plugged in, and I
> get the following: failed to open device file '/dev/gpib0'
> main: No such file or directory
>
> I've tried using "udevadm monitor -e"  and I can see when the device gets
> plugged in, but I'm not sure what I should be seeing that shows me that the
> udev rules were processed correctly.
>
> Any suggestions on how to further diagnose what I've done wrong are
> greatly appreciated. If attachments are allowed, I will gladly send the
> contents of the configuration files and the captured output from my attempt
> at monitoring udev.
>
> Regards,
>
> Ron
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] linux-gpib-4.3.0 on Ubuntu 18..04 LTS with multiple NI-GPIB-HS (help please)

[<ron...@uf...>]

Greetings, 

My apologies in advance for asking a general question. I'm struggling
with installing linux-gpib-4.3.0 on Ubuntu-18.04LTS and getting a single
NI-GPIB-HS controller to work (and I need to run two at the same time).
Has anyone had success doing this? If so, I'm hoping you can help me
figure out what I'm doing wrong. 

I've had linux-gpib-4.2.0 running in the past on Ubuntu 16.04 LTS with a
single NI-GPIB-HS, but it has been a long time since I set that up, and
my notes of that installation process aren't the best. 

The general outline of what I have done for this 4.3.0 attempt is: 

1) tar -zxvf linux-gpib-4.3.0.tar.gz, and then changed to the created
directory and performed similar tar operation for the kernel and user
files 

2) in the kernel directory: make followed by sudo make install. I saw
something on the output about SSL errors, but things were created in the
/lib/modules/kernel_version/gpib directory so I thought I was okay.
Maybe that is a false assumption 

3) in the user directory: ./configure --sysconfdir=/etc then make
followed by sudo make install 

4) created the gpib group and added myself to that group 

5) Edited the contents of the 98-gpib-generic.rules file to set the
serial number for the first NI-GPIB-HS controller 

6) rebooted the computer 

I've tried the gpib_config command with the NI-GPIB-HS plugged in, and I
get the following: failed to open device file '/dev/gpib0'
main: No such file or directory 

I've tried using "udevadm monitor -e"  and I can see when the device
gets plugged in, but I'm not sure what I should be seeing that shows me
that the udev rules were processed correctly. 

Any suggestions on how to further diagnose what I've done wrong are
greatly appreciated. If attachments are allowed, I will gladly send the
contents of the configuration files and the captured output from my
attempt at monitoring udev. 

Regards, 

Ron

[Linux-gpib-general] linux-gpib-4.3.0 release available on sourceforge

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

It is available as the default download on SF or you can get it directly
here
<https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/4.3.0/linux-gpib-4.3.0.tar.gz>
.

Release notes:
Changes since the linux-gpib-4.2.0 release - Removed kernel package build
dependency on autoconf. It now only uses a Makefile and the standard linux
kernel build tool chain. See the installation instructions in
linux-gpib-kernel-4.3.0/INSTALL - Noted in docs that gpib.conf will be in
the sysconfdir, which isn't always /etc/ depending on configuration. The
configured directory is now printed in configure output. - Added NI
PCIe-GPIB to supported hardware matrix. - Added ibrsv2, which can be used
to avoid spurious service requests that ibrsv is prone to. Currently only
implemented for fmh_gpib and tnt4882. - Added support for IbcHSCableLength
in ibconfig which is needed to enable high speed noninterlocked handshaking
(a.k.a. HS488). - Added support for selecting hardware by sysfs device path
or serial number. - Removed obsolete hotplug usermaps. - Fixed and
refactored udev rules and related scripts. - Improved multi-board
initialisation scripts. - Made ibln and FindLstn address the board as
talker, to work around problems caused by transceivers preventing the NDAC
line from being read accurately. - A number of other fixes as well as
patches from the community. See Changelog entries from r1764 for more
details. Note: As the udev rules were changed and refactored in this
release it necessary to remove any pre 4.3.0 gpib udev rules files in
/etc/udev/rules.d/ before installing linux-gpib-user-4.3.0. The files to
remove are: 99-agilent_82357a.rules 99-gpib-generic.rules
99-ni_usb_gpib.rules

Re: [Linux-gpib-general] Fwd: Re: NI GPIB-USB-HS+ on debian 10 (buster)

[Bruno G. <bg...@au...>]

Hi Frank,

thank you for the advices and the help.

Regards,

Bruno

On 22/08/19 5:29 PM, Frank Mori Hess wrote:
>> On Wed, 21 Aug 2019 at 19:10, Bruno Garbin <bg...@au...> wrote:
>>> Please note, however, that the device blinks from orange to green continuously.
>>> Would you happen to have an explanation/fix for this?
> The explanation is that we ignore the bus analyzer portion of the HS+
> and never do anything to initialize it.  It doesn't seem to cause any
> problems.  If someone really wanted to fix it, you would have to use a
> usb sniffer to reverse engineer how the NI windows driver initializes
> the analyzer.

Re: [Linux-gpib-general] Fwd: Re: NI GPIB-USB-HS+ on debian 10 (buster)

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

> On Wed, 21 Aug 2019 at 19:10, Bruno Garbin <bg...@au...> wrote:

>> Please note, however, that the device blinks from orange to green continuously.
>> Would you happen to have an explanation/fix for this?

The explanation is that we ignore the bus analyzer portion of the HS+
and never do anything to initialize it.  It doesn't seem to cause any
problems.  If someone really wanted to fix it, you would have to use a
usb sniffer to reverse engineer how the NI windows driver initializes
the analyzer.

Re: [Linux-gpib-general] NI GPIB-USB-HS+ on debian 10 (buster)

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

On Wed, Aug 21, 2019 at 9:10 AM Bruno Garbin <bg...@au...> wrote:
>
> gpib_config
> failed to bring board online
> failed to configure board
> main: No such device
>
> When I try to load the driver manually:
> fxload -D /dev/bus/usb/001/017 -I niusbb_firmware.hex -s niusbb_loader.hex
> can't modify CPUCS: Broken pipe

The firmware is just for the usb-b.  The hs+ doesn't need any firmware
load.  Are you trying to use both adapters at the same time?  If so,
you'll need to use the "--minor" or "--device-file" option of
gpib_config to specify something other than the default of /dev/gpib0
for one of the boards.

Usually, the usb boards are configured by the udev scripts.  The udev
scripts from svn work better than the ones from the latest release.
Unfortunately, some of their names have changed slightly so you will
want to delete the old gpib scripts from /etc/udev/rules.d before
installing svn linux-gpib.  Also see
/etc/udev/rules.d/98-gpib-generic.rules for some commented-out
examples of how to associate specific boards with specific device
files.

Also, the driver used to wrongly bind to the analyzer part of the hs+
which could cause problems in some cases, that is also fixed in svn.

-- 
Frank

[Linux-gpib-general] NI GPIB-USB-HS+ on debian 10 (buster)

[Bruno G. <bg...@au...>]

Dear linux-gpib,

I am trying to install a GPIB-USB-HS+ board on a newly install debian 10 
(buster). Note that I successfully configured a GPIB-USB-B device already.

Here are the output of some commands that may be helpful in 
understanding the issue.

uname -a
Linux *hostname* 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 
(2019-08-08) x86_64 GNU/Linux

gpib_config
failed to bring board online
failed to configure board
main: No such device

When I try to load the driver manually:
fxload -D /dev/bus/usb/001/017 -I niusbb_firmware.hex -s niusbb_loader.hex
can't modify CPUCS: Broken pipe

Note that those .hex files are the exact same used for the GPIB-USB-B 
adapter that works.

Thank you in advance for the help.

Regards,

Bruno

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

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

On Thu, Aug 1, 2019, 02:23 Dirk Niggemann <dir...@gm...> wrote:

> Hi Frank,
>
> Yes, disabling TCS works perfectly, as you suggested.
> Do you think that's the correct fix for this? Or should we aim for
> something like a read of DIR register just before every TCA
>


Yes disabling tcs is best.  The rhld command or read of DIR causing
transitions to NRFD is actually nonsensical behavior.  There are several
errors in the acceptor state machine described by the tms9914a manual.  My
guess is the designers of the 82350b copied mistakes in the tms9914a
documentation into their hardware.


>>

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

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

Hi Frank,

Yes, disabling TCS works perfectly, as you suggested.
Do you think that's the correct fix for this? Or should we aim for
something like a read of DIR register just before every TCA?

Regards,

Dirk



On Thu, Aug 1, 2019 at 3:41 AM Frank Mori Hess <fm...@gm...> wrote:

> On Wed, Jul 31, 2019 at 8:08 PM Dirk Niggemann <dir...@gm...>
> wrote:
> > I thought the issue was directly related to the particular device
> because i originally triggered the issue by sending an invalid command to
> the board.
> > You don't actually need to send anything- just reading from the device
> without sending anything is sufficient,
> >
>
> Yeah, attempting a read that fails will leave the board out of the
> ANRS state, causing tcs to fail.  Try modifying tms9914_aux.c by
> changing tms9914_take_control so that it immediately returns
> -ETIMEDOUT if "synchronous" is true.   So basically, you want to make
> sure it never writes AUX_TCS to the  AUXCR register.
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

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

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

On Wed, Jul 31, 2019 at 8:08 PM Dirk Niggemann <dir...@gm...> wrote:
> I thought the issue was directly related to the particular device because i originally triggered the issue by sending an invalid command to the board.
> You don't actually need to send anything- just reading from the device without sending anything is sufficient,
>

Yeah, attempting a read that fails will leave the board out of the
ANRS state, causing tcs to fail.  Try modifying tms9914_aux.c by
changing tms9914_take_control so that it immediately returns
-ETIMEDOUT if "synchronous" is true.   So basically, you want to make
sure it never writes AUX_TCS to the  AUXCR register.

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

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

Hi Frank,

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

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

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

Regards,

Dirk







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

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

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

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

I found a detailed manual for the tms9914a online, and it has a
diagram for the controller state machine.  If it is accurate, it could
explain the behavior.  It shows if the chip is given a tcs command, it
transitions from CSBS to CWAS.  Then it waits for ANRS to complete the
transition to CSHS.  The problem is, while in CWAS it ignores tca.  So
if a synchronous tcs is issued but never completes due to the acceptor
not ready state (ANRS) never happening, then tca won't have any
effect.  The only workaround I see would be to never use tcs so it
can't get stuck in the CWAS state.

Also, the datasheet's acceptor handshake diagram shows transitions to
ANRS when the rhdf command is issued or the data in register is read,
so that could explain why they ungum things, since ANRS allows the
take control synchronously to complete.

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

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

On Wed, Jul 31, 2019 at 5:47 PM Dirk Niggemann <dir...@gm...> wrote:
>
>
> H Frank,
>
> I checked the value returned from the DIR register and it's almost always 0xa so the last byte sent on the previously successful read. Or 0 if we never read anything.
>
> I am already testing with the _unaccel driver because i wanted to make sure this wasn't a side effect of using the FIFOs- sorry, I should have mentioned that.

You said the board goes into the bad state after sending an invalid
command to the device.  The controller doesn't care if the command was
valid or not, so what is the device doing that puts the controller
into a bad state?  Does it request service when it receives a bad
command?  You could check the state of the SRQ and other bus lines
using iblines.

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

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

H Frank,

I checked the value returned from the DIR register and it's almost always
0xa so the last byte sent on the previously successful read. Or 0 if we
never read anything.

I am already testing with the _unaccel driver because i wanted to make sure
this wasn't a side effect of using the FIFOs- sorry, I should have
mentioned that.

Regards,

Dirk

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

> On Tue, Jul 30, 2019 at 4:14 AM Dirk Niggemann <dir...@gm...>
> wrote:
> >
> > Yes, that works too.
> >
> > That leaves the question of why there is a byte to read when nothing was
> sent?
> >
>
> Oh, maybe there isn't a byte.  Reading the DIR register tickles the
> data holdoff logic, so maybe that could cause it.  Another thing you
> could try is using "agilent_82350b_unaccel" as the board type, to take
> the fifos out of the picture.  Then the driver will only use the
> tms9914 directly.
>
>
> _______________________________________________
> 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 Tue, Jul 30, 2019 at 4:14 AM Dirk Niggemann <dir...@gm...> wrote:
>
> Yes, that works too.
>
> That leaves the question of why there is a byte to read when nothing was sent?
>

Oh, maybe there isn't a byte.  Reading the DIR register tickles the
data holdoff logic, so maybe that could cause it.  Another thing you
could try is using "agilent_82350b_unaccel" as the board type, to take
the fifos out of the picture.  Then the driver will only use the
tms9914 directly.