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

Re: [Linux-gpib-general] async reads and timeouts

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

 
Well I see from the mailing list that the last reply formatted like a dog's breakfast...I filed a bug report.  This also has the test code..Linux GPIB Support Bugs Linux GPIB Driver package (source) Status: Beta Brought to you by: dpenkler, fmhess


| 
| 
|  | 
Linux GPIB Support Bugs Linux GPIB Driver package (source) Status: B...


 |

 |

 |


Michael

Re: [Linux-gpib-general] async reads and timeouts

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

 I think I found out the problem. (this is a bug in the library)
When you call ibrda, the timeout is not cached by the routine. If you immediately change the timeout following the call, the async process has not yet accessed it and so gets the new (changed) value.
See the example below...  if I delay the change of timeout by 10ms, it works. If I use the same delay but after the timeout change if fails.
The library must cache the timeout when the ibrda or ibwrta call is made (and pass this through to the async process).



[michael@dirac ~]$ ./asyncReadTest 100ms delay AFTER changing timeout for ibwaitGPIB failure waitingGPIB status 8100[michael@dirac ~]$ ./asyncReadTest -b100ms delay BEFORE changing timeout for ibwaitGPIB wait timeout (0.000)GPIB wait timeout (0.010)GPIB wait timeout (0.020)GPIB wait timeout (0.030)GPIB wait timeout (0.040)GPIB read complete (2630 characters)Complete OKGPIB status 2100[michael@dirac ~]$ 



// $ gcc -o asyncReadTest asyncReadTest.c -lgpib

