Menu
▾
▴
linux-gpib-general — linux-gpib package mailing list
You can subscribe to this list here.
| 2002 |
Jan
(2) |
Feb
(2) |
Mar
(22) |
Apr
(24) |
May
(7) |
Jun
(44) |
Jul
(16) |
Aug
(2) |
Sep
(13) |
Oct
(11) |
Nov
(19) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(16) |
Feb
(27) |
Mar
(5) |
Apr
(20) |
May
(17) |
Jun
(34) |
Jul
(29) |
Aug
(22) |
Sep
(25) |
Oct
(11) |
Nov
(13) |
Dec
(18) |
| 2004 |
Jan
(25) |
Feb
(22) |
Mar
(33) |
Apr
(15) |
May
(37) |
Jun
(15) |
Jul
(12) |
Aug
(22) |
Sep
(18) |
Oct
(45) |
Nov
(19) |
Dec
(30) |
| 2005 |
Jan
(31) |
Feb
(35) |
Mar
(27) |
Apr
(22) |
May
(9) |
Jun
(13) |
Jul
(13) |
Aug
(9) |
Sep
(25) |
Oct
(25) |
Nov
(12) |
Dec
(20) |
| 2006 |
Jan
(14) |
Feb
(16) |
Mar
(17) |
Apr
(8) |
May
(7) |
Jun
(20) |
Jul
(21) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(23) |
Dec
(15) |
| 2007 |
Jan
(13) |
Feb
(14) |
Mar
(24) |
Apr
(21) |
May
(9) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
(21) |
Oct
(5) |
Nov
(30) |
Dec
(9) |
| 2008 |
Jan
(15) |
Feb
(18) |
Mar
(4) |
Apr
(11) |
May
(3) |
Jun
(14) |
Jul
(12) |
Aug
(1) |
Sep
(31) |
Oct
(10) |
Nov
(9) |
Dec
(2) |
| 2009 |
Jan
(9) |
Feb
(6) |
Mar
(9) |
Apr
(2) |
May
(7) |
Jun
(22) |
Jul
(5) |
Aug
(1) |
Sep
(26) |
Oct
(13) |
Nov
(2) |
Dec
(10) |
| 2010 |
Jan
(29) |
Feb
(2) |
Mar
(23) |
Apr
(9) |
May
(7) |
Jun
(8) |
Jul
(4) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(9) |
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(25) |
May
(2) |
Jun
(19) |
Jul
(6) |
Aug
(4) |
Sep
(9) |
Oct
(3) |
Nov
(8) |
Dec
(7) |
| 2012 |
Jan
(5) |
Feb
(10) |
Mar
(10) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(18) |
Dec
(10) |
| 2013 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(4) |
Jun
|
Jul
(26) |
Aug
(13) |
Sep
(24) |
Oct
(2) |
Nov
(1) |
Dec
(4) |
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(5) |
| 2015 |
Jan
(1) |
Feb
(8) |
Mar
(7) |
Apr
(30) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(6) |
Oct
(13) |
Nov
(9) |
Dec
(2) |
| 2016 |
Jan
|
Feb
(7) |
Mar
(11) |
Apr
(6) |
May
(2) |
Jun
(16) |
Jul
(2) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(7) |
| 2017 |
Jan
(9) |
Feb
(25) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(14) |
Sep
(23) |
Oct
(3) |
Nov
|
Dec
(4) |
| 2018 |
Jan
|
Feb
|
Mar
(6) |
Apr
(4) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(3) |
Nov
(20) |
Dec
(10) |
| 2019 |
Jan
(4) |
Feb
(2) |
Mar
(9) |
Apr
(7) |
May
(2) |
Jun
(14) |
Jul
(17) |
Aug
(8) |
Sep
(9) |
Oct
(2) |
Nov
(2) |
Dec
(5) |
| 2020 |
Jan
(5) |
Feb
(13) |
Mar
|
Apr
(6) |
May
|
Jun
(7) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(11) |
Dec
(4) |
| 2021 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
(7) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
|
Dec
(3) |
| 2022 |
Jan
(5) |
Feb
(13) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(4) |
Jul
|
Aug
(10) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(4) |
| 2023 |
Jan
(10) |
Feb
(5) |
Mar
|
Apr
|
May
(5) |
Jun
(4) |
Jul
(6) |
Aug
(4) |
Sep
(28) |
Oct
(8) |
Nov
(2) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(3) |
Jun
(1) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
(28) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: dave p. <dpe...@gm...> - 2020-11-30 10:33:18
|
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
>
|
|
From: Mitchell C. <mo....@gm...> - 2020-11-30 00:44:34
|
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. |
|
From: Alexander H. <ale...@xx...> - 2020-11-24 14:00:34
|
Yes, I found that during research a few days ago too. I'd prefer something for Linux, ideally open source, but hey, it's better than nothing. I wonder how difficult it would be to write a plotter emulator from scratch in something like python. I think it would have to understand the commands with it's coordinates and paint that on a canvas of some sort. But that's a task for another day, when the basics are working. i reached out to the pyvisa-py developers for advise, they say the 'bus error' I see in the kernel ring buffer is an indication for a low level problem. Is there anything I can do with linux-gpib directly to debug this? -Alex On Mon, Nov 23, 2020 at 03:10:24PM +0100, W wrote: > Maybe you can use this tool (http://www.ke5fx.com/gpib/7470.htm) to make a > screenshot of your display > > On 23.11.2020 00:26, Alexander Huemer wrote: > > Things start to move here. > > Your installation instructions were very useful, Walter, thank you! > > I found that I had to add --enable-python-binding to ./configure and add > > PYTHONPATH="/usr/local/lib/python3.7/site-packages/" to /etc/profile, > > but eventually I got: > > > > GPIB INSTR: Available via Linux GPIB (b'4.3.3') > > GPIB INTFC: Available via Linux GPIB (b'4.3.3') > > > > in `python3 -m visa info`. Yay! > > > > I then proceeded to play with `python -m visa shell` and visa_test.py > > and managed to enable and disable the output of my power supply and > > write fancy text to the display. > > > > There are situations in which i get error messages in the kernel ring > > buffer like these though: > > > > Nov 22 11:53:43 gpib kernel: tnt4882: write bus error > > > > and > > > > Nov 22 11:41:46 gpib kernel: tnt4882: minor 0 read timed out > > Nov 22 11:41:46 gpib kernel: tnt4882: read timed out > > > > Also, pyvisa often exits with: > > > > pyvisa.errors.VisaIOError: VI_ERROR_SYSTEM_ERROR (-1073807360): Unknown system error (miscellaneous error). > > > > and > > > > pyvisa.errors.VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed. > > > > I haven't figured out yet why that is. Is it obvious what I am doing > > wrong here? > > > > My instruments display things like 'Rmt Addr Err' and 'REM MTA'. Not > > sure yet what these mean, but 'Err' definitely doesn't sound right. > > > > One of my goals is to be able to get screenshots off my scope. > > The programming manual says: > > > > Example: > > > > 210 CLEAR 707 ! Clear interface buffers. > > 220 OUTPUT 707;"PLOT" ! Starts plotter buffering. > > 230 SEND 7;UNT UNL ! Clears bus, set ATN line at controller true. > > 240 SEND 7;LISTEN 5 ! Tells plotter at address 5 to listen. > > 250 SEND 7;TALK 7 ! Sets 54200A/D to talk mode. > > 260 SEND 7;DATA ! Sets ATN line at controller to false > > 270 ! so data can be transferred. > > 280 WAIT 50 ! Wait 50 seconds for transfer to finish > > 290 ! Note: If programming, use the SRQ capabilities > > 300 ! of the 54200A/D to determine if the transfer > > 310 ! is complete. Attempting to program the > > 320 ! 54200A/D while making a hardcopy dump will > > 330 ! cause errors. > > > > How would I go about receiving such a plot with pyvisa or linux-gpib > > directly? Can it be done? A quick web search didn't provide insights. > > > > Thanks, > > -Alex > > > > On Sun, Nov 22, 2020 at 05:19:58PM +0100, W wrote: > > > Hi Alex > > > > > > I followed the same path as you and gave up with these NI-Visa drivers. Now > > > I have something working with linux-gpib, pyvisa/pyvisa-py on an old PC > > > (Pentium 4) > > > > > > A couple of days ago, I described my process to have this software > > > installed. If you are interested, you can find it here <https://github.com/daturach/Documentation/wiki/GPIB:-Building-an-instrumentation-lab-with-python-libraries> > > > > > > Good luck > > > > > > Walter > > > > > > On 22.11.2020 12:18, Alexander Huemer wrote: > > > > Hi > > > > > > > > That looks promising. I actually already had it installed but didn't > > > > look at it yet. From the README I figure that it has linux-gpib as a > > > > dependency. I'll have to look into it. > > > > Thanks for the suggestion. > > > > > > > > -Alex > > > > > > > > On Sun, Nov 22, 2020 at 10:58:44AM +0100, Roel Jordans wrote: > > > > > Hi Alex, > > > > > > > > > > You may want to have a look at pyvisa-py. That seems to work nicely > > > > > for me without having to install the NI-VISA drivers. > > > > > > > > > > Cheers, > > > > > Roel > > > > > > > > > > -----Original Message----- > > > > > From: Alexander Huemer <ale...@xx...> > > > > > To: Linux GPIB general mailinglist < > > > > > lin...@li...> > > > > > Subject: [Linux-gpib-general] Compatibility layer for pyvisa? > > > > > Date: Sun, 22 Nov 2020 08:57:29 +0000 > > > > > > > > > > Hi > > > > > > > > > > My understanding is this: > > > > > * linux-gpib implements drivers for many GPIB interfaces and provides > > > > > a > > > > > userspace API on top of that, which is great. > > > > > * pyvisa depends on vendor drivers like NI-VISA or the equivalent of > > > > > other vendors. > > > > > > > > > > Is this correct? > > > > > > > > > > I tried to get NI-VISA working yesterday in order to be able to use > > > > > pyvisa with a NI PCI board, on a distribution that they do not want to > > > > > support, on a i686 box. I gave up after some hours, the configure > > > > > script they have in there was written by drunk monkeys. > > > > > > > > > > So, here is my question: Did anybody consider to make the linux-gpib > > > > > drivers available to pyvisa? > > > > > > > > > > -Alex > > > > > > > > > > [1] > > > > > https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223 > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > _______________________________________________ > > 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 |
|
From: W <dat...@gm...> - 2020-11-23 14:10:37
|
Maybe you can use this tool (http://www.ke5fx.com/gpib/7470.htm) to make a screenshot of your display On 23.11.2020 00:26, Alexander Huemer wrote: > Things start to move here. > Your installation instructions were very useful, Walter, thank you! > I found that I had to add --enable-python-binding to ./configure and add > PYTHONPATH="/usr/local/lib/python3.7/site-packages/" to /etc/profile, > but eventually I got: > > GPIB INSTR: Available via Linux GPIB (b'4.3.3') > GPIB INTFC: Available via Linux GPIB (b'4.3.3') > > in `python3 -m visa info`. Yay! > > I then proceeded to play with `python -m visa shell` and visa_test.py > and managed to enable and disable the output of my power supply and > write fancy text to the display. > > There are situations in which i get error messages in the kernel ring > buffer like these though: > > Nov 22 11:53:43 gpib kernel: tnt4882: write bus error > > and > > Nov 22 11:41:46 gpib kernel: tnt4882: minor 0 read timed out > Nov 22 11:41:46 gpib kernel: tnt4882: read timed out > > Also, pyvisa often exits with: > > pyvisa.errors.VisaIOError: VI_ERROR_SYSTEM_ERROR (-1073807360): Unknown system error (miscellaneous error). > > and > > pyvisa.errors.VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed. > > I haven't figured out yet why that is. Is it obvious what I am doing > wrong here? > > My instruments display things like 'Rmt Addr Err' and 'REM MTA'. Not > sure yet what these mean, but 'Err' definitely doesn't sound right. > > One of my goals is to be able to get screenshots off my scope. > The programming manual says: > > Example: > > 210 CLEAR 707 ! Clear interface buffers. > 220 OUTPUT 707;"PLOT" ! Starts plotter buffering. > 230 SEND 7;UNT UNL ! Clears bus, set ATN line at controller true. > 240 SEND 7;LISTEN 5 ! Tells plotter at address 5 to listen. > 250 SEND 7;TALK 7 ! Sets 54200A/D to talk mode. > 260 SEND 7;DATA ! Sets ATN line at controller to false > 270 ! so data can be transferred. > 280 WAIT 50 ! Wait 50 seconds for transfer to finish > 290 ! Note: If programming, use the SRQ capabilities > 300 ! of the 54200A/D to determine if the transfer > 310 ! is complete. Attempting to program the > 320 ! 54200A/D while making a hardcopy dump will > 330 ! cause errors. > > How would I go about receiving such a plot with pyvisa or linux-gpib > directly? Can it be done? A quick web search didn't provide insights. > > Thanks, > -Alex > > On Sun, Nov 22, 2020 at 05:19:58PM +0100, W wrote: >> Hi Alex >> >> I followed the same path as you and gave up with these NI-Visa drivers. Now >> I have something working with linux-gpib, pyvisa/pyvisa-py on an old PC >> (Pentium 4) >> >> A couple of days ago, I described my process to have this software >> installed. If you are interested, you can find it here <https://github.com/daturach/Documentation/wiki/GPIB:-Building-an-instrumentation-lab-with-python-libraries> >> >> Good luck >> >> Walter >> >> On 22.11.2020 12:18, Alexander Huemer wrote: >>> Hi >>> >>> That looks promising. I actually already had it installed but didn't >>> look at it yet. From the README I figure that it has linux-gpib as a >>> dependency. I'll have to look into it. >>> Thanks for the suggestion. >>> >>> -Alex >>> >>> On Sun, Nov 22, 2020 at 10:58:44AM +0100, Roel Jordans wrote: >>>> Hi Alex, >>>> >>>> You may want to have a look at pyvisa-py. That seems to work nicely >>>> for me without having to install the NI-VISA drivers. >>>> >>>> Cheers, >>>> Roel >>>> >>>> -----Original Message----- >>>> From: Alexander Huemer <ale...@xx...> >>>> To: Linux GPIB general mailinglist < >>>> lin...@li...> >>>> Subject: [Linux-gpib-general] Compatibility layer for pyvisa? >>>> Date: Sun, 22 Nov 2020 08:57:29 +0000 >>>> >>>> Hi >>>> >>>> My understanding is this: >>>> * linux-gpib implements drivers for many GPIB interfaces and provides >>>> a >>>> userspace API on top of that, which is great. >>>> * pyvisa depends on vendor drivers like NI-VISA or the equivalent of >>>> other vendors. >>>> >>>> Is this correct? >>>> >>>> I tried to get NI-VISA working yesterday in order to be able to use >>>> pyvisa with a NI PCI board, on a distribution that they do not want to >>>> support, on a i686 box. I gave up after some hours, the configure >>>> script they have in there was written by drunk monkeys. >>>> >>>> So, here is my question: Did anybody consider to make the linux-gpib >>>> drivers available to pyvisa? >>>> >>>> -Alex >>>> >>>> [1] >>>> https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223 >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general |
|
From: W <dat...@gm...> - 2020-11-23 09:18:58
|
Hello Alex I am glad you find it useful. I guess you have a HP 54200. Did you manage to get the response of an ID command? The small script you sent supposed that your instrument is set to address 7. If you have visa timeout errors, that means your instrument did not respond to a query or didn't have the time to do it. You can increase that timeout. (https://pyvisa.readthedocs.io/en/1.8/resources.html) Try something like that for a first test: import pyvisa as visa rm = visa.ResourceManager('@py') instr = rm.open_resource('GPIB0::7::INSTR') instr.read_termination = '\n' instr.write_termination = '\n' instr.write('ID?') print(instr.read_raw()) instr.close() Check your ID command in your manual. It may be different. Check as well your terminations characters. Walter On 23.11.2020 00:26, Alexander Huemer wrote: > Things start to move here. > Your installation instructions were very useful, Walter, thank you! > I found that I had to add --enable-python-binding to ./configure and add > PYTHONPATH="/usr/local/lib/python3.7/site-packages/" to /etc/profile, > but eventually I got: > > GPIB INSTR: Available via Linux GPIB (b'4.3.3') > GPIB INTFC: Available via Linux GPIB (b'4.3.3') > > in `python3 -m visa info`. Yay! > > I then proceeded to play with `python -m visa shell` and visa_test.py > and managed to enable and disable the output of my power supply and > write fancy text to the display. > > There are situations in which i get error messages in the kernel ring > buffer like these though: > > Nov 22 11:53:43 gpib kernel: tnt4882: write bus error > > and > > Nov 22 11:41:46 gpib kernel: tnt4882: minor 0 read timed out > Nov 22 11:41:46 gpib kernel: tnt4882: read timed out > > Also, pyvisa often exits with: > > pyvisa.errors.VisaIOError: VI_ERROR_SYSTEM_ERROR (-1073807360): Unknown system error (miscellaneous error). > > and > > pyvisa.errors.VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed. > > I haven't figured out yet why that is. Is it obvious what I am doing > wrong here? > > My instruments display things like 'Rmt Addr Err' and 'REM MTA'. Not > sure yet what these mean, but 'Err' definitely doesn't sound right. > > One of my goals is to be able to get screenshots off my scope. > The programming manual says: > > Example: > > 210 CLEAR 707 ! Clear interface buffers. > 220 OUTPUT 707;"PLOT" ! Starts plotter buffering. > 230 SEND 7;UNT UNL ! Clears bus, set ATN line at controller true. > 240 SEND 7;LISTEN 5 ! Tells plotter at address 5 to listen. > 250 SEND 7;TALK 7 ! Sets 54200A/D to talk mode. > 260 SEND 7;DATA ! Sets ATN line at controller to false > 270 ! so data can be transferred. > 280 WAIT 50 ! Wait 50 seconds for transfer to finish > 290 ! Note: If programming, use the SRQ capabilities > 300 ! of the 54200A/D to determine if the transfer > 310 ! is complete. Attempting to program the > 320 ! 54200A/D while making a hardcopy dump will > 330 ! cause errors. > > How would I go about receiving such a plot with pyvisa or linux-gpib > directly? Can it be done? A quick web search didn't provide insights. > > Thanks, > -Alex > > On Sun, Nov 22, 2020 at 05:19:58PM +0100, W wrote: >> Hi Alex >> >> I followed the same path as you and gave up with these NI-Visa drivers. Now >> I have something working with linux-gpib, pyvisa/pyvisa-py on an old PC >> (Pentium 4) >> >> A couple of days ago, I described my process to have this software >> installed. If you are interested, you can find it here <https://github.com/daturach/Documentation/wiki/GPIB:-Building-an-instrumentation-lab-with-python-libraries> >> >> Good luck >> >> Walter >> >> On 22.11.2020 12:18, Alexander Huemer wrote: >>> Hi >>> >>> That looks promising. I actually already had it installed but didn't >>> look at it yet. From the README I figure that it has linux-gpib as a >>> dependency. I'll have to look into it. >>> Thanks for the suggestion. >>> >>> -Alex >>> >>> On Sun, Nov 22, 2020 at 10:58:44AM +0100, Roel Jordans wrote: >>>> Hi Alex, >>>> >>>> You may want to have a look at pyvisa-py. That seems to work nicely >>>> for me without having to install the NI-VISA drivers. >>>> >>>> Cheers, >>>> Roel >>>> >>>> -----Original Message----- >>>> From: Alexander Huemer <ale...@xx...> >>>> To: Linux GPIB general mailinglist < >>>> lin...@li...> >>>> Subject: [Linux-gpib-general] Compatibility layer for pyvisa? >>>> Date: Sun, 22 Nov 2020 08:57:29 +0000 >>>> >>>> Hi >>>> >>>> My understanding is this: >>>> * linux-gpib implements drivers for many GPIB interfaces and provides >>>> a >>>> userspace API on top of that, which is great. >>>> * pyvisa depends on vendor drivers like NI-VISA or the equivalent of >>>> other vendors. >>>> >>>> Is this correct? >>>> >>>> I tried to get NI-VISA working yesterday in order to be able to use >>>> pyvisa with a NI PCI board, on a distribution that they do not want to >>>> support, on a i686 box. I gave up after some hours, the configure >>>> script they have in there was written by drunk monkeys. >>>> >>>> So, here is my question: Did anybody consider to make the linux-gpib >>>> drivers available to pyvisa? >>>> >>>> -Alex >>>> >>>> [1] >>>> https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223 >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general |
|
From: Alexander H. <ale...@xx...> - 2020-11-22 23:27:32
|
Things start to move here.
Your installation instructions were very useful, Walter, thank you!
I found that I had to add --enable-python-binding to ./configure and add
PYTHONPATH="/usr/local/lib/python3.7/site-packages/" to /etc/profile,
but eventually I got:
GPIB INSTR: Available via Linux GPIB (b'4.3.3')
GPIB INTFC: Available via Linux GPIB (b'4.3.3')
in `python3 -m visa info`. Yay!
I then proceeded to play with `python -m visa shell` and visa_test.py
and managed to enable and disable the output of my power supply and
write fancy text to the display.
There are situations in which i get error messages in the kernel ring
buffer like these though:
Nov 22 11:53:43 gpib kernel: tnt4882: write bus error
and
Nov 22 11:41:46 gpib kernel: tnt4882: minor 0 read timed out
Nov 22 11:41:46 gpib kernel: tnt4882: read timed out
Also, pyvisa often exits with:
pyvisa.errors.VisaIOError: VI_ERROR_SYSTEM_ERROR (-1073807360): Unknown system error (miscellaneous error).
and
pyvisa.errors.VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.
I haven't figured out yet why that is. Is it obvious what I am doing
wrong here?
My instruments display things like 'Rmt Addr Err' and 'REM MTA'. Not
sure yet what these mean, but 'Err' definitely doesn't sound right.
One of my goals is to be able to get screenshots off my scope.
The programming manual says:
Example:
210 CLEAR 707 ! Clear interface buffers.
220 OUTPUT 707;"PLOT" ! Starts plotter buffering.
230 SEND 7;UNT UNL ! Clears bus, set ATN line at controller true.
240 SEND 7;LISTEN 5 ! Tells plotter at address 5 to listen.
250 SEND 7;TALK 7 ! Sets 54200A/D to talk mode.
260 SEND 7;DATA ! Sets ATN line at controller to false
270 ! so data can be transferred.
280 WAIT 50 ! Wait 50 seconds for transfer to finish
290 ! Note: If programming, use the SRQ capabilities
300 ! of the 54200A/D to determine if the transfer
310 ! is complete. Attempting to program the
320 ! 54200A/D while making a hardcopy dump will
330 ! cause errors.
How would I go about receiving such a plot with pyvisa or linux-gpib
directly? Can it be done? A quick web search didn't provide insights.
Thanks,
-Alex
On Sun, Nov 22, 2020 at 05:19:58PM +0100, W wrote:
> Hi Alex
>
> I followed the same path as you and gave up with these NI-Visa drivers. Now
> I have something working with linux-gpib, pyvisa/pyvisa-py on an old PC
> (Pentium 4)
>
> A couple of days ago, I described my process to have this software
> installed. If you are interested, you can find it here <https://github.com/daturach/Documentation/wiki/GPIB:-Building-an-instrumentation-lab-with-python-libraries>
>
> Good luck
>
> Walter
>
> On 22.11.2020 12:18, Alexander Huemer wrote:
> > Hi
> >
> > That looks promising. I actually already had it installed but didn't
> > look at it yet. From the README I figure that it has linux-gpib as a
> > dependency. I'll have to look into it.
> > Thanks for the suggestion.
> >
> > -Alex
> >
> > On Sun, Nov 22, 2020 at 10:58:44AM +0100, Roel Jordans wrote:
> > > Hi Alex,
> > >
> > > You may want to have a look at pyvisa-py. That seems to work nicely
> > > for me without having to install the NI-VISA drivers.
> > >
> > > Cheers,
> > > Roel
> > >
> > > -----Original Message-----
> > > From: Alexander Huemer <ale...@xx...>
> > > To: Linux GPIB general mailinglist <
> > > lin...@li...>
> > > Subject: [Linux-gpib-general] Compatibility layer for pyvisa?
> > > Date: Sun, 22 Nov 2020 08:57:29 +0000
> > >
> > > Hi
> > >
> > > My understanding is this:
> > > * linux-gpib implements drivers for many GPIB interfaces and provides
> > > a
> > > userspace API on top of that, which is great.
> > > * pyvisa depends on vendor drivers like NI-VISA or the equivalent of
> > > other vendors.
> > >
> > > Is this correct?
> > >
> > > I tried to get NI-VISA working yesterday in order to be able to use
> > > pyvisa with a NI PCI board, on a distribution that they do not want to
> > > support, on a i686 box. I gave up after some hours, the configure
> > > script they have in there was written by drunk monkeys.
> > >
> > > So, here is my question: Did anybody consider to make the linux-gpib
> > > drivers available to pyvisa?
> > >
> > > -Alex
> > >
> > > [1]
> > > https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223
> > >
> > >
> > > _______________________________________________
> > > 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
|
|
From: W <dat...@gm...> - 2020-11-22 16:31:40
|
Hi Alex I followed the same path as you and gave up with these NI-Visa drivers. Now I have something working with linux-gpib, pyvisa/pyvisa-py on an old PC (Pentium 4) A couple of days ago, I described my process to have this software installed. If you are interested, you can find it here <https://github.com/daturach/Documentation/wiki/GPIB:-Building-an-instrumentation-lab-with-python-libraries> Good luck Walter On 22.11.2020 12:18, Alexander Huemer wrote: > Hi > > That looks promising. I actually already had it installed but didn't > look at it yet. From the README I figure that it has linux-gpib as a > dependency. I'll have to look into it. > Thanks for the suggestion. > > -Alex > > On Sun, Nov 22, 2020 at 10:58:44AM +0100, Roel Jordans wrote: >> Hi Alex, >> >> You may want to have a look at pyvisa-py. That seems to work nicely >> for me without having to install the NI-VISA drivers. >> >> Cheers, >> Roel >> >> -----Original Message----- >> From: Alexander Huemer <ale...@xx...> >> To: Linux GPIB general mailinglist < >> lin...@li...> >> Subject: [Linux-gpib-general] Compatibility layer for pyvisa? >> Date: Sun, 22 Nov 2020 08:57:29 +0000 >> >> Hi >> >> My understanding is this: >> * linux-gpib implements drivers for many GPIB interfaces and provides >> a >> userspace API on top of that, which is great. >> * pyvisa depends on vendor drivers like NI-VISA or the equivalent of >> other vendors. >> >> Is this correct? >> >> I tried to get NI-VISA working yesterday in order to be able to use >> pyvisa with a NI PCI board, on a distribution that they do not want to >> support, on a i686 box. I gave up after some hours, the configure >> script they have in there was written by drunk monkeys. >> >> So, here is my question: Did anybody consider to make the linux-gpib >> drivers available to pyvisa? >> >> -Alex >> >> [1] >> https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223 >> >> >> _______________________________________________ >> 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 |
|
From: Alexander H. <ale...@xx...> - 2020-11-22 11:18:32
|
Hi That looks promising. I actually already had it installed but didn't look at it yet. From the README I figure that it has linux-gpib as a dependency. I'll have to look into it. Thanks for the suggestion. -Alex On Sun, Nov 22, 2020 at 10:58:44AM +0100, Roel Jordans wrote: > Hi Alex, > > You may want to have a look at pyvisa-py. That seems to work nicely > for me without having to install the NI-VISA drivers. > > Cheers, > Roel > > -----Original Message----- > From: Alexander Huemer <ale...@xx...> > To: Linux GPIB general mailinglist < > lin...@li...> > Subject: [Linux-gpib-general] Compatibility layer for pyvisa? > Date: Sun, 22 Nov 2020 08:57:29 +0000 > > Hi > > My understanding is this: > * linux-gpib implements drivers for many GPIB interfaces and provides > a > userspace API on top of that, which is great. > * pyvisa depends on vendor drivers like NI-VISA or the equivalent of > other vendors. > > Is this correct? > > I tried to get NI-VISA working yesterday in order to be able to use > pyvisa with a NI PCI board, on a distribution that they do not want to > support, on a i686 box. I gave up after some hours, the configure > script they have in there was written by drunk monkeys. > > So, here is my question: Did anybody consider to make the linux-gpib > drivers available to pyvisa? > > -Alex > > [1] > https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223 > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Roel J. <r.j...@sc...> - 2020-11-22 10:12:44
|
Hi Alex, You may want to have a look at pyvisa-py. That seems to work nicely for me without having to install the NI-VISA drivers. Cheers, Roel -----Original Message----- From: Alexander Huemer <ale...@xx...> To: Linux GPIB general mailinglist < lin...@li...> Subject: [Linux-gpib-general] Compatibility layer for pyvisa? Date: Sun, 22 Nov 2020 08:57:29 +0000 Hi My understanding is this: * linux-gpib implements drivers for many GPIB interfaces and provides a userspace API on top of that, which is great. * pyvisa depends on vendor drivers like NI-VISA or the equivalent of other vendors. Is this correct? I tried to get NI-VISA working yesterday in order to be able to use pyvisa with a NI PCI board, on a distribution that they do not want to support, on a i686 box. I gave up after some hours, the configure script they have in there was written by drunk monkeys. So, here is my question: Did anybody consider to make the linux-gpib drivers available to pyvisa? -Alex [1] https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223 _______________________________________________ Linux-gpib-general mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-gpib-general |
|
From: Alexander H. <ale...@xx...> - 2020-11-22 09:24:39
|
Hi My understanding is this: * linux-gpib implements drivers for many GPIB interfaces and provides a userspace API on top of that, which is great. * pyvisa depends on vendor drivers like NI-VISA or the equivalent of other vendors. Is this correct? I tried to get NI-VISA working yesterday in order to be able to use pyvisa with a NI PCI board, on a distribution that they do not want to support, on a i686 box. I gave up after some hours, the configure script they have in there was written by drunk monkeys. So, here is my question: Did anybody consider to make the linux-gpib drivers available to pyvisa? -Alex [1] https://www.ni.com/de-at/support/downloads/drivers/download.ni-kal.html#334223 |
|
From: Edward J. <edw...@ni...> - 2020-08-12 18:06:01
|
Hey NI guy here, My customers have never complained that I am aware of and we recently had a project using the linux-gpib driver, hence I'm here. We didn't have any compatibility issues on our end, more other vendors had strange PCI bus stuff going on but once that got fixed it worked. From the general I believe NI offers GPIB+ which is extra debugging functionality and analytics on the chip which I think we've trademarked so are the only provider of this diagnostic capability during setup or maintenance... Anyone feel free to correct me if I'm wrong 😊 Of course, price is always a caveat, we also had some counterfeiters duplicate our cables but you don't get support if you buy them and they turn out to be faulty. Especially since the vendor can tell from serial numbers when you try to get it repaired. ________________________________ From: Steve Tell <te...@te...> Sent: 12 August 2020 18:45 To: lin...@li... <lin...@li...> Subject: [EXTERNAL] [Linux-gpib-general] Which GPIB-USB adaptor? What is everyone's preferred USB to GPIB adaptor for use with linux-gpib these days? At work we've been using the Agilent 82357B, but have had several fail and need some new ones. Failures seem equally distributed between the genuine agilent ones, and some possibly-counterfit ones obtained at a lower price. Of course Agilent stuff is now Keysight, but the 82357B looks the same. More lab equipment seems to be coming in with USB and ethernet ports these days, but still some things only have GPIB... _______________________________________________ Linux-gpib-general mailing list Lin...@li... https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!FbZ0ZwI3Qg!_d9rGh_Khix4TnfUhRyyQy4CrKPEynIeEVh1VeapxuCWf44WTLekyaiAMv1oBhg$ National Instruments Corporation (UK) Ltd | Measurement House | Newbury Business Park | Newbury | RG14 2PZ Registered Office: 42 - 50 Hersham Road | Walton-on-Thames | Surrey | KT12 1RZ United Kingdom: Company Registration No. 2999356 | VAT No. GB493598779 Ireland: Company Registration No. 904311 | VAT No. IE9514656W |
|
From: Steve T. <te...@te...> - 2020-08-12 17:45:23
|
What is everyone's preferred USB to GPIB adaptor for use with linux-gpib these days? At work we've been using the Agilent 82357B, but have had several fail and need some new ones. Failures seem equally distributed between the genuine agilent ones, and some possibly-counterfit ones obtained at a lower price. Of course Agilent stuff is now Keysight, but the 82357B looks the same. More lab equipment seems to be coming in with USB and ethernet ports these days, but still some things only have GPIB... |
|
From: Steve T. <te...@te...> - 2020-08-12 17:33:19
|
Does your Agilent 82357B work with any other GPIB devices?
We've had several 82357Bs fail, and I think thats how I remember them
dying - they just can't communicate with the GPIB side.
I did see a note somewhere suggesting a GPIB cable between the usb-gpib
adaptor and the instrument; perhaps they have a timing problem in some
caes.
Steve
On Tue, 7 Jul 2020, Andrew Z wrote:
> Hello!
>
> I am having some issues getting linux-gpib to work with my GPIB adapter and
> I was wondering if I could get some help. I'm not sure if this is the right
> place to ask, if not, it would be great if someone could direct me to the
> proper avenue!
>
> I have been looking around at previous issues and I haven't been able to
> find a solution to my problem. Here's my setup:
>
> Raspberry Pi 4 running 4.19.118-v7l+
> Agilent 82357B USB-to-GPIB adapter connected to a Tektronix TDS220
> linux-gpib-4.3.3, revision 1916
>
> I am getting a timeout error (14). I know *IDN? works as I have used it
> before successfully with a NI-GPIB-HS adapter.
>
> ```
> : w
> enter a string to send to your device: *IDN?
> sending string: *IDN?
>
> gpib status is:
> ibsta = 0xc100 < ERR TIMO CMPL >
> iberr= 14
> EBUS 14: Bus error
>
> ibcntl = 0
> ```
> I've also tried using \n at the end which is the correct end character for
> my instrument. But still I'm getting the same error message.
>
> ```
> : w
> enter a string to send to your device: *IDN?\n
> sending string: *IDN?\n
>
> gpib status is:
> ibsta = 0xc100 < ERR TIMO CMPL >
> iberr= 14
> EBUS 14: Bus error
>
> ibcntl = 0
> ```
>
> Here's my gpib.conf settings:
>
> ```
> interface {
> minor = 0 /* board index, minor = 0 uses /dev/gpib0, minor = 1
> uses /dev/gpib1, etc. */
> board_type = "agilent_82357a" /* 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 = T100s /* timeout for commands */
>
> eos = 0x0a /* 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 */
>
> /* settings for boards that lack plug-n-play capability */
> base = 0 /* Base io ADDRESS */
> irq = 0 /* Interrupt request level */
> dma = 0 /* DMA channel (zero disables) */
>
> /* pci_bus and pci_slot can be used to distinguish two pci boards supported
> by the same driver */
> /* pci_bus = 0 */
> /* pci_slot = 7 */
>
> master = yes /* interface board is system controller */
> }
> ```
>
> I have also loaded the firmware onto the agilent adapter and the ready light
> is green. I've used the exact same installation that was working on the
> NI-GPIB-HS adapter so I assume that my build and install procedures are
> correct. I also tried installing it on another pi for verification, same
> result.
>
> This seems to be the same error as listed by this
> tutorial: https://xdevs.com/guide/agilent_gpib_rpi/ .It says I should use
> revision 1654 or later on a 4.x.x kernel of which I am using revision 1916.
> I believe I've done everything correctly and have read a decent number of
> forums but none have yet to fix my problem. Any help though would be
> appreciated!
>
> Best,
>
> Andrew
>
>
> |
|
From: Andrew Z <and...@gm...> - 2020-07-07 19:02:03
|
Hello!
I am having some issues getting linux-gpib to work with my GPIB adapter and
I was wondering if I could get some help. I'm not sure if this is the right
place to ask, if not, it would be great if someone could direct me to the
proper avenue!
I have been looking around at previous issues and I haven't been able to
find a solution to my problem. Here's my setup:
Raspberry Pi 4 running 4.19.118-v7l+
Agilent 82357B USB-to-GPIB adapter connected to a Tektronix TDS220
linux-gpib-4.3.3, revision 1916
I am getting a timeout error (14). I know *IDN? works as I have used it
before successfully with a NI-GPIB-HS adapter.
```
: w
enter a string to send to your device: *IDN?
sending string: *IDN?
gpib status is:
ibsta = 0xc100 < ERR TIMO CMPL >
iberr= 14
EBUS 14: Bus error
ibcntl = 0
```
I've also tried using \n at the end which is the correct end character for
my instrument. But still I'm getting the same error message.
```
: w
enter a string to send to your device: *IDN?\n
sending string: *IDN?\n
gpib status is:
ibsta = 0xc100 < ERR TIMO CMPL >
iberr= 14
EBUS 14: Bus error
ibcntl = 0
```
Here's my gpib.conf settings:
```
interface {
minor = 0 /* board index, minor = 0 uses /dev/gpib0, minor =
1 uses /dev/gpib1, etc. */
board_type = "agilent_82357a" /* 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 = T100s /* timeout for commands */
eos = 0x0a /* 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 */
/* settings for boards that lack plug-n-play capability */
base = 0 /* Base io ADDRESS */
irq = 0 /* Interrupt request level */
dma = 0 /* DMA channel (zero disables) */
/* pci_bus and pci_slot can be used to distinguish two pci boards supported
by the same driver */
/* pci_bus = 0 */
/* pci_slot = 7 */
master = yes /* interface board is system controller */
}
```
I have also loaded the firmware onto the agilent adapter and the ready
light is green. I've used the exact same installation that was working on
the NI-GPIB-HS adapter so I assume that my build and install procedures are
correct. I also tried installing it on another pi for verification, same
result.
This seems to be the same error as listed by this tutorial:
https://xdevs.com/guide/agilent_gpib_rpi/ .It says I should use revision
1654 or later on a 4.x.x kernel of which I am using revision 1916. I
believe I've done everything correctly and have read a decent number of
forums but none have yet to fix my problem. Any help though would be
appreciated!
Best,
Andrew
|
|
From: dave p. <dpe...@gm...> - 2020-06-19 08:22:56
|
On Fri, 19 Jun 2020, 10:05 Richard Klingler, <ric...@gm...> wrote: > Hello Dave > > Ah okay....so how is the expected communication flow actually? > > From my understanding it looks like the controller ends his part after the > MTA5 command, which tells device 5 to respond... > > So can the device just begin transferring data with last byte EOI set or > does the device also needs > to send those MTA/MLA as well prepending the payload? > Yes the device can just begin transferring data as soon as it has been addressed as talker. It doesn't need to prepend MLA/MTA to the payload as it is only the controller in charge that sends those commands. > > thanks in advance > richard > > > Am Fr., 19. Juni 2020 um 09:48 Uhr schrieb dave penkler < > dpe...@gm...>: > >> Hi Richard, >> ibterm by default tries to read a response after a send but will not >> report an error on timeout of the read. >> cheers, >> -Dave >> >> On Thu, 18 Jun 2020, 10:52 Richard Klingler, <ric...@gm...> >> wrote: >> >>> Good morning (o; >>> >>> As I decided to develop a GPIB device based on STM32F MCU I did a first >>> setup based on a Nucleo-F207ZG board with attached 75160/161 transceivers... >>> >>> In my test code I just check for DAV and set NRFD and NDAC >>> accordingly.... >>> >>> Interestingly...when I send for example a *IDN? query to my test device, >>> which doesn't send back any data (not yet ;o), I don't get any errors in >>> ibterm....so is this normal that ibterm doesn't wait for data and just >>> closes the communication? >>> >>> Currently I just send out the received commands/Data out the USB CDC >>> device... >>> >>> Sending *IDN? I get in my USB console: >>> >>> CMD: 40 >>> CMD: 3F >>> CMD: 25 >>> DAT: * >>> DAT: I >>> DAT: D >>> DAT: N >>> DAT: ? >>> CMD: 3F >>> CMD: 20 >>> CMD: 45 >>> >>> Or does it misread EOI and therefore closes the communication? >>> >>> >>> thanks in advance >>> richard >>> >>> >>> >>> _______________________________________________ >>> 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 > |
|
From: Richard K. <ric...@gm...> - 2020-06-19 08:05:23
|
Hello Dave Ah okay....so how is the expected communication flow actually? >From my understanding it looks like the controller ends his part after the MTA5 command, which tells device 5 to respond... So can the device just begin transferring data with last byte EOI set or does the device also needs to send those MTA/MLA as well prepending the payload? thanks in advance richard Am Fr., 19. Juni 2020 um 09:48 Uhr schrieb dave penkler <dpe...@gm... >: > Hi Richard, > ibterm by default tries to read a response after a send but will not > report an error on timeout of the read. > cheers, > -Dave > > On Thu, 18 Jun 2020, 10:52 Richard Klingler, <ric...@gm...> > wrote: > >> Good morning (o; >> >> As I decided to develop a GPIB device based on STM32F MCU I did a first >> setup based on a Nucleo-F207ZG board with attached 75160/161 transceivers... >> >> In my test code I just check for DAV and set NRFD and NDAC accordingly.... >> >> Interestingly...when I send for example a *IDN? query to my test device, >> which doesn't send back any data (not yet ;o), I don't get any errors in >> ibterm....so is this normal that ibterm doesn't wait for data and just >> closes the communication? >> >> Currently I just send out the received commands/Data out the USB CDC >> device... >> >> Sending *IDN? I get in my USB console: >> >> CMD: 40 >> CMD: 3F >> CMD: 25 >> DAT: * >> DAT: I >> DAT: D >> DAT: N >> DAT: ? >> CMD: 3F >> CMD: 20 >> CMD: 45 >> >> Or does it misread EOI and therefore closes the communication? >> >> >> thanks in advance >> richard >> >> >> >> _______________________________________________ >> Linux-gpib-general mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general >> > |
|
From: dave p. <dpe...@gm...> - 2020-06-19 07:48:19
|
Hi Richard, ibterm by default tries to read a response after a send but will not report an error on timeout of the read. cheers, -Dave On Thu, 18 Jun 2020, 10:52 Richard Klingler, <ric...@gm...> wrote: > Good morning (o; > > As I decided to develop a GPIB device based on STM32F MCU I did a first > setup based on a Nucleo-F207ZG board with attached 75160/161 transceivers... > > In my test code I just check for DAV and set NRFD and NDAC accordingly.... > > Interestingly...when I send for example a *IDN? query to my test device, > which doesn't send back any data (not yet ;o), I don't get any errors in > ibterm....so is this normal that ibterm doesn't wait for data and just > closes the communication? > > Currently I just send out the received commands/Data out the USB CDC > device... > > Sending *IDN? I get in my USB console: > > CMD: 40 > CMD: 3F > CMD: 25 > DAT: * > DAT: I > DAT: D > DAT: N > DAT: ? > CMD: 3F > CMD: 20 > CMD: 45 > > Or does it misread EOI and therefore closes the communication? > > > thanks in advance > richard > > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Richard K. <ric...@gm...> - 2020-06-18 08:52:11
|
Good morning (o; As I decided to develop a GPIB device based on STM32F MCU I did a first setup based on a Nucleo-F207ZG board with attached 75160/161 transceivers... In my test code I just check for DAV and set NRFD and NDAC accordingly.... Interestingly...when I send for example a *IDN? query to my test device, which doesn't send back any data (not yet ;o), I don't get any errors in ibterm....so is this normal that ibterm doesn't wait for data and just closes the communication? Currently I just send out the received commands/Data out the USB CDC device... Sending *IDN? I get in my USB console: CMD: 40 CMD: 3F CMD: 25 DAT: * DAT: I DAT: D DAT: N DAT: ? CMD: 3F CMD: 20 CMD: 45 Or does it misread EOI and therefore closes the communication? thanks in advance richard |
|
From: dave p. <dpe...@gm...> - 2020-06-16 06:46:50
|
Hello Alan, The 4.3.3 package should work just fine. As Søren said the GPIB version numbers are independent of the Linux kernel version numbers. The 4.3.3 package works with all Linux versions up to 5.4.39. cheers, -Dave On Tue, 16 Jun 2020 at 06:36, Alan Kardec Mota da Cunha <ka...@ho...> wrote: > Hello, my name is Alan, currently I'm making a final work to conclude > college, which I'll use GPIB on a Raspberry Pi 3 Model B. > I saw that the last file posted is for 4.3.3 kernel, at this moment my > raspbian is 4.19, so my doubt is, must I install the package for 4.1.0 or > this last package will work as well? > > > Thanks in advance, > Alan > [image: Sent from Mailspring] > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Søren K. <sq...@dt...> - 2020-06-16 04:57:36
|
Hi Allan. As far as I understand it, then the kernel version and the gpib-version does not have to be equal, I think it is only a coincidence that they are so close. But if you are in doubt, then make a copy of you SD card for the Pi and try one of them, if it works, then great, and if not, reload the Pi from the copy and try an other version of the gpib :-) (However, do remember to make a correct copy using a tool for copying complete file systems, not just cp...) Best regards Søren Koch On 6/16/20 6:35 AM, Alan Kardec Mota da Cunha wrote: > Hello, my name is Alan, currently I'm making a final work to conclude > college, which I'll use GPIB on a Raspberry Pi 3 Model B. > I saw that the last file posted is for 4.3.3 kernel, at this moment my > raspbian is 4.19, so my doubt is, must I install the package for > 4.1.0 or this last package will work as well? > > > Thanks in advance, > Alan > Sent from Mailspring > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general -- Søren Koch Senior Development Engineer Mob: +45 21325247 sq...@dt... Fysikvej Building 310 2800 Kgs. Lyngby |
|
From: Alan K. M. da C. <ka...@ho...> - 2020-06-16 04:35:47
|
Hello, my name is Alan, currently I'm making a final work to conclude college, which I'll use GPIB on a Raspberry Pi 3 Model B. I saw that the last file posted is for 4.3.3 kernel, at this moment my raspbian is 4.19, so my doubt is, must I install the package for 4.1.0 or this last package will work as well? Thanks in advance, Alan |
|
From: Mitchell C. <mo....@gm...> - 2020-04-09 03:24:30
|
Thanks for the updates, this works for me now. On Wed, Apr 8, 2020 at 8:01 AM dave penkler <dpe...@gm...> wrote: > There was an issue with the previous tip since the option was not being > passed down to the individual module compilation steps. > The SVN has been updated accordingly. Please check the INSTALL files in > both the user and kernel directories regarding PCMCIA support and let > know if you have any issues. > You can see the changes here > <https://sourceforge.net/p/linux-gpib/code/1873/>. > Thanks, > -Dave > > On Wed, 8 Apr 2020 at 10:28, Roel Jordans <r.j...@sc...> wrote: > >> Hi Mitchell, >> >> Then probably a make clean before your new make should have helped. >> Since there were no changes to the files themselves (except for the >> Makefile) make typically will assume that the old build result is still >> valid. >> >> Cheers, >> Roel >> >> -----Original Message----- >> From: Mitchell Clement <mo....@gm...> >> To: dave penkler <dpe...@gm...> >> Cc: lin...@li... >> Subject: Re: [Linux-gpib-general] PCMCIA GPIB help with linux-gpib- >> 4.3.0 >> Date: Tue, 7 Apr 2020 13:18:16 -0700 >> >> Dave, >> >> Thanks for the tip. I changed the Makefile per your instructions, but >> that didn't seem to work. As a workaround, I went into the drive >> directory and commented out all of the #ifdef(GPIB_CONFIG_PCMCIA) lines >> and built the kernel and that worksI think. After doing $ sudo >> gpib_config --minor 0, the output of $ dmesg | grep gpib, shows: >> [ 16.730076] gpib_common: loading out-of-tree module taints kernel. >> [ 16.733090] gpib_common: module verification failed: signature >> and/or required key missing - tainting kernel >> [ 16.764816] gpib: registered ni_isa interface >> [ 16.767173] gpib: registered ni_isa_accel interface >> [ 16.768955] gpib: registered ni_nat4882_isa interface >> [ 16.770737] gpib: registered ni_nat4882_isa_accel interface >> [ 16.772486] gpib: registered ni_nec_isa interface >> [ 16.774209] gpib: registered ni_nec_isa_accel interface >> [ 16.775886] gpib: registered ni_pci interface >> [ 16.777530] gpib: registered ni_pci_accel interface >> [ 16.779148] gpib: registered ni_pcmcia interface >> [ 16.780691] gpib: registered ni_pcmcia_accel interface >> [ 16.783782] ni_gpib_probe(0xffff8b7ef6a83800) >> [ 16.783785] ni_gpib_config(0xffff8b7ef6a83800) >> [ 151.273150] gpib debug: pid 9313, gpib: opening minor 0 >> [ 151.278597] gpib debug: pid 9313, gpib: request module returned 256 >> [ 151.278619] gpib debug: pid 9313, minor 0, ioctl 39, interface=, >> use=0, onl=0 >> [ 151.278628] gpib debug: pid 9313, minor 0, ioctl 24, interface=, >> use=0, onl=0 >> [ 151.278634] gpib debug: pid 9313, minor 0, ioctl 21, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278638] gpib debug: pid 9313, minor 0, ioctl 22, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278643] gpib debug: pid 9313, minor 0, ioctl 23, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278647] gpib debug: pid 9313, minor 0, ioctl 15, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278650] gpib debug: set primary addr to 0 >> [ 151.278654] gpib debug: pid 9313, minor 0, ioctl 16, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278656] gpib debug: set secondary addr to -96 >> [ 151.278660] gpib debug: pid 9313, minor 0, ioctl 32, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278666] gpib debug: pid 9313, minor 0, ioctl 43, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278682] gpib debug: pid 9313, minor 0, ioctl 44, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.278739] gpib debug: pid 9313, minor 0, ioctl 39, >> interface=ni_pcmcia, use=1, onl=0 >> [ 151.279068] gpib debug: gpib: board online >> [ 151.279505] gpib debug: pid 9313, gpib: opening minor 0 >> [ 151.279514] gpib debug: pid 9313, minor 0, ioctl 26, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279517] gpib debug: pid 9313, locked board 0 mutex >> [ 151.279522] gpib debug: pid 9313, minor 0, ioctl 34, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279537] gpib debug: pid 9313, minor 0, ioctl 5, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279554] gpib debug: pid 9313, minor 0, ioctl 26, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279557] gpib debug: pid 9313, unlocked board 0 mutex >> [ 151.279565] gpib debug: pid 9313, minor 0, ioctl 26, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279567] gpib debug: pid 9313, locked board 0 mutex >> [ 151.279572] gpib debug: pid 9313, minor 0, ioctl 29, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279576] gpib debug: pid 9313, minor 0, ioctl 9, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279579] gpib debug: sending interface clear >> [ 151.279623] gpib debug: minor 0, isr1 0x0, imr1 0xbf, isr2 0x89, >> imr2 0x4f >> [ 151.279693] gpib debug: pid 9313, minor 0, ioctl 5, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279707] gpib debug: pid 9313, minor 0, ioctl 26, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279710] gpib debug: pid 9313, unlocked board 0 mutex >> [ 151.279716] gpib debug: pid 9313, minor 0, ioctl 26, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279719] gpib debug: pid 9313, locked board 0 mutex >> [ 151.279723] gpib debug: pid 9313, minor 0, ioctl 29, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279727] gpib debug: pid 9313, minor 0, ioctl 10, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279737] gpib debug: pid 9313, minor 0, ioctl 5, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279751] gpib debug: pid 9313, minor 0, ioctl 26, >> interface=ni_pcmcia, use=2, onl=1 >> [ 151.279753] gpib debug: pid 9313, unlocked board 0 mutex >> [ 151.279759] gpib debug: pid 9313, gpib: closing minor 0 >> [ 151.279948] gpib debug: pid 9313, gpib: closing minor 0 >> [ 151.285747] gpib debug: entering autospoll thread >> >> Thanks. >> >> Mitchell >> >> On Tue, Apr 7, 2020 at 8:27 AM dave penkler <dpe...@gm...> wrote: >> > Hi Mitchell, >> > The kernel module for ni_pcmcia and ni_pcmcia_accel is the tnt4882.ko >> > module which seems to exist from your dmesg. >> > We forgot to put a GPIB_CONFIG_PCMCIA config option into the Makefile >> > when autoconf was dropped for the kernel modules build. >> > Please edit the "all" target in the top level Makefile in the linux- >> > gpib-kernel-4.3.0 directory to look like so: >> > all: >> > -$(MAKE) -C $(LINUX_SRCDIR) V=$(VERBOSE) modules \ >> > M="$(GPIB_SRCDIR)/drivers/gpib" \ >> > GPIB_TOP_DIR=$(GPIB_SRCDIR) \ >> > CONFIG_GPIB_ISA="$(ENABLE_ISA)" \ >> > HAVE_DEV_OF_NODE=$(HAVE_DEV_OF_NODE) \ >> > GPIB_CONFIG_KERNEL_DEBUG=$(GPIB_DEBUG) \ >> > GPIB_CONFIG_PCMCIA=1 >> > >> > Rebuild and install the kernel modules with the above modification >> > and reboot to test. >> > BTW: The gpib_config command should be: gpib_config --minor 0. >> > Cheers, >> > -Dave >> > >> > On Tue, 7 Apr 2020 at 02:02, Mitchell Clement <mo....@gm...> >> > wrote: >> > > Hi, I'm new to the Linux-GPIB community and am hoping to get some >> > > guidance on getting my National Instruments PCMCIA-GPIB card >> > > working with linux-gpib-4.3.0. >> > > >> > > TL;DR: Are there better instructions for getting PCMCIA cards to >> > > work with linux-gpib than is what is contained in "linux-gpib-user- >> > > 4.3.0/INSTALL"? >> > > >> > > Full details: >> > > I am running CentOS 7.7.1908, with a custom kernel (3.10.0- >> > > 1062.18.1.rt56.1044.el7.x86_64). I have successfully built the >> > > kernel driver and installed the user space package. The >> > > instructions contained in the linux-gpib-user-4.3.0/INSTALL file >> > > appear to be very outdated for PCMCIA, as it makes reference to the >> > > cardmgr daemon (as far as I know cardmgr was replaced by pccardctl >> > > and lspcmcia). I edited the "board_type" field in "/etc/gpib.conf" >> > > to "ni_pcmcia". As instructed, I copied the etc/pcmcia subdirectory >> > > to /etc/pcmcia. I am assuming the script "/etc/pcmcia/linux-gpib- >> > > pcmcia" is supposed to be run somehow, when a pcmcia card is >> > > inserted, but I am unable to get it to run from the terminal. I am >> > > able to insert the kernel module drivers: gpib_common, nec7210, >> > > tnt4882, but when try issuing the command: >> > > $ sudo gpib_config 0 >> > > , I get: >> > > failed to configure boardtype: ni_pcmcia >> > > failed to configure board >> > > main: Invalid argument >> > > I checked the output of dmesg after inserting the drivers and see >> > > that the following interfaces get registered: >> > > [ 1495.671213] gpib: registered ni_isa interface >> > > [ 1495.671220] gpib: registered ni_isa_accel interface >> > > [ 1495.671223] gpib: registered ni_nat4882_isa interface >> > > [ 1495.671225] gpib: registered ni_nat4882_isa_accel interface >> > > [ 1495.671227] gpib: registered ni_nec_isa interface >> > > [ 1495.671229] gpib: registered ni_nec_isa_accel interface >> > > [ 1495.671231] gpib: registered ni_pci interface >> > > [ 1495.671233] gpib: registered ni_pci_accel interface >> > > ni_pcmcia is nowhere to be found. Looking in the tnt4882 driver >> > > source, I see that all the above listed interfaces have definitions >> > > in "tnt4882_init.c" which I assume contains all the initialization >> > > routines when the drive module is inserted in the kernel. The >> > > pcmcia init routines are found in "tnt4882_cs.c". It seems that >> > > PCMCIA is a dying bus interface and am wondering if maybe the >> > > ni_pcmcia routines should have been added to "tnt4882_init.c" some >> > > time ago or am I doing something wrong? Thanks for the help and >> > > reading my lengthy email. >> > > >> > > Mitchell >> > > _______________________________________________ >> > > 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 >> >> |
|
From: dave p. <dpe...@gm...> - 2020-04-08 15:01:27
|
There was an issue with the previous tip since the option was not being passed down to the individual module compilation steps. The SVN has been updated accordingly. Please check the INSTALL files in both the user and kernel directories regarding PCMCIA support and let know if you have any issues. You can see the changes here <https://sourceforge.net/p/linux-gpib/code/1873/>. Thanks, -Dave On Wed, 8 Apr 2020 at 10:28, Roel Jordans <r.j...@sc...> wrote: > Hi Mitchell, > > Then probably a make clean before your new make should have helped. > Since there were no changes to the files themselves (except for the > Makefile) make typically will assume that the old build result is still > valid. > > Cheers, > Roel > > -----Original Message----- > From: Mitchell Clement <mo....@gm...> > To: dave penkler <dpe...@gm...> > Cc: lin...@li... > Subject: Re: [Linux-gpib-general] PCMCIA GPIB help with linux-gpib- > 4.3.0 > Date: Tue, 7 Apr 2020 13:18:16 -0700 > > Dave, > > Thanks for the tip. I changed the Makefile per your instructions, but > that didn't seem to work. As a workaround, I went into the drive > directory and commented out all of the #ifdef(GPIB_CONFIG_PCMCIA) lines > and built the kernel and that worksI think. After doing $ sudo > gpib_config --minor 0, the output of $ dmesg | grep gpib, shows: > [ 16.730076] gpib_common: loading out-of-tree module taints kernel. > [ 16.733090] gpib_common: module verification failed: signature > and/or required key missing - tainting kernel > [ 16.764816] gpib: registered ni_isa interface > [ 16.767173] gpib: registered ni_isa_accel interface > [ 16.768955] gpib: registered ni_nat4882_isa interface > [ 16.770737] gpib: registered ni_nat4882_isa_accel interface > [ 16.772486] gpib: registered ni_nec_isa interface > [ 16.774209] gpib: registered ni_nec_isa_accel interface > [ 16.775886] gpib: registered ni_pci interface > [ 16.777530] gpib: registered ni_pci_accel interface > [ 16.779148] gpib: registered ni_pcmcia interface > [ 16.780691] gpib: registered ni_pcmcia_accel interface > [ 16.783782] ni_gpib_probe(0xffff8b7ef6a83800) > [ 16.783785] ni_gpib_config(0xffff8b7ef6a83800) > [ 151.273150] gpib debug: pid 9313, gpib: opening minor 0 > [ 151.278597] gpib debug: pid 9313, gpib: request module returned 256 > [ 151.278619] gpib debug: pid 9313, minor 0, ioctl 39, interface=, > use=0, onl=0 > [ 151.278628] gpib debug: pid 9313, minor 0, ioctl 24, interface=, > use=0, onl=0 > [ 151.278634] gpib debug: pid 9313, minor 0, ioctl 21, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278638] gpib debug: pid 9313, minor 0, ioctl 22, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278643] gpib debug: pid 9313, minor 0, ioctl 23, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278647] gpib debug: pid 9313, minor 0, ioctl 15, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278650] gpib debug: set primary addr to 0 > [ 151.278654] gpib debug: pid 9313, minor 0, ioctl 16, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278656] gpib debug: set secondary addr to -96 > [ 151.278660] gpib debug: pid 9313, minor 0, ioctl 32, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278666] gpib debug: pid 9313, minor 0, ioctl 43, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278682] gpib debug: pid 9313, minor 0, ioctl 44, > interface=ni_pcmcia, use=1, onl=0 > [ 151.278739] gpib debug: pid 9313, minor 0, ioctl 39, > interface=ni_pcmcia, use=1, onl=0 > [ 151.279068] gpib debug: gpib: board online > [ 151.279505] gpib debug: pid 9313, gpib: opening minor 0 > [ 151.279514] gpib debug: pid 9313, minor 0, ioctl 26, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279517] gpib debug: pid 9313, locked board 0 mutex > [ 151.279522] gpib debug: pid 9313, minor 0, ioctl 34, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279537] gpib debug: pid 9313, minor 0, ioctl 5, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279554] gpib debug: pid 9313, minor 0, ioctl 26, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279557] gpib debug: pid 9313, unlocked board 0 mutex > [ 151.279565] gpib debug: pid 9313, minor 0, ioctl 26, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279567] gpib debug: pid 9313, locked board 0 mutex > [ 151.279572] gpib debug: pid 9313, minor 0, ioctl 29, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279576] gpib debug: pid 9313, minor 0, ioctl 9, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279579] gpib debug: sending interface clear > [ 151.279623] gpib debug: minor 0, isr1 0x0, imr1 0xbf, isr2 0x89, > imr2 0x4f > [ 151.279693] gpib debug: pid 9313, minor 0, ioctl 5, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279707] gpib debug: pid 9313, minor 0, ioctl 26, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279710] gpib debug: pid 9313, unlocked board 0 mutex > [ 151.279716] gpib debug: pid 9313, minor 0, ioctl 26, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279719] gpib debug: pid 9313, locked board 0 mutex > [ 151.279723] gpib debug: pid 9313, minor 0, ioctl 29, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279727] gpib debug: pid 9313, minor 0, ioctl 10, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279737] gpib debug: pid 9313, minor 0, ioctl 5, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279751] gpib debug: pid 9313, minor 0, ioctl 26, > interface=ni_pcmcia, use=2, onl=1 > [ 151.279753] gpib debug: pid 9313, unlocked board 0 mutex > [ 151.279759] gpib debug: pid 9313, gpib: closing minor 0 > [ 151.279948] gpib debug: pid 9313, gpib: closing minor 0 > [ 151.285747] gpib debug: entering autospoll thread > > Thanks. > > Mitchell > > On Tue, Apr 7, 2020 at 8:27 AM dave penkler <dpe...@gm...> wrote: > > Hi Mitchell, > > The kernel module for ni_pcmcia and ni_pcmcia_accel is the tnt4882.ko > > module which seems to exist from your dmesg. > > We forgot to put a GPIB_CONFIG_PCMCIA config option into the Makefile > > when autoconf was dropped for the kernel modules build. > > Please edit the "all" target in the top level Makefile in the linux- > > gpib-kernel-4.3.0 directory to look like so: > > all: > > -$(MAKE) -C $(LINUX_SRCDIR) V=$(VERBOSE) modules \ > > M="$(GPIB_SRCDIR)/drivers/gpib" \ > > GPIB_TOP_DIR=$(GPIB_SRCDIR) \ > > CONFIG_GPIB_ISA="$(ENABLE_ISA)" \ > > HAVE_DEV_OF_NODE=$(HAVE_DEV_OF_NODE) \ > > GPIB_CONFIG_KERNEL_DEBUG=$(GPIB_DEBUG) \ > > GPIB_CONFIG_PCMCIA=1 > > > > Rebuild and install the kernel modules with the above modification > > and reboot to test. > > BTW: The gpib_config command should be: gpib_config --minor 0. > > Cheers, > > -Dave > > > > On Tue, 7 Apr 2020 at 02:02, Mitchell Clement <mo....@gm...> > > wrote: > > > Hi, I'm new to the Linux-GPIB community and am hoping to get some > > > guidance on getting my National Instruments PCMCIA-GPIB card > > > working with linux-gpib-4.3.0. > > > > > > TL;DR: Are there better instructions for getting PCMCIA cards to > > > work with linux-gpib than is what is contained in "linux-gpib-user- > > > 4.3.0/INSTALL"? > > > > > > Full details: > > > I am running CentOS 7.7.1908, with a custom kernel (3.10.0- > > > 1062.18.1.rt56.1044.el7.x86_64). I have successfully built the > > > kernel driver and installed the user space package. The > > > instructions contained in the linux-gpib-user-4.3.0/INSTALL file > > > appear to be very outdated for PCMCIA, as it makes reference to the > > > cardmgr daemon (as far as I know cardmgr was replaced by pccardctl > > > and lspcmcia). I edited the "board_type" field in "/etc/gpib.conf" > > > to "ni_pcmcia". As instructed, I copied the etc/pcmcia subdirectory > > > to /etc/pcmcia. I am assuming the script "/etc/pcmcia/linux-gpib- > > > pcmcia" is supposed to be run somehow, when a pcmcia card is > > > inserted, but I am unable to get it to run from the terminal. I am > > > able to insert the kernel module drivers: gpib_common, nec7210, > > > tnt4882, but when try issuing the command: > > > $ sudo gpib_config 0 > > > , I get: > > > failed to configure boardtype: ni_pcmcia > > > failed to configure board > > > main: Invalid argument > > > I checked the output of dmesg after inserting the drivers and see > > > that the following interfaces get registered: > > > [ 1495.671213] gpib: registered ni_isa interface > > > [ 1495.671220] gpib: registered ni_isa_accel interface > > > [ 1495.671223] gpib: registered ni_nat4882_isa interface > > > [ 1495.671225] gpib: registered ni_nat4882_isa_accel interface > > > [ 1495.671227] gpib: registered ni_nec_isa interface > > > [ 1495.671229] gpib: registered ni_nec_isa_accel interface > > > [ 1495.671231] gpib: registered ni_pci interface > > > [ 1495.671233] gpib: registered ni_pci_accel interface > > > ni_pcmcia is nowhere to be found. Looking in the tnt4882 driver > > > source, I see that all the above listed interfaces have definitions > > > in "tnt4882_init.c" which I assume contains all the initialization > > > routines when the drive module is inserted in the kernel. The > > > pcmcia init routines are found in "tnt4882_cs.c". It seems that > > > PCMCIA is a dying bus interface and am wondering if maybe the > > > ni_pcmcia routines should have been added to "tnt4882_init.c" some > > > time ago or am I doing something wrong? Thanks for the help and > > > reading my lengthy email. > > > > > > Mitchell > > > _______________________________________________ > > > 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 > > |
|
From: Roel J. <r.j...@sc...> - 2020-04-08 08:42:01
|
Hi Mitchell, Then probably a make clean before your new make should have helped. Since there were no changes to the files themselves (except for the Makefile) make typically will assume that the old build result is still valid. Cheers, Roel -----Original Message----- From: Mitchell Clement <mo....@gm...> To: dave penkler <dpe...@gm...> Cc: lin...@li... Subject: Re: [Linux-gpib-general] PCMCIA GPIB help with linux-gpib- 4.3.0 Date: Tue, 7 Apr 2020 13:18:16 -0700 Dave, Thanks for the tip. I changed the Makefile per your instructions, but that didn't seem to work. As a workaround, I went into the drive directory and commented out all of the #ifdef(GPIB_CONFIG_PCMCIA) lines and built the kernel and that worksI think. After doing $ sudo gpib_config --minor 0, the output of $ dmesg | grep gpib, shows: [ 16.730076] gpib_common: loading out-of-tree module taints kernel. [ 16.733090] gpib_common: module verification failed: signature and/or required key missing - tainting kernel [ 16.764816] gpib: registered ni_isa interface [ 16.767173] gpib: registered ni_isa_accel interface [ 16.768955] gpib: registered ni_nat4882_isa interface [ 16.770737] gpib: registered ni_nat4882_isa_accel interface [ 16.772486] gpib: registered ni_nec_isa interface [ 16.774209] gpib: registered ni_nec_isa_accel interface [ 16.775886] gpib: registered ni_pci interface [ 16.777530] gpib: registered ni_pci_accel interface [ 16.779148] gpib: registered ni_pcmcia interface [ 16.780691] gpib: registered ni_pcmcia_accel interface [ 16.783782] ni_gpib_probe(0xffff8b7ef6a83800) [ 16.783785] ni_gpib_config(0xffff8b7ef6a83800) [ 151.273150] gpib debug: pid 9313, gpib: opening minor 0 [ 151.278597] gpib debug: pid 9313, gpib: request module returned 256 [ 151.278619] gpib debug: pid 9313, minor 0, ioctl 39, interface=, use=0, onl=0 [ 151.278628] gpib debug: pid 9313, minor 0, ioctl 24, interface=, use=0, onl=0 [ 151.278634] gpib debug: pid 9313, minor 0, ioctl 21, interface=ni_pcmcia, use=1, onl=0 [ 151.278638] gpib debug: pid 9313, minor 0, ioctl 22, interface=ni_pcmcia, use=1, onl=0 [ 151.278643] gpib debug: pid 9313, minor 0, ioctl 23, interface=ni_pcmcia, use=1, onl=0 [ 151.278647] gpib debug: pid 9313, minor 0, ioctl 15, interface=ni_pcmcia, use=1, onl=0 [ 151.278650] gpib debug: set primary addr to 0 [ 151.278654] gpib debug: pid 9313, minor 0, ioctl 16, interface=ni_pcmcia, use=1, onl=0 [ 151.278656] gpib debug: set secondary addr to -96 [ 151.278660] gpib debug: pid 9313, minor 0, ioctl 32, interface=ni_pcmcia, use=1, onl=0 [ 151.278666] gpib debug: pid 9313, minor 0, ioctl 43, interface=ni_pcmcia, use=1, onl=0 [ 151.278682] gpib debug: pid 9313, minor 0, ioctl 44, interface=ni_pcmcia, use=1, onl=0 [ 151.278739] gpib debug: pid 9313, minor 0, ioctl 39, interface=ni_pcmcia, use=1, onl=0 [ 151.279068] gpib debug: gpib: board online [ 151.279505] gpib debug: pid 9313, gpib: opening minor 0 [ 151.279514] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279517] gpib debug: pid 9313, locked board 0 mutex [ 151.279522] gpib debug: pid 9313, minor 0, ioctl 34, interface=ni_pcmcia, use=2, onl=1 [ 151.279537] gpib debug: pid 9313, minor 0, ioctl 5, interface=ni_pcmcia, use=2, onl=1 [ 151.279554] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279557] gpib debug: pid 9313, unlocked board 0 mutex [ 151.279565] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279567] gpib debug: pid 9313, locked board 0 mutex [ 151.279572] gpib debug: pid 9313, minor 0, ioctl 29, interface=ni_pcmcia, use=2, onl=1 [ 151.279576] gpib debug: pid 9313, minor 0, ioctl 9, interface=ni_pcmcia, use=2, onl=1 [ 151.279579] gpib debug: sending interface clear [ 151.279623] gpib debug: minor 0, isr1 0x0, imr1 0xbf, isr2 0x89, imr2 0x4f [ 151.279693] gpib debug: pid 9313, minor 0, ioctl 5, interface=ni_pcmcia, use=2, onl=1 [ 151.279707] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279710] gpib debug: pid 9313, unlocked board 0 mutex [ 151.279716] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279719] gpib debug: pid 9313, locked board 0 mutex [ 151.279723] gpib debug: pid 9313, minor 0, ioctl 29, interface=ni_pcmcia, use=2, onl=1 [ 151.279727] gpib debug: pid 9313, minor 0, ioctl 10, interface=ni_pcmcia, use=2, onl=1 [ 151.279737] gpib debug: pid 9313, minor 0, ioctl 5, interface=ni_pcmcia, use=2, onl=1 [ 151.279751] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279753] gpib debug: pid 9313, unlocked board 0 mutex [ 151.279759] gpib debug: pid 9313, gpib: closing minor 0 [ 151.279948] gpib debug: pid 9313, gpib: closing minor 0 [ 151.285747] gpib debug: entering autospoll thread Thanks. Mitchell On Tue, Apr 7, 2020 at 8:27 AM dave penkler <dpe...@gm...> wrote: > Hi Mitchell, > The kernel module for ni_pcmcia and ni_pcmcia_accel is the tnt4882.ko > module which seems to exist from your dmesg. > We forgot to put a GPIB_CONFIG_PCMCIA config option into the Makefile > when autoconf was dropped for the kernel modules build. > Please edit the "all" target in the top level Makefile in the linux- > gpib-kernel-4.3.0 directory to look like so: > all: > -$(MAKE) -C $(LINUX_SRCDIR) V=$(VERBOSE) modules \ > M="$(GPIB_SRCDIR)/drivers/gpib" \ > GPIB_TOP_DIR=$(GPIB_SRCDIR) \ > CONFIG_GPIB_ISA="$(ENABLE_ISA)" \ > HAVE_DEV_OF_NODE=$(HAVE_DEV_OF_NODE) \ > GPIB_CONFIG_KERNEL_DEBUG=$(GPIB_DEBUG) \ > GPIB_CONFIG_PCMCIA=1 > > Rebuild and install the kernel modules with the above modification > and reboot to test. > BTW: The gpib_config command should be: gpib_config --minor 0. > Cheers, > -Dave > > On Tue, 7 Apr 2020 at 02:02, Mitchell Clement <mo....@gm...> > wrote: > > Hi, I'm new to the Linux-GPIB community and am hoping to get some > > guidance on getting my National Instruments PCMCIA-GPIB card > > working with linux-gpib-4.3.0. > > > > TL;DR: Are there better instructions for getting PCMCIA cards to > > work with linux-gpib than is what is contained in "linux-gpib-user- > > 4.3.0/INSTALL"? > > > > Full details: > > I am running CentOS 7.7.1908, with a custom kernel (3.10.0- > > 1062.18.1.rt56.1044.el7.x86_64). I have successfully built the > > kernel driver and installed the user space package. The > > instructions contained in the linux-gpib-user-4.3.0/INSTALL file > > appear to be very outdated for PCMCIA, as it makes reference to the > > cardmgr daemon (as far as I know cardmgr was replaced by pccardctl > > and lspcmcia). I edited the "board_type" field in "/etc/gpib.conf" > > to "ni_pcmcia". As instructed, I copied the etc/pcmcia subdirectory > > to /etc/pcmcia. I am assuming the script "/etc/pcmcia/linux-gpib- > > pcmcia" is supposed to be run somehow, when a pcmcia card is > > inserted, but I am unable to get it to run from the terminal. I am > > able to insert the kernel module drivers: gpib_common, nec7210, > > tnt4882, but when try issuing the command: > > $ sudo gpib_config 0 > > , I get: > > failed to configure boardtype: ni_pcmcia > > failed to configure board > > main: Invalid argument > > I checked the output of dmesg after inserting the drivers and see > > that the following interfaces get registered: > > [ 1495.671213] gpib: registered ni_isa interface > > [ 1495.671220] gpib: registered ni_isa_accel interface > > [ 1495.671223] gpib: registered ni_nat4882_isa interface > > [ 1495.671225] gpib: registered ni_nat4882_isa_accel interface > > [ 1495.671227] gpib: registered ni_nec_isa interface > > [ 1495.671229] gpib: registered ni_nec_isa_accel interface > > [ 1495.671231] gpib: registered ni_pci interface > > [ 1495.671233] gpib: registered ni_pci_accel interface > > ni_pcmcia is nowhere to be found. Looking in the tnt4882 driver > > source, I see that all the above listed interfaces have definitions > > in "tnt4882_init.c" which I assume contains all the initialization > > routines when the drive module is inserted in the kernel. The > > pcmcia init routines are found in "tnt4882_cs.c". It seems that > > PCMCIA is a dying bus interface and am wondering if maybe the > > ni_pcmcia routines should have been added to "tnt4882_init.c" some > > time ago or am I doing something wrong? Thanks for the help and > > reading my lengthy email. > > > > Mitchell > > _______________________________________________ > > 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 |
|
From: Mitchell C. <mo....@gm...> - 2020-04-07 20:18:38
|
Dave, Thanks for the tip. I changed the Makefile per your instructions, but that didn't seem to work. As a workaround, I went into the drive directory and commented out all of the #ifdef(GPIB_CONFIG_PCMCIA) lines and built the kernel and that worksI think. After doing $ sudo gpib_config --minor 0, the output of $ dmesg | grep gpib, shows: [ 16.730076] gpib_common: loading out-of-tree module taints kernel. [ 16.733090] gpib_common: module verification failed: signature and/or required key missing - tainting kernel [ 16.764816] gpib: registered ni_isa interface [ 16.767173] gpib: registered ni_isa_accel interface [ 16.768955] gpib: registered ni_nat4882_isa interface [ 16.770737] gpib: registered ni_nat4882_isa_accel interface [ 16.772486] gpib: registered ni_nec_isa interface [ 16.774209] gpib: registered ni_nec_isa_accel interface [ 16.775886] gpib: registered ni_pci interface [ 16.777530] gpib: registered ni_pci_accel interface [ 16.779148] gpib: registered ni_pcmcia interface [ 16.780691] gpib: registered ni_pcmcia_accel interface [ 16.783782] ni_gpib_probe(0xffff8b7ef6a83800) [ 16.783785] ni_gpib_config(0xffff8b7ef6a83800) [ 151.273150] gpib debug: pid 9313, gpib: opening minor 0 [ 151.278597] gpib debug: pid 9313, gpib: request module returned 256 [ 151.278619] gpib debug: pid 9313, minor 0, ioctl 39, interface=, use=0, onl=0 [ 151.278628] gpib debug: pid 9313, minor 0, ioctl 24, interface=, use=0, onl=0 [ 151.278634] gpib debug: pid 9313, minor 0, ioctl 21, interface=ni_pcmcia, use=1, onl=0 [ 151.278638] gpib debug: pid 9313, minor 0, ioctl 22, interface=ni_pcmcia, use=1, onl=0 [ 151.278643] gpib debug: pid 9313, minor 0, ioctl 23, interface=ni_pcmcia, use=1, onl=0 [ 151.278647] gpib debug: pid 9313, minor 0, ioctl 15, interface=ni_pcmcia, use=1, onl=0 [ 151.278650] gpib debug: set primary addr to 0 [ 151.278654] gpib debug: pid 9313, minor 0, ioctl 16, interface=ni_pcmcia, use=1, onl=0 [ 151.278656] gpib debug: set secondary addr to -96 [ 151.278660] gpib debug: pid 9313, minor 0, ioctl 32, interface=ni_pcmcia, use=1, onl=0 [ 151.278666] gpib debug: pid 9313, minor 0, ioctl 43, interface=ni_pcmcia, use=1, onl=0 [ 151.278682] gpib debug: pid 9313, minor 0, ioctl 44, interface=ni_pcmcia, use=1, onl=0 [ 151.278739] gpib debug: pid 9313, minor 0, ioctl 39, interface=ni_pcmcia, use=1, onl=0 [ 151.279068] gpib debug: gpib: board online [ 151.279505] gpib debug: pid 9313, gpib: opening minor 0 [ 151.279514] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279517] gpib debug: pid 9313, locked board 0 mutex [ 151.279522] gpib debug: pid 9313, minor 0, ioctl 34, interface=ni_pcmcia, use=2, onl=1 [ 151.279537] gpib debug: pid 9313, minor 0, ioctl 5, interface=ni_pcmcia, use=2, onl=1 [ 151.279554] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279557] gpib debug: pid 9313, unlocked board 0 mutex [ 151.279565] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279567] gpib debug: pid 9313, locked board 0 mutex [ 151.279572] gpib debug: pid 9313, minor 0, ioctl 29, interface=ni_pcmcia, use=2, onl=1 [ 151.279576] gpib debug: pid 9313, minor 0, ioctl 9, interface=ni_pcmcia, use=2, onl=1 [ 151.279579] gpib debug: sending interface clear [ 151.279623] gpib debug: minor 0, isr1 0x0, imr1 0xbf, isr2 0x89, imr2 0x4f [ 151.279693] gpib debug: pid 9313, minor 0, ioctl 5, interface=ni_pcmcia, use=2, onl=1 [ 151.279707] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279710] gpib debug: pid 9313, unlocked board 0 mutex [ 151.279716] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279719] gpib debug: pid 9313, locked board 0 mutex [ 151.279723] gpib debug: pid 9313, minor 0, ioctl 29, interface=ni_pcmcia, use=2, onl=1 [ 151.279727] gpib debug: pid 9313, minor 0, ioctl 10, interface=ni_pcmcia, use=2, onl=1 [ 151.279737] gpib debug: pid 9313, minor 0, ioctl 5, interface=ni_pcmcia, use=2, onl=1 [ 151.279751] gpib debug: pid 9313, minor 0, ioctl 26, interface=ni_pcmcia, use=2, onl=1 [ 151.279753] gpib debug: pid 9313, unlocked board 0 mutex [ 151.279759] gpib debug: pid 9313, gpib: closing minor 0 [ 151.279948] gpib debug: pid 9313, gpib: closing minor 0 [ 151.285747] gpib debug: entering autospoll thread Thanks. Mitchell On Tue, Apr 7, 2020 at 8:27 AM dave penkler <dpe...@gm...> wrote: > Hi Mitchell, > The kernel module for ni_pcmcia and ni_pcmcia_accel is the tnt4882.ko > module which seems to exist from your dmesg. > We forgot to put a GPIB_CONFIG_PCMCIA config option into the Makefile > when autoconf was dropped for the kernel modules build. > Please edit the "all" target in the top level Makefile in the > linux-gpib-kernel-4.3.0 directory to look like so: > all: > -$(MAKE) -C $(LINUX_SRCDIR) V=$(VERBOSE) modules \ > M="$(GPIB_SRCDIR)/drivers/gpib" \ > GPIB_TOP_DIR=$(GPIB_SRCDIR) \ > CONFIG_GPIB_ISA="$(ENABLE_ISA)" \ > HAVE_DEV_OF_NODE=$(HAVE_DEV_OF_NODE) \ > GPIB_CONFIG_KERNEL_DEBUG=$(GPIB_DEBUG) \ > GPIB_CONFIG_PCMCIA=1 > > Rebuild and install the kernel modules with the above modification and > reboot to test. > BTW: The gpib_config command should be: gpib_config --minor 0. > Cheers, > -Dave > > On Tue, 7 Apr 2020 at 02:02, Mitchell Clement <mo....@gm...> > wrote: > >> Hi, I'm new to the Linux-GPIB community and am hoping to get some >> guidance on getting my National Instruments PCMCIA-GPIB card working with >> linux-gpib-4.3.0. >> >> TL;DR: Are there better instructions for getting PCMCIA cards to work >> with linux-gpib than is what is contained in >> "linux-gpib-user-4.3.0/INSTALL"? >> >> Full details: >> I am running CentOS 7.7.1908, with a custom kernel >> (3.10.0-1062.18.1.rt56.1044.el7.x86_64). I have successfully built the >> kernel driver and installed the user space package. The instructions >> contained in the linux-gpib-user-4.3.0/INSTALL file appear to be very >> outdated for PCMCIA, as it makes reference to the cardmgr daemon (as far as >> I know cardmgr was replaced by pccardctl and lspcmcia). I edited the >> "board_type" field in "/etc/gpib.conf" to "ni_pcmcia". As instructed, I >> copied the etc/pcmcia subdirectory to /etc/pcmcia. I am assuming the script >> "/etc/pcmcia/linux-gpib-pcmcia" is supposed to be run somehow, when a >> pcmcia card is inserted, but I am unable to get it to run from the >> terminal. I am able to insert the kernel module drivers: gpib_common, >> nec7210, tnt4882, but when try issuing the command: >> $ sudo gpib_config 0 >> , I get: >> failed to configure boardtype: ni_pcmcia >> failed to configure board >> main: Invalid argument >> I checked the output of dmesg after inserting the drivers and see that >> the following interfaces get registered: >> [ 1495.671213] gpib: registered ni_isa interface >> [ 1495.671220] gpib: registered ni_isa_accel interface >> [ 1495.671223] gpib: registered ni_nat4882_isa interface >> [ 1495.671225] gpib: registered ni_nat4882_isa_accel interface >> [ 1495.671227] gpib: registered ni_nec_isa interface >> [ 1495.671229] gpib: registered ni_nec_isa_accel interface >> [ 1495.671231] gpib: registered ni_pci interface >> [ 1495.671233] gpib: registered ni_pci_accel interface >> ni_pcmcia is nowhere to be found. Looking in the tnt4882 driver source, I >> see that all the above listed interfaces have definitions in >> "tnt4882_init.c" which I assume contains all the initialization routines >> when the drive module is inserted in the kernel. The pcmcia init routines >> are found in "tnt4882_cs.c". It seems that PCMCIA is a dying bus interface >> and am wondering if maybe the ni_pcmcia routines should have been added to >> "tnt4882_init.c" some time ago or am I doing something wrong? Thanks for >> the help and reading my lengthy email. >> >> Mitchell >> _______________________________________________ >> Linux-gpib-general mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general >> > |
5 messages has been excluded from this view by a project administrator.