#include <stdio.h>#include <stdlib.h>#include <unistd.h>#include <string.h>
#include <gpib/ib.h>
#define GPIB_CONTROLLER_INDEX 0#define GPIB_DEVICE_PID 16#define ERROR -1#define READ_BUF_SIZE 4000#define TIMEOUT    10.0#define GPIB_SET_EOI 1#define TIMEOUT_10S 10.0#define FALSE 0#define TRUE 1
int main( int argc, char **argv){    int GPIBstatus;    int GPIBdescriptor;    char readBuffer[ READ_BUF_SIZE ];    double timeElapsed = 0.0;        char *sQuery = "OUTPLEAS;";    int bDelayBeforeTimeoutChange = FALSE;
    if( argc > 1 && strcmp( argv[1], "-b" ) == 0 ) {        printf( "100ms delay BEFORE changing timeout for ibwait\n" );     bDelayBeforeTimeoutChange = TRUE;    } else {        printf( "100ms delay AFTER changing timeout for ibwait\n" );     bDelayBeforeTimeoutChange = FALSE;    }            GPIBdescriptor = ibdev( GPIB_CONTROLLER_INDEX, GPIB_DEVICE_PID, 0, T30ms, GPIB_SET_EOI, 0 );        if ( GPIBdescriptor == ERROR ) {        fprintf( stderr, "Failed to open device %d\n",  GPIB_DEVICE_PID);            goto error;    }            GPIBstatus = ibwrt( GPIBdescriptor, sQuery, strlen( sQuery ) );            if ( GPIBstatus & ERR ) {        fprintf( stderr, "GPIB write failure\n");            goto error;    }
    ibtmo( GPIBdescriptor, TNONE );    GPIBstatus = ibrda( GPIBdescriptor, readBuffer, READ_BUF_SIZE );    if ( GPIBstatus & ERR ) {        fprintf( stderr, "GPIB aync read failure\n");            goto error;    }        if( bDelayBeforeTimeoutChange ) {        usleep( 20 * 1000 );        ibtmo( GPIBdescriptor, T10ms );    } else {        ibtmo( GPIBdescriptor, T10ms );        usleep( 20 * 1000 );    }
    do {        // Wait for read completion or timeout        GPIBstatus = ibwait(GPIBdescriptor, TIMO | CMPL | END);        if( (GPIBstatus & TIMO) == 0 ){            if( GPIBstatus & ERR ){                fprintf( stderr, "GPIB failure waiting\n");                goto error;            }                    if( GPIBstatus & CMPL ){                fprintf( stderr, "GPIB read complete (%d characters)\n",  ibcnt);                break;            }                if( GPIBstatus & END ){                fprintf( stderr, "GPIB read complete (EOI) (%d characters)\n",  ibcnt);                break;            }        }        fprintf( stderr, "GPIB wait timeout (%.3f)\n", timeElapsed);        timeElapsed += 0.01;    } while ( (GPIBstatus & TIMO) && timeElapsed < TIMEOUT_10S );           if( timeElapsed < TIMEOUT_10S )        fprintf( stderr, "Complete OK\n" );    else        fprintf( stderr, "10 second timeout\n" );error:    fprintf( stderr, "GPIB status %04x\n",  ibsta);}


    On Thursday, August 4, 2022 at 05:33:17 PM EDT, Frank Mori Hess <fm...@gm...> wrote:  
 
 On Sat, May 7, 2022 at 11:56 AM Michael K via Linux-gpib-general
<lin...@li...> wrote:
> What is the correct way to use ibrda and ibwait together in this scenario ?

It's been a while, but I believe you can set the timeout for the read
before ibrda, then change the timeout for the wait before calling
ibwait.
  

Re: [Linux-gpib-general] Strange errors with NI GPIB-USB-HS

[Jakub L. <la...@vo...>]

Hello

Can you recommend me any further action?

Shouldn't i download the firmware from the eeprom?

I am convinced, that if the device works with windows, it should also 
work with linu-gpib software, sooner or later.

Thanks

Jakub

Re: [Linux-gpib-general] async reads and timeouts

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

On Sat, May 7, 2022 at 11:56 AM Michael K via Linux-gpib-general
<lin...@li...> wrote:
> What is the correct way to use ibrda and ibwait together in this scenario ?

It's been a while, but I believe you can set the timeout for the read
before ibrda, then change the timeout for the wait before calling
ibwait.

Re: [Linux-gpib-general] Strange errors with NI GPIB-USB-HS

[Jakub L. <la...@vo...>]

Hello,


This may be also helpful to track the problem (for someone who udestands it)

from dmesg:
[ 1232.778556] usb 1-1.5.5.2: new high-speed USB device number 12 using 
ehci-pci
[ 1233.147354] usb 1-1.5.5.2: config 1 interface 0 altsetting 0 endpoint 
0x81 has an invalid bInterval 0, changing to 7
[ 1233.148271] usb 1-1.5.5.2: New USB device found, idVendor=3923, 
idProduct=709b, bcdDevice= 1.01
[ 1233.148286] usb 1-1.5.5.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1233.148293] usb 1-1.5.5.2: Product: GPIB-USB-HS
[ 1233.148297] usb 1-1.5.5.2: Manufacturer: National Instruments
[ 1233.148302] usb 1-1.5.5.2: SerialNumber: 019BF124
[ 1233.233856] gpib_common: loading out-of-tree module taints kernel.
[ 1233.233928] gpib_common: module verification failed: signature and/or 
required key missing - tainting kernel
[ 1233.234678] Linux-GPIB 4.3.5 Driver
[ 1233.255319] ni_usb_gpib driver loading
[ 1233.255345] ni_usb_gpib: probe succeeded for path: 
usb-0000:00:1a.0-1.5.5.2
[ 1233.255608] usbcore: registered new interface driver ni_usb_gpib
[ 1233.255612] gpib: registered ni_usb_b interface
[ 2146.665123] ni_usb_gpib: attach
[ 2146.665132] usb 1-1.5.5.2: bus 1 dev num 12 attached to gpib minor 0, 
NI usb interface 0
[ 2146.665394]  product id=0x709b
[ 2146.665625] ni_usb_hs_wait_for_ready: board serial number is 0x19bf124
[ 2146.667378] 
/home/ladmanj/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5/drivers/gpib/ni_usb/ni_usb_gpib.c: 
ni_usb_hs_wait_for_ready: unexpected data: buffer[6]=0x15, expected 0x2, 
0xe or 0xf
[ 2146.667384] ni_usb_dump_raw_block:

[ 2146.667386]  40
[ 2146.667387]   1
[ 2146.667388]   0
[ 2146.667389]   1
[ 2146.667389]  30
[ 2146.667390]   1
[ 2146.667390]  15
[ 2146.667391]   5

[ 2146.667392]   0
[ 2146.667393]   0
[ 2146.667393]  96

Thanks
J.

Re: [Linux-gpib-general] Strange errors with NI GPIB-USB-HS

[Jakub L. <la...@vo...>]

> Hi Jakub,
> The suspicious entry is:
>       bEndpointAddress 0x81 EP 1 IN
>         bmAttributes 3
>           Transfer Type Interrupt
>           Synch Type None
>           Usage Type Data
>         wMaxPacketSize 0x0010 1x 16 bytes
>         bInterval 0
> A genuine card sets the poll interval for the interrupt endpoint to 2 ms: bInterval 2
> We have seen this before a couple of times.
> For the fake cards in the syslog you would see a message from the USB core similar to this:
> usb 2-1.1: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 0, changing to 7
> We have not figured out how the adapter is initialised in windows. For that a trace of the initialisation with usbmon would be required. As you are running windows in qemu this should be relatively easy to do,
> cheers,
> -Dave

Hi Dave,
I have already taken the snapshots of the usb communication with 
wireshark. Both for linux-gpib and for qemu+win10+ni driver.

The files are in the attached archive.

Thank you for looking at it.

Jakub

K tomuto e-mailu je připojen 1 soubor:
* usb-gpib-hs-capture.tar.bz2 (211 KB) uložen na Dropbox: 
https://www.dropbox.com/s/1k2n5acu801toqy/usb-gpib-hs-capture.tar.bz2?dl=0

Re: [Linux-gpib-general] Strange errors with NI GPIB-USB-HS

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

Hi Jakub,
The suspicious entry is:
      bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0010 1x 16 bytes
        bInterval 0
A genuine card sets the poll interval for the interrupt endpoint to 2 ms:
bInterval 2
We have seen this before a couple of times.
For the fake cards in the syslog you would see a message from the USB core
similar to this:
usb 2-1.1: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid
bInterval 0, changing to 7
We have not figured out how the adapter is initialised in windows. For that
a trace of the initialisation with usbmon would be required. As you are
running windows in qemu this should be relatively easy to do,
cheers,
-Dave

On Wed, 3 Aug 2022 at 09:13, Jakub Ladman <la...@vo...> wrote:

> > Hi Jakub,
> > One way to check is to look at: the output of the syslog lines with
> "gpib" in them and the output of "lsusb -d 3923:",  with the adapter
> plugged in.
> > cheers,
> > -dave
>
>
> Hello
>
> First of all, I wrote that the device is working with windows, but the
> part I omitted is - windows is running in qemu on the same machine,
> where I'm testing the linux-gpib.
>
> I can't show you the syslog output, because I have now installed the
> closed source driver and appropriate software from National Instruments
> (which I don't want to use in the end, but I use it now as a sanity
> check only).
>
> The lsusb output is:
> $ lsusb -d 3923: -v
>
> Bus 001 Device 020: ID 3923:709b National Instruments Corp. GPIB-USB-HS
> Couldn't open device, some information will be missing
> Device Descriptor:
>    bLength 18
>    bDescriptorType 1
>    bcdUSB 2.00
>    bDeviceClass 0
>    bDeviceSubClass 0
>    bDeviceProtocol 0
>    bMaxPacketSize0 64
>    idVendor 0x3923 National Instruments Corp.
>    idProduct 0x709b GPIB-USB-HS
>    bcdDevice 1.01
>    iManufacturer 1 National Instruments
>    iProduct 2 GPIB-USB-HS
>    iSerial 3 019BF124
>    bNumConfigurations 1
>    Configuration Descriptor:
>      bLength 9
>      bDescriptorType 2
>      wTotalLength 0x0035
>      bNumInterfaces 1
>      bConfigurationValue 1
>      iConfiguration 0
>      bmAttributes 0x80
>        (Bus Powered)
>      MaxPower 500mA
>      Interface Descriptor:
>        bLength 9
>        bDescriptorType 4
>        bInterfaceNumber 0
>        bAlternateSetting 0
>        bNumEndpoints 5
>        bInterfaceClass 255 Vendor Specific Class
>        bInterfaceSubClass 0
>        bInterfaceProtocol 0
>        iInterface 0
>        Endpoint Descriptor:
>          bLength 7
>          bDescriptorType 5
>          bEndpointAddress 0x02 EP 2 OUT
>          bmAttributes 2
>            Transfer Type Bulk
>            Synch Type None
>            Usage Type Data
>          wMaxPacketSize 0x0200 1x 512 bytes
>          bInterval 0
>        Endpoint Descriptor:
>          bLength 7
>          bDescriptorType 5
>          bEndpointAddress 0x06 EP 6 OUT
>          bmAttributes 2
>            Transfer Type Bulk
>            Synch Type None
>            Usage Type Data
>          wMaxPacketSize 0x0200 1x 512 bytes
>          bInterval 0
>        Endpoint Descriptor:
>          bLength 7
>          bDescriptorType 5
>          bEndpointAddress 0x81 EP 1 IN
>          bmAttributes 3
>            Transfer Type Interrupt
>            Synch Type None
>            Usage Type Data
>          wMaxPacketSize 0x0010 1x 16 bytes
>          bInterval 0
>        Endpoint Descriptor:
>          bLength 7
>          bDescriptorType 5
>          bEndpointAddress 0x84 EP 4 IN
>          bmAttributes 2
>            Transfer Type Bulk
>            Synch Type None
>            Usage Type Data
>          wMaxPacketSize 0x0200 1x 512 bytes
>          bInterval 0
>        Endpoint Descriptor:
>          bLength 7
>          bDescriptorType 5
>          bEndpointAddress 0x88 EP 8 IN
>          bmAttributes 2
>            Transfer Type Bulk
>            Synch Type None
>            Usage Type Data
>          wMaxPacketSize 0x0200 1x 512 bytes
>          bInterval 0
>
> If you see something strange here, please let me know.
>
> Thank you.
>
> Jakub Ladman
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Strange errors with NI GPIB-USB-HS

[Jakub L. <la...@vo...>]

> Hi Jakub,
> One way to check is to look at: the output of the syslog lines with "gpib" in them and the output of "lsusb -d 3923:",  with the adapter plugged in.
> cheers,
> -dave


Hello

First of all, I wrote that the device is working with windows, but the 
part I omitted is - windows is running in qemu on the same machine, 
where I'm testing the linux-gpib.

I can't show you the syslog output, because I have now installed the 
closed source driver and appropriate software from National Instruments 
(which I don't want to use in the end, but I use it now as a sanity 
check only).

The lsusb output is:
$ lsusb -d 3923: -v

Bus 001 Device 020: ID 3923:709b National Instruments Corp. GPIB-USB-HS
Couldn't open device, some information will be missing
Device Descriptor:
   bLength 18
   bDescriptorType 1
   bcdUSB 2.00
   bDeviceClass 0
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0 64
   idVendor 0x3923 National Instruments Corp.
   idProduct 0x709b GPIB-USB-HS
   bcdDevice 1.01
   iManufacturer 1 National Instruments
   iProduct 2 GPIB-USB-HS
   iSerial 3 019BF124
   bNumConfigurations 1
   Configuration Descriptor:
     bLength 9
     bDescriptorType 2
     wTotalLength 0x0035
     bNumInterfaces 1
     bConfigurationValue 1
     iConfiguration 0
     bmAttributes 0x80
       (Bus Powered)
     MaxPower 500mA
     Interface Descriptor:
       bLength 9
       bDescriptorType 4
       bInterfaceNumber 0
       bAlternateSetting 0
       bNumEndpoints 5
       bInterfaceClass 255 Vendor Specific Class
       bInterfaceSubClass 0
       bInterfaceProtocol 0
       iInterface 0
       Endpoint Descriptor:
         bLength 7
         bDescriptorType 5
         bEndpointAddress 0x02 EP 2 OUT
         bmAttributes 2
           Transfer Type Bulk
           Synch Type None
           Usage Type Data
         wMaxPacketSize 0x0200 1x 512 bytes
         bInterval 0
       Endpoint Descriptor:
         bLength 7
         bDescriptorType 5
         bEndpointAddress 0x06 EP 6 OUT
         bmAttributes 2
           Transfer Type Bulk
           Synch Type None
           Usage Type Data
         wMaxPacketSize 0x0200 1x 512 bytes
         bInterval 0
       Endpoint Descriptor:
         bLength 7
         bDescriptorType 5
         bEndpointAddress 0x81 EP 1 IN
         bmAttributes 3
           Transfer Type Interrupt
           Synch Type None
           Usage Type Data
         wMaxPacketSize 0x0010 1x 16 bytes
         bInterval 0
       Endpoint Descriptor:
         bLength 7
         bDescriptorType 5
         bEndpointAddress 0x84 EP 4 IN
         bmAttributes 2
           Transfer Type Bulk
           Synch Type None
           Usage Type Data
         wMaxPacketSize 0x0200 1x 512 bytes
         bInterval 0
       Endpoint Descriptor:
         bLength 7
         bDescriptorType 5
         bEndpointAddress 0x88 EP 8 IN
         bmAttributes 2
           Transfer Type Bulk
           Synch Type None
           Usage Type Data
         wMaxPacketSize 0x0200 1x 512 bytes
         bInterval 0

If you see something strange here, please let me know.

Thank you.

Jakub Ladman

Re: [Linux-gpib-general] Strange errors with NI GPIB-USB-HS

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

Hi Jakub,
One way to check is to look at: the output of the syslog lines with "gpib"
in them and the output of "lsusb -d 3923:",  with the adapter plugged in.
cheers,
-dave

On Mon, 1 Aug 2022 at 15:02, Ladman Jakub <la...@vo...> wrote:

> Hello
> I am new to this maling-list and with only limited experience with GPIB
> in general.
> I have NI GPIB-USB-HS hardware, which I want to use with linux-gpib.
> I have tried several versions of the linux-gpib (both kernel and user
> part) including 4.3.4 and 4.3.5. with my computer with kernel:
>
> $ uname -r
>
> 5.15.0-43-generic (ubuntu 22.04)
> Also my friends computer with kernel 3.16.0-4 (some old debian) and
> linux-gpib-3.2.21, which he is using regularly with another piece of
> GPIB-USB-HS interface.
> The behavior was the same, with the exception that the error messages
> were slightly different.
> The kernel module ni_gpib_b.ko is successfuly loaded, the rights are
> set, user is in the gpib group, the /dev/gpib0 is created among others.
>
> findlisteners lists my two devices (HP 3478A multimeter and AMREL
> PPS-1002 power supply) at pads 22 and 12.
> When trying to communicate with the devices from ibtest, ibterm or from
> python script I've got something similar to this:
>
> ibterm>MODEL?
> ibterm error: Unable to write to device at pad 12
>
> or
> :m
> gpib status is:
> ibsta = 0x8100 < ERR CMPL >
> iberr= 0
> EDVR 0: OS error
>
> ibcnt = 5
> But everytime I tried this, the controlled devices were signalizing
> "RMT" "TALK" or so on (from top of my head, because I am at different
> place now)
>
> I was convinced, that the hardware is half dead until I checked it from
> windows with NI software.
>
> I have installed whole bundle of software and then opened NI MAX.
>
>  From there i was completely able to scan and detect the devices and to
> communicate with those in the first place without any configuration.
>
> I have also tried the NI software for linux with ni488k.ko kernel
> module  (among others; instaled from official .deb package), but then
> the kernel module seems to completely ignore the hardware device. The
> userspace applications don't see any gpib interfaces.
>
> I dont know whether my device is a fake one or not, I bought it with
> huge discount from china, but everyting seems legit.
>
> The packaging was nice and clean, there was safety sticker on the bubble
> bag inside the box.
>
> The case is made of quality plastics, the color is as usual, the sticker
> on it is looking ok, the CD-ROM or DVD-ROM included is looking good, the
> booklet is good. There is "Made in Hungary" noted on everything which is
> also legit because they have manufacturing plant in Hungary.
>
> Both the windows software from the 2016 CD/DVD and the lastest form
> ni.com is functioning perfectly.
>
> Only the linux versions, both opensource and the ni provided are non
> functional.
>
> Is there a posibility to check the firmware version and compare it to a
> known to work interface piece?
>
> Any other tip?
>
> Thank you very much
> Jakub Ladman
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Strange errors with NI GPIB-USB-HS

[Ladman J. <la...@vo...>]

Hello
I am new to this maling-list and with only limited experience with GPIB 
in general.
I have NI GPIB-USB-HS hardware, which I want to use with linux-gpib.
I have tried several versions of the linux-gpib (both kernel and user 
part) including 4.3.4 and 4.3.5. with my computer with kernel:

$ uname -r

5.15.0-43-generic (ubuntu 22.04)
Also my friends computer with kernel 3.16.0-4 (some old debian) and 
linux-gpib-3.2.21, which he is using regularly with another piece of 
GPIB-USB-HS interface.
The behavior was the same, with the exception that the error messages 
were slightly different.
The kernel module ni_gpib_b.ko is successfuly loaded, the rights are 
set, user is in the gpib group, the /dev/gpib0 is created among others.

findlisteners lists my two devices (HP 3478A multimeter and AMREL 
PPS-1002 power supply) at pads 22 and 12.
When trying to communicate with the devices from ibtest, ibterm or from 
python script I've got something similar to this:

ibterm>MODEL?
ibterm error: Unable to write to device at pad 12

or
:m
gpib status is:
ibsta = 0x8100 < ERR CMPL >
iberr= 0
EDVR 0: OS error

ibcnt = 5
But everytime I tried this, the controlled devices were signalizing 
"RMT" "TALK" or so on (from top of my head, because I am at different 
place now)

I was convinced, that the hardware is half dead until I checked it from 
windows with NI software.

I have installed whole bundle of software and then opened NI MAX.

 From there i was completely able to scan and detect the devices and to 
communicate with those in the first place without any configuration.

I have also tried the NI software for linux with ni488k.ko kernel 
module  (among others; instaled from official .deb package), but then 
the kernel module seems to completely ignore the hardware device. The 
userspace applications don't see any gpib interfaces.

I dont know whether my device is a fake one or not, I bought it with 
huge discount from china, but everyting seems legit.

The packaging was nice and clean, there was safety sticker on the bubble 
bag inside the box.

The case is made of quality plastics, the color is as usual, the sticker 
on it is looking ok, the CD-ROM or DVD-ROM included is looking good, the 
booklet is good. There is "Made in Hungary" noted on everything which is 
also legit because they have manufacturing plant in Hungary.

Both the windows software from the 2016 CD/DVD and the lastest form 
ni.com is functioning perfectly.

Only the linux versions, both opensource and the ni provided are non 
functional.

Is there a posibility to check the firmware version and compare it to a 
known to work interface piece?

Any other tip?

Thank you very much
Jakub Ladman

Re: [Linux-gpib-general] python3.10 breaking changes

[Lee N. <ln...@ne...>]

Oi!  This explains why it seemed to suddenly appear even though I had been
using 3.10 all along.  In an attempt to solve another problem, I switched
from svn to the tarball.

On Sun, Jun 26, 2022 at 10:29 PM dave penkler <dpe...@gm...> wrote:

> The patch to define the PY_SSIZE_T_CLEAN macro from mika was added in
> r1990 so the svn should be OK.
>
> On Mon, 27 Jun 2022 at 05:11, Lee Nelson <ln...@ne...> wrote:
>
>> There seems to be a breaking change introduced in Python3.10:
>> https://docs.python.org/3.10/whatsnew/3.10.html#id2
>> https://peps.python.org/pep-0353/
>>
>> It appears to be in gpibinter.c and results in an error like this:
>> 2022-06-26 19:03:45,730 - pyvisa - DEBUG - GPIB0::5::INSTR - opening ...
>>
>>
>> 2022-06-26 19:03:45,735 - pyvisa - DEBUG - GPIB0::5::INSTR - is open with
>> session 1840975
>>
>> 2022-06-26 19:03:45,735 - pyvisa - DEBUG - GPIB.write b'*IDN?\r\n'
>>
>>
>> Traceback (most recent call last):
>>
>>
>>   File "/home/lnelson/test_gpib.py", line 6, in <module>
>>
>>
>>     my_instrument.query("*IDN?")
>>
>>
>>   File
>> "/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
>> line 642, in query
>>
>>     self.write(message)
>>
>>
>>   File
>> "/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
>> line 197, in write
>>
>>     count = self.write_raw(message.encode(enco))
>>
>>
>>   File
>> "/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
>> line 157, in write_raw
>>
>>     return self.visalib.write(self.session, message)[0]
>>
>>
>>   File "/usr/local/lib/python3.10/dist-packages/pyvisa_py/highlevel.py",
>> line 543, in write
>>
>>     written, status_code = self.sessions[session].write(data)
>>
>>
>>   File "/usr/local/lib/python3.10/dist-packages/pyvisa_py/gpib.py", line
>> 401, in write
>>
>>     ifc.write(data)
>>   File "/usr/local/lib/python3.10/dist-packages/Gpib.py", line 53, in
>> write
>>     gpib.write(self.id, str)
>> SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats
>> 2022-06-26 19:03:45,878 - pyvisa - DEBUG - Closing ResourceManager
>> (session: 7325318)
>> 2022-06-26 19:03:45,878 - pyvisa - DEBUG - GPIB0::5::INSTR - closing
>> 2022-06-26 19:03:45,879 - pyvisa - DEBUG - GPIB0::5::INSTR - is closed
>>
>> It didn't look like this is mentioned elsewhere on the list, so I thought
>> I'd bring it up.
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>

-- 
https://keybase.io/nelsonov

Re: [Linux-gpib-general] python3.10 breaking changes

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

The patch to define the PY_SSIZE_T_CLEAN macro from mika was added in r1990
so the svn should be OK.

On Mon, 27 Jun 2022 at 05:11, Lee Nelson <ln...@ne...> wrote:

> There seems to be a breaking change introduced in Python3.10:
> https://docs.python.org/3.10/whatsnew/3.10.html#id2
> https://peps.python.org/pep-0353/
>
> It appears to be in gpibinter.c and results in an error like this:
> 2022-06-26 19:03:45,730 - pyvisa - DEBUG - GPIB0::5::INSTR - opening ...
>
>
> 2022-06-26 19:03:45,735 - pyvisa - DEBUG - GPIB0::5::INSTR - is open with
> session 1840975
>
> 2022-06-26 19:03:45,735 - pyvisa - DEBUG - GPIB.write b'*IDN?\r\n'
>
>
> Traceback (most recent call last):
>
>
>   File "/home/lnelson/test_gpib.py", line 6, in <module>
>
>
>     my_instrument.query("*IDN?")
>
>
>   File
> "/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
> line 642, in query
>
>     self.write(message)
>
>
>   File
> "/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
> line 197, in write
>
>     count = self.write_raw(message.encode(enco))
>
>
>   File
> "/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
> line 157, in write_raw
>
>     return self.visalib.write(self.session, message)[0]
>
>
>   File "/usr/local/lib/python3.10/dist-packages/pyvisa_py/highlevel.py",
> line 543, in write
>
>     written, status_code = self.sessions[session].write(data)
>
>
>   File "/usr/local/lib/python3.10/dist-packages/pyvisa_py/gpib.py", line
> 401, in write
>
>     ifc.write(data)
>   File "/usr/local/lib/python3.10/dist-packages/Gpib.py", line 53, in write
>     gpib.write(self.id, str)
> SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats
> 2022-06-26 19:03:45,878 - pyvisa - DEBUG - Closing ResourceManager
> (session: 7325318)
> 2022-06-26 19:03:45,878 - pyvisa - DEBUG - GPIB0::5::INSTR - closing
> 2022-06-26 19:03:45,879 - pyvisa - DEBUG - GPIB0::5::INSTR - is closed
>
> It didn't look like this is mentioned elsewhere on the list, so I thought
> I'd bring it up.
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] python3.10 breaking changes

[Lee N. <ln...@ne...>]

There seems to be a breaking change introduced in Python3.10:
https://docs.python.org/3.10/whatsnew/3.10.html#id2
https://peps.python.org/pep-0353/

It appears to be in gpibinter.c and results in an error like this:
2022-06-26 19:03:45,730 - pyvisa - DEBUG - GPIB0::5::INSTR - opening ...


2022-06-26 19:03:45,735 - pyvisa - DEBUG - GPIB0::5::INSTR - is open with
session 1840975

2022-06-26 19:03:45,735 - pyvisa - DEBUG - GPIB.write b'*IDN?\r\n'


Traceback (most recent call last):


  File "/home/lnelson/test_gpib.py", line 6, in <module>


    my_instrument.query("*IDN?")


  File
"/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
line 642, in query

    self.write(message)


  File
"/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
line 197, in write

    count = self.write_raw(message.encode(enco))


  File
"/usr/local/lib/python3.10/dist-packages/pyvisa/resources/messagebased.py",
line 157, in write_raw

    return self.visalib.write(self.session, message)[0]


  File "/usr/local/lib/python3.10/dist-packages/pyvisa_py/highlevel.py",
line 543, in write

    written, status_code = self.sessions[session].write(data)


  File "/usr/local/lib/python3.10/dist-packages/pyvisa_py/gpib.py", line
401, in write

    ifc.write(data)
  File "/usr/local/lib/python3.10/dist-packages/Gpib.py", line 53, in write
    gpib.write(self.id, str)
SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats
2022-06-26 19:03:45,878 - pyvisa - DEBUG - Closing ResourceManager
(session: 7325318)
2022-06-26 19:03:45,878 - pyvisa - DEBUG - GPIB0::5::INSTR - closing
2022-06-26 19:03:45,879 - pyvisa - DEBUG - GPIB0::5::INSTR - is closed

It didn't look like this is mentioned elsewhere on the list, so I thought
I'd bring it up.

[Linux-gpib-general] FYI: New Fedora RPMs available

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

The Fedora package of linux-gpib done by 'vccvss' appears to be inactive or abandoned. The packages there do not work on the current Fedora distribution (36) and the snapshot included is now several years old.
I did a pull request with fixes and updates on the vccvss github repository but heard only crickets.

Consequently, I have created a new RPM repository with fixes to the configuration and updated patches to ensure it installs and works on Fedora 35 & 36. 
The new repository is https://copr.fedorainfracloud.org/coprs/vk2bea/GPIB/.

To install the r2020 SVN on Fedora 35 or 36 use:

$ sudo dnf copr enable vk2bea/GPIB
$ sudo dnf install dkms-linux-gpib linux-gpib

to install firmware, for those adapters that require it, then use ... 

$ sudo dnf install linux-gpib-firmware

To install language packages, install one or more ...

$ sudo dnf install guile18-linux-gpib perl-LinuxGpib php-linux-gpib python2-linux-gpib python3-linux-gpib tcl-linux-gpib

To install documentation ...

sudo dnf install linux-gpib-doc

Michael

[Linux-gpib-general] Package for debian?

[Michael D. <mi...@di...>]

What is the reason why there is no package for debian?
10 years ago there was already a package awailable.

At least for RasPi it is a real pita to get linux gpib compiled, if you do
not have recent script for it.
It would have saved hours of my and many others lifes...

Seems GauiStori just needs a bit of motivation to put it into debian:
https://github.com/GauiStori/gpib/issues/1#issuecomment-803460289

Derek Kozel had started packaging:

https://sourceforge.net/p/linux-gpib/mailman/message/36281789/

Any progress there?

 

Best regards, Michael

[Linux-gpib-general] Package for debian?

[Michael D. <mi...@di...>]

What is the reason why there is no package for debian?
10 years ago there was already a package awailable.

At least for RasPi it is a real pita to get linux gpib compiled, if you do
not have recent script for it.
It would have saved hours of my and many others lifes...

Seems GauiStori just needs a bit of motivation to put it into debian:
https://github.com/GauiStori/gpib/issues/1#issuecomment-803460289

Derek Kozel had started packaging:
https://sourceforge.net/p/linux-gpib/mailman/message/36281789/
Any progress there?

Best regards, Michael

Re: [Linux-gpib-general] async reads and timeouts

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

Oh, that code had a typo..

....
#ifndef PREFERRED
        if( rtn == eRD_CONTINUE )
            usleep(100 * 1000);
#endif
....

[Linux-gpib-general] async reads and timeouts

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

I'm trying to write a routine to use asynchronous reads so that I can handle a long timeout (the device may take ~minute to respond) while still being responsive.

My plan was to set a short timeout (100ms) use ibrda (async read) and wait on CMPL, TIMO and END.
After a timeout, I check to see if we need to respond to other parts of the program (or an abort request) and then ibwait again.

This doesn't work. It seems that the read aborts after the timeout.

I can do an ibwait with 0 instead of ( TIMO | CMPL | END), check the ibstatus response, then use usleep to wait 100ms but this means that if the read completes while I'm sleeping I have an unnecessary (up to) 100ms delay.

What is the correct way to use ibrda and ibwait together in this scenario ?
 

typedef enum { eRD_OK=0, eRD_ERROR, eRD_TIMEOUT, eRD_ABORT, eRD_CONTINUE } tReadStatus;

tReadStatus
GPIB_AsyncRead( int GPIBdescriptor, void *readBuffer, long maxBytes, double timeout, int bAbort )
{
    int GPIBstatus, currentTimeout;

    tReadStatus rtn = eRD_CONTINUE;

    ibask(GPIBdescriptor, IbaTMO, &currentTimeout);

    ibtmo( GPIBdescriptor, T100s );
    GPIBstatus = ibrda( GPIBdescriptor, readBuffer, maxBytes );

    do {
#ifdef PREFERRED
        GPIBstatus = ibwait(GPIBdescriptor, TIMO | CMPL | END);
#else
        GPIBstatus = ibwait(GPIBdescriptor, 0);
#endif
        if( GPIBstatus & ERR )
            rtn= eRD_ERROR;
        else if( GPIBstatus & CMPL )
            rtn = eRD_OK;
        else if( bAbort )
            rtn = eRD_ABORT;
        else if((GPIBstatus & TIMO)  != TIMO )
            rtn = eRD_ERROR;
#ifdef PREFERRED
        if( rtn == eRD_CONTINUE )
            usleep(100 * 1000);
#endif
    } while( rtn == eRD_CONTINUE && (timeout -= 0.1) > 0.0 );

    if( rtn == eRD_OK )
        ibwait(GPIBdescriptor, CMPL);
    else
        ibstop( GPIBdescriptor );

    ibtmo( GPIBdescriptor, currentTimeout);
    return ( rtn == eRD_CONTINUE ? eRD_TIMEOUT : rtn );   
}

Re: [Linux-gpib-general] FindLstn doesn't return if no devices found.

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

Hi Michael,
The following program terminates just fine even with no devices attached on
an agilent_82357b clone.
$ ./fls
ibcnt 0, iberr 0x2
$
cheers,
-Dave
#include <stdint.h>
#include <stdio.h>
#include <gpib/gpib_user.h>
#include <gpib/ib.h>
#define MAX_PRIMARY_DEVICES          30
#define MAX_SECONDARY_DEVICES        10

Addr4882_t deviceList[ MAX_PRIMARY_DEVICES + 1 ] = {5,6,7,NOADDR};
Addr4882_t resultList[ MAX_PRIMARY_DEVICES * MAX_SECONDARY_DEVICES ] = {};

int main() {
  FindLstn( 0, deviceList, resultList, ( MAX_PRIMARY_DEVICES *
MAX_SECONDARY_DEVICES));
  printf("ibcnt %d, iberr 0x%0x\n",ibcnt,iberr);
}

On Sun, 17 Apr 2022 at 02:19, Michael K via Linux-gpib-general <
lin...@li...> wrote:

> I'm trying to use FindLstn to query the GPIB.
> When a device is found, things work as expected but if there are no
> devices connected to the controller ( HP 82357b ) FindLstn hangs.
>
> I'm using the latest SVN branch.
>
> Is this correct behavior ?
>
> Michael
>
> #define MAX_PRIMARY_DEVICES               30
> #define MAX_SECONDARY_DEVICES        10
>
> Addr4882_t deviceList[ MAX_PRIMARY_DEVICES + 1 ] = {};
>  Addr4882_t resultList[ MAX_PRIMARY_DEVICES * MAX_SECONDARY_DEVICES ] = {};
>
> GPIBdevice devices[] = {
>         { A4882( ADDR_HP8753C, 0 ),                "HP8753C",        {
> FALSE } },
>         { A4882( ADDR_HP33401A_MULTIMETER, 0 ),    "HP33401A
> Multimeter",    { FALSE } }
> };
>
>
> gint MAX_ENUMERATED_DEVICES = ((sizeof( devices ) / sizeof( GPIBdevice )));
>
>         for( i=0; i < MAX_PRIMARY_DEVICES + 1; i++ ) {
>             if( i < MAX_ENUMERATED_DEVICES )
>                 deviceList[ i ] = devices[i].GPIBaddress;
>             else
>                 deviceList[ i ] = NOADDR;
>         }
>
>         FindLstn( descGPIBcontroller, deviceList, resultList,
> MAX_PRIMARY_DEVICES * MAX_SECONDARY_DEVICES);
>
> // Never gets here unless a device responds
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] FindLstn doesn't return if no devices found.

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

I'm trying to use FindLstn to query the GPIB.
When a device is found, things work as expected but if there are no devices connected to the controller ( HP 82357b ) FindLstn hangs.

I'm using the latest SVN branch.

Is this correct behavior ?  

Michael

#define MAX_PRIMARY_DEVICES               30
#define MAX_SECONDARY_DEVICES        10

Addr4882_t deviceList[ MAX_PRIMARY_DEVICES + 1 ] = {};
 Addr4882_t resultList[ MAX_PRIMARY_DEVICES * MAX_SECONDARY_DEVICES ] = {};
 
GPIBdevice devices[] = {
        { A4882( ADDR_HP8753C, 0 ),                "HP8753C",        { FALSE } },
        { A4882( ADDR_HP33401A_MULTIMETER, 0 ),    "HP33401A Multimeter",    { FALSE } }
};


gint MAX_ENUMERATED_DEVICES = ((sizeof( devices ) / sizeof( GPIBdevice )));

        for( i=0; i < MAX_PRIMARY_DEVICES + 1; i++ ) {
            if( i < MAX_ENUMERATED_DEVICES )
                deviceList[ i ] = devices[i].GPIBaddress;
            else
                deviceList[ i ] = NOADDR;
        }

        FindLstn( descGPIBcontroller, deviceList, resultList, MAX_PRIMARY_DEVICES * MAX_SECONDARY_DEVICES);

// Never gets here unless a device responds

[Linux-gpib-general] udev rule for NI USB HS and Debian 11

[Richard K. <ric...@gm...>]

Good monring (o;

Someone has a working udev rule for the NI USB HS GPIB adapter?

Well all works except that the /dev/gpib* device entries are isntalled as root,root instead of using group plugdev as in the udev rule:

#gpib-usb-b without firmware
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="3923", ATTR{idProduct}=="702b", ENV{DEVICE}="$devnode", RUN+="/usr/local/lib/udev/gpib_udev_fxloader"
#device id 713b is a keithley kusb-488 before we load it with firmware
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="3923", ATTR{idProduct}=="713b", ENV{DEVICE}="$devnode", RUN+="/usr/local/lib/udev/gpib_udev_fxloader"

#automatically set the correct --board-type option
ACTION=="add|change", SUBSYSTEM=="usb", DRIVER=="ni_usb_gpib", ATTRS{serial}=="*", ENV{GPIB_CONFIG_OPTIONS}+="--board-type ni_usb_b", ENV{SERIAL}="$attr{serial}"
#devices ready to be configured with gpib_config
SUBSYSTEM=="usb", ACTION=="add|change", DRIVER=="ni_usb_gpib", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="702a", RUN+="/usr/local/lib/udev/gpib_udev_config"
SUBSYSTEM=="usb", ACTION=="add|change", DRIVER=="ni_usb_gpib", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="709b", RUN+="/usr/local/lib/udev/gpib_udev_config", MODE="666", GROUP="plugdev"
SUBSYSTEM=="usb", ACTION=="add|change", DRIVER=="ni_usb_gpib", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7618", RUN+="/usr/local/lib/udev/gpib_udev_config"
SUBSYSTEM=="usb", ACTION=="add|change", DRIVER=="ni_usb_gpib", ATTRS{idVendor}=="3923", ATTRS{idProduct}=="725[cd]", RUN+="/usr/local/lib/udev/gpib_udev_config"

thanks in advance
richard

Re: [Linux-gpib-general] Detecting the absence/removal of board (USB device)

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

 Apparently for php 8 ...   
   - TSRMLS_CC was part of the the Thread-Safe Resource Manager, an implementation of thread-local storage used to build PHP for multi-threaded environments. It has been removed because newer mechanisms exist to do the same thing much more transparently. You can safely remove all uses of TSRMLS_* from your extension, unless you need to retain PHP 5 support.

https://github.com/php/php-src/blob/PHP-8.0/UPGRADING.INTERNALS

 
    On Sunday, February 27, 2022, 09:18:01 PM EST, Michael K via Linux-gpib-general <lin...@li...> wrote:  
 
  maybe a php version problem? php -vPHP 8.0.16 (cli) (built: Feb 15 2022 21:34:32) ( NTS gcc x86_64 )Copyright (c) The PHP GroupZend Engine v4.0.16, Copyright (c) Zend Technologies    with Zend OPcache v8.0.16, Copyright (c), by Zend Technologies


    On Sunday, February 27, 2022, 09:13:20 PM EST, Michael K via Linux-gpib-general <lin...@li...> wrote:  
 
  If I use "YACC=bison" on the configure that problem is solved but now I get a stack of other errors ... like 
gpib.c: In function ‘zif_iberr’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:430:6: note: in expansion of macro ‘FUN_ACCESSOR’  430 |      FUN_ACCESSOR(iberr)      |      ^~~~~~~~~~~~gpib.c:73:7: error: too few arguments to function ‘zend_parse_parameters’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |       ^~~~~~~~~~~~~~~~~~~~~gpib.c:430:6: note: in expansion of macro ‘FUN_ACCESSOR’  430 |      FUN_ACCESSOR(iberr)      |      ^~~~~~~~~~~~In file included from /usr/include/php/main/php.h:35,                 from gpib.c:65:/usr/include/php/Zend/zend_API.h:304:22: note: declared here  304 | ZEND_API zend_result zend_parse_parameters(uint32_t num_args, const char *type_spec, ...);      |                      ^~~~~~~~~~~~~~~~~~~~~gpib.c: In function ‘zif_ibcnt’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:431:6: note: in expansion of macro ‘FUN_ACCESSOR’  431 |      FUN_ACCESSOR(ibcnt)      |      ^~~~~~~~~~~~gpib.c:73:7: error: too few arguments to function ‘zend_parse_parameters’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |       ^~~~~~~~~~~~~~~~~~~~~gpib.c:431:6: note: in expansion of macro ‘FUN_ACCESSOR’  431 |      FUN_ACCESSOR(ibcnt)      |      ^~~~~~~~~~~~In file included from /usr/include/php/main/php.h:35,                 from gpib.c:65:/usr/include/php/Zend/zend_API.h:304:22: note: declared here  304 | ZEND_API zend_result zend_parse_parameters(uint32_t num_args, const char *type_spec, ...);      |                      ^~~~~~~~~~~~~~~~~~~~~gpib.c: In function ‘zif_ibsta’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:432:6: note: in expansion of macro ‘FUN_ACCESSOR’  432 |      FUN_ACCESSOR(ibsta)      |      ^~~~~~~~~~~~

    On Sunday, February 27, 2022, 09:00:41 PM EST, Michael K via Linux-gpib-general <lin...@li...> wrote:  
 
  That's great but I'm now having trouble compiling the SVN.
I bootstrap, configure and the make but for some odd reason the makefile generates an invalid option for yacc.Any idea whats going on here?
/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -Wno-yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: invalid option -- 'W'Usage: yacc [options] filename
if I remove the option from the Makefile.ac I get this error when building (after bootsrat and configure)

/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: e - line 115 of "ibConfYacc.y", syntax error%define api.pure full^
$ yacc -Vyacc - 2.0 20210328


thanks,  Michael    On Sunday, February 27, 2022, 12:47:55 PM EST, dave penkler <dpe...@gm...> wrote:  
 
 Normally I would suggest using  iblines(). But the agilent driver has a bug returning no error even if there is no board.It is fixed in the SVN and now returns ibcntl = 19 which is ENODEVHere is a log of ibtest with the "board" disconnected:
$ ibtest
Do you wish to open a (d)evice or an interface (b)oard?
        (you probably want to open a device): b
enter name of interface board (or device) you wish to open: hpusb
trying to open board named 'hpusb'
You can:
        w(a)it for an event
        write (c)ommand bytes to bus (system controller only)
        send (d)evice clear (device only)
        change remote (e)nable line (system controller only)
        (g)o to standby (release ATN line, system controller only)
        send (i)nterface clear (system controller only)
        ta(k)e control (assert ATN line, system controller only)
        get bus (l)ine status (board only)
        go to local (m)ode
        change end (o)f transmission configuration
        (q)uit
        (r)ead string
        perform (s)erial poll (device only)
        change (t)imeout on io operations
        request ser(v)ice (board only)
        (w)rite data string
        send group e(x)ecute trigger (device only)
: l
gpib status is: 
ibsta = 0x8120  < ERR CMPL CIC >
iberr= 0
EDVR 0: OS error

ibcntl = 19
You can:...

On Sun, 27 Feb 2022 at 16:43, Michael K via Linux-gpib-general <lin...@li...> wrote:

I'm using an Keysight 82357B "board" (USB device).If the drivers (gpib_common and agilent_82357a) are loaded, ibfind will always find the device even after the USB device has been removed.(the drivers are loaded upon connection but do not unload when the USB device is removed)Is there a way to determine if the board is still connected using the API?_______________________________________________
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
  

Re: [Linux-gpib-general] Detecting the absence/removal of board (USB device)

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

 maybe a php version problem? php -vPHP 8.0.16 (cli) (built: Feb 15 2022 21:34:32) ( NTS gcc x86_64 )Copyright (c) The PHP GroupZend Engine v4.0.16, Copyright (c) Zend Technologies    with Zend OPcache v8.0.16, Copyright (c), by Zend Technologies


    On Sunday, February 27, 2022, 09:13:20 PM EST, Michael K via Linux-gpib-general <lin...@li...> wrote:  
 
  If I use "YACC=bison" on the configure that problem is solved but now I get a stack of other errors ... like 
gpib.c: In function ‘zif_iberr’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:430:6: note: in expansion of macro ‘FUN_ACCESSOR’  430 |      FUN_ACCESSOR(iberr)      |      ^~~~~~~~~~~~gpib.c:73:7: error: too few arguments to function ‘zend_parse_parameters’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |       ^~~~~~~~~~~~~~~~~~~~~gpib.c:430:6: note: in expansion of macro ‘FUN_ACCESSOR’  430 |      FUN_ACCESSOR(iberr)      |      ^~~~~~~~~~~~In file included from /usr/include/php/main/php.h:35,                 from gpib.c:65:/usr/include/php/Zend/zend_API.h:304:22: note: declared here  304 | ZEND_API zend_result zend_parse_parameters(uint32_t num_args, const char *type_spec, ...);      |                      ^~~~~~~~~~~~~~~~~~~~~gpib.c: In function ‘zif_ibcnt’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:431:6: note: in expansion of macro ‘FUN_ACCESSOR’  431 |      FUN_ACCESSOR(ibcnt)      |      ^~~~~~~~~~~~gpib.c:73:7: error: too few arguments to function ‘zend_parse_parameters’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |       ^~~~~~~~~~~~~~~~~~~~~gpib.c:431:6: note: in expansion of macro ‘FUN_ACCESSOR’  431 |      FUN_ACCESSOR(ibcnt)      |      ^~~~~~~~~~~~In file included from /usr/include/php/main/php.h:35,                 from gpib.c:65:/usr/include/php/Zend/zend_API.h:304:22: note: declared here  304 | ZEND_API zend_result zend_parse_parameters(uint32_t num_args, const char *type_spec, ...);      |                      ^~~~~~~~~~~~~~~~~~~~~gpib.c: In function ‘zif_ibsta’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:432:6: note: in expansion of macro ‘FUN_ACCESSOR’  432 |      FUN_ACCESSOR(ibsta)      |      ^~~~~~~~~~~~

    On Sunday, February 27, 2022, 09:00:41 PM EST, Michael K via Linux-gpib-general <lin...@li...> wrote:  
 
  That's great but I'm now having trouble compiling the SVN.
I bootstrap, configure and the make but for some odd reason the makefile generates an invalid option for yacc.Any idea whats going on here?
/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -Wno-yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: invalid option -- 'W'Usage: yacc [options] filename
if I remove the option from the Makefile.ac I get this error when building (after bootsrat and configure)

/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: e - line 115 of "ibConfYacc.y", syntax error%define api.pure full^
$ yacc -Vyacc - 2.0 20210328


thanks,  Michael    On Sunday, February 27, 2022, 12:47:55 PM EST, dave penkler <dpe...@gm...> wrote:  
 
 Normally I would suggest using  iblines(). But the agilent driver has a bug returning no error even if there is no board.It is fixed in the SVN and now returns ibcntl = 19 which is ENODEVHere is a log of ibtest with the "board" disconnected:
$ ibtest
Do you wish to open a (d)evice or an interface (b)oard?
        (you probably want to open a device): b
enter name of interface board (or device) you wish to open: hpusb
trying to open board named 'hpusb'
You can:
        w(a)it for an event
        write (c)ommand bytes to bus (system controller only)
        send (d)evice clear (device only)
        change remote (e)nable line (system controller only)
        (g)o to standby (release ATN line, system controller only)
        send (i)nterface clear (system controller only)
        ta(k)e control (assert ATN line, system controller only)
        get bus (l)ine status (board only)
        go to local (m)ode
        change end (o)f transmission configuration
        (q)uit
        (r)ead string
        perform (s)erial poll (device only)
        change (t)imeout on io operations
        request ser(v)ice (board only)
        (w)rite data string
        send group e(x)ecute trigger (device only)
: l
gpib status is: 
ibsta = 0x8120  < ERR CMPL CIC >
iberr= 0
EDVR 0: OS error

ibcntl = 19
You can:...

On Sun, 27 Feb 2022 at 16:43, Michael K via Linux-gpib-general <lin...@li...> wrote:

I'm using an Keysight 82357B "board" (USB device).If the drivers (gpib_common and agilent_82357a) are loaded, ibfind will always find the device even after the USB device has been removed.(the drivers are loaded upon connection but do not unload when the USB device is removed)Is there a way to determine if the board is still connected using the API?_______________________________________________
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] Detecting the absence/removal of board (USB device)

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

 If I use "YACC=bison" on the configure that problem is solved but now I get a stack of other errors ... like 
gpib.c: In function ‘zif_iberr’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:430:6: note: in expansion of macro ‘FUN_ACCESSOR’  430 |      FUN_ACCESSOR(iberr)      |      ^~~~~~~~~~~~gpib.c:73:7: error: too few arguments to function ‘zend_parse_parameters’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |       ^~~~~~~~~~~~~~~~~~~~~gpib.c:430:6: note: in expansion of macro ‘FUN_ACCESSOR’  430 |      FUN_ACCESSOR(iberr)      |      ^~~~~~~~~~~~In file included from /usr/include/php/main/php.h:35,                 from gpib.c:65:/usr/include/php/Zend/zend_API.h:304:22: note: declared here  304 | ZEND_API zend_result zend_parse_parameters(uint32_t num_args, const char *type_spec, ...);      |                      ^~~~~~~~~~~~~~~~~~~~~gpib.c: In function ‘zif_ibcnt’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:431:6: note: in expansion of macro ‘FUN_ACCESSOR’  431 |      FUN_ACCESSOR(ibcnt)      |      ^~~~~~~~~~~~gpib.c:73:7: error: too few arguments to function ‘zend_parse_parameters’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |       ^~~~~~~~~~~~~~~~~~~~~gpib.c:431:6: note: in expansion of macro ‘FUN_ACCESSOR’  431 |      FUN_ACCESSOR(ibcnt)      |      ^~~~~~~~~~~~In file included from /usr/include/php/main/php.h:35,                 from gpib.c:65:/usr/include/php/Zend/zend_API.h:304:22: note: declared here  304 | ZEND_API zend_result zend_parse_parameters(uint32_t num_args, const char *type_spec, ...);      |                      ^~~~~~~~~~~~~~~~~~~~~gpib.c: In function ‘zif_ibsta’:gpib.c:73:45: error: expected ‘)’ before ‘TSRMLS_CC’   73 |   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "") == FAILURE) \      |                            ~                ^~~~~~~~~gpib.c:432:6: note: in expansion of macro ‘FUN_ACCESSOR’  432 |      FUN_ACCESSOR(ibsta)      |      ^~~~~~~~~~~~

    On Sunday, February 27, 2022, 09:00:41 PM EST, Michael K via Linux-gpib-general <lin...@li...> wrote:  
 
  That's great but I'm now having trouble compiling the SVN.
I bootstrap, configure and the make but for some odd reason the makefile generates an invalid option for yacc.Any idea whats going on here?
/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -Wno-yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: invalid option -- 'W'Usage: yacc [options] filename
if I remove the option from the Makefile.ac I get this error when building (after bootsrat and configure)

/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: e - line 115 of "ibConfYacc.y", syntax error%define api.pure full^
$ yacc -Vyacc - 2.0 20210328


thanks,  Michael    On Sunday, February 27, 2022, 12:47:55 PM EST, dave penkler <dpe...@gm...> wrote:  
 
 Normally I would suggest using  iblines(). But the agilent driver has a bug returning no error even if there is no board.It is fixed in the SVN and now returns ibcntl = 19 which is ENODEVHere is a log of ibtest with the "board" disconnected:
$ ibtest
Do you wish to open a (d)evice or an interface (b)oard?
        (you probably want to open a device): b
enter name of interface board (or device) you wish to open: hpusb
trying to open board named 'hpusb'
You can:
        w(a)it for an event
        write (c)ommand bytes to bus (system controller only)
        send (d)evice clear (device only)
        change remote (e)nable line (system controller only)
        (g)o to standby (release ATN line, system controller only)
        send (i)nterface clear (system controller only)
        ta(k)e control (assert ATN line, system controller only)
        get bus (l)ine status (board only)
        go to local (m)ode
        change end (o)f transmission configuration
        (q)uit
        (r)ead string
        perform (s)erial poll (device only)
        change (t)imeout on io operations
        request ser(v)ice (board only)
        (w)rite data string
        send group e(x)ecute trigger (device only)
: l
gpib status is: 
ibsta = 0x8120  < ERR CMPL CIC >
iberr= 0
EDVR 0: OS error

ibcntl = 19
You can:...

On Sun, 27 Feb 2022 at 16:43, Michael K via Linux-gpib-general <lin...@li...> wrote:

I'm using an Keysight 82357B "board" (USB device).If the drivers (gpib_common and agilent_82357a) are loaded, ibfind will always find the device even after the USB device has been removed.(the drivers are loaded upon connection but do not unload when the USB device is removed)Is there a way to determine if the board is still connected using the API?_______________________________________________
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] Detecting the absence/removal of board (USB device)

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

 That's great but I'm now having trouble compiling the SVN.
I bootstrap, configure and the make but for some odd reason the makefile generates an invalid option for yacc.Any idea whats going on here?
/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -Wno-yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: invalid option -- 'W'Usage: yacc [options] filename
if I remove the option from the Makefile.ac I get this error when building (after bootsrat and configure)

/bin/sh /home/michael/CatLab/GPIB/linux-gpib-code/linux-gpib-user/missing yacc -d -p gpib_yy -o ./ibConfYacc.c ibConfYacc.yyacc: e - line 115 of "ibConfYacc.y", syntax error%define api.pure full^
$ yacc -Vyacc - 2.0 20210328


thanks,  Michael    On Sunday, February 27, 2022, 12:47:55 PM EST, dave penkler <dpe...@gm...> wrote:  
 
 Normally I would suggest using  iblines(). But the agilent driver has a bug returning no error even if there is no board.It is fixed in the SVN and now returns ibcntl = 19 which is ENODEVHere is a log of ibtest with the "board" disconnected:
$ ibtest
Do you wish to open a (d)evice or an interface (b)oard?
        (you probably want to open a device): b
enter name of interface board (or device) you wish to open: hpusb
trying to open board named 'hpusb'
You can:
        w(a)it for an event
        write (c)ommand bytes to bus (system controller only)
        send (d)evice clear (device only)
        change remote (e)nable line (system controller only)
        (g)o to standby (release ATN line, system controller only)
        send (i)nterface clear (system controller only)
        ta(k)e control (assert ATN line, system controller only)
        get bus (l)ine status (board only)
        go to local (m)ode
        change end (o)f transmission configuration
        (q)uit
        (r)ead string
        perform (s)erial poll (device only)
        change (t)imeout on io operations
        request ser(v)ice (board only)
        (w)rite data string
        send group e(x)ecute trigger (device only)
: l
gpib status is: 
ibsta = 0x8120  < ERR CMPL CIC >
iberr= 0
EDVR 0: OS error

ibcntl = 19
You can:...

On Sun, 27 Feb 2022 at 16:43, Michael K via Linux-gpib-general <lin...@li...> wrote:

I'm using an Keysight 82357B "board" (USB device).If the drivers (gpib_common and agilent_82357a) are loaded, ibfind will always find the device even after the USB device has been removed.(the drivers are loaded upon connection but do not unload when the USB device is removed)Is there a way to determine if the board is still connected using the API?_______________________________________________
Linux-gpib-general mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general