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
(31) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: dave p. <dpe...@gm...> - 2025-08-27 07:01:29
|
Hi Chris, It was fixed with this commit [778a98] <https://sourceforge.net/p/linux-gpib/git/ci/778a98df97a2b89d401a54515bad3ce2346dd3af/> , The latest kernel divers are currently available in the linux-gpib-git/linux-gpib-kernel directory of the git repo: git clone https://dpe...@gi.../p/linux-gpib/git linux-gpib-git I hope to cut a release for 4.3.7 which includes this fix in the next few weeks. cheers, -Dave On Tue, 26 Aug 2025 at 23:49, Cris Collins <clc...@gm...> wrote: > Solved. > RHEL 9's 5.14 kernel must be showing up as greater than 6.4 > Changed device.h from: > > #if LINUX_VERSION_CODE < KERNEL_VERSION(6,4,0) > > #define CLASS_CREATE(owner, name) \ > > class_create(owner, name) > > #else > > #define CLASS_CREATE(owner, name) \ > > class_create(name) > > #endif > > > To: > > #define CLASS_CREATE(owner, name) \ > > class_create(name) > > > > > > On Tue, Aug 26, 2025 at 3:57 PM Cris Collins <clc...@gm...> > wrote: > >> >> >> Trying to get the ni_usb_gpib driver to compile on a RHEL 9 system with >> the 5.14.0 kernel. But get the following error. We had been using 4.1.0 >> under RHEL 7 without problem. Any help is appreciated. >> >> >> >> CC [M] >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.o >> >> In file included from >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30, >> >> from >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20: >> >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c: >> In function ‘gpib_common_init_module’: >> >> ./include/linux/export.h:17:22: error: passing argument 1 of >> ‘class_create’ from incompatible pointer type >> [-Werror=incompatible-pointer-types] >> >> 17 | #define THIS_MODULE (&__this_module) >> >> | ~^~~~~~~~~~~~~~~ >> >> | | >> >> | struct module * >> >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:52:22: >> note: in definition of macro ‘CLASS_CREATE’ >> >> 52 | class_create(owner, name) >> >> | ^~~~~ >> >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:210:35: >> note: in expansion of macro ‘THIS_MODULE’ >> >> 210 | gpib_class = CLASS_CREATE(THIS_MODULE, "gpib_common"); >> >> | ^~~~~~~~~~~ >> >> In file included from ./include/linux/device.h:31, >> >> from >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:89, >> >> from >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30, >> >> from >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20: >> >> ./include/linux/device/class.h:230:54: note: expected ‘const char *’ but >> argument is of type ‘struct module *’ >> >> 230 | struct class * __must_check class_create(const char *name); >> >> | ~~~~~~~~~~~~^~~~ >> >> In file included from >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30, >> >> from >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20: >> >> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:52:9: >> error: too many arguments to function ‘class_create’ >> >> 52 | class_create(owner, name) >> >> >> >> >> >> >> >> >> >> -- >> This is my G-Mail account. I do not usually check it. >> > > > -- > This is my G-Mail account. I do not usually check it. > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Cris C. <clc...@gm...> - 2025-08-26 21:48:29
|
Solved.
RHEL 9's 5.14 kernel must be showing up as greater than 6.4
Changed device.h from:
#if LINUX_VERSION_CODE < KERNEL_VERSION(6,4,0)
#define CLASS_CREATE(owner, name) \
class_create(owner, name)
#else
#define CLASS_CREATE(owner, name) \
class_create(name)
#endif
To:
#define CLASS_CREATE(owner, name) \
class_create(name)
On Tue, Aug 26, 2025 at 3:57 PM Cris Collins <clc...@gm...> wrote:
>
>
> Trying to get the ni_usb_gpib driver to compile on a RHEL 9 system with
> the 5.14.0 kernel. But get the following error. We had been using 4.1.0
> under RHEL 7 without problem. Any help is appreciated.
>
>
>
> CC [M]
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.o
>
> In file included from
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30,
>
> from
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20:
>
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:
> In function ‘gpib_common_init_module’:
>
> ./include/linux/export.h:17:22: error: passing argument 1 of
> ‘class_create’ from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>
> 17 | #define THIS_MODULE (&__this_module)
>
> | ~^~~~~~~~~~~~~~~
>
> | |
>
> | struct module *
>
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:52:22:
> note: in definition of macro ‘CLASS_CREATE’
>
> 52 | class_create(owner, name)
>
> | ^~~~~
>
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:210:35:
> note: in expansion of macro ‘THIS_MODULE’
>
> 210 | gpib_class = CLASS_CREATE(THIS_MODULE, "gpib_common");
>
> | ^~~~~~~~~~~
>
> In file included from ./include/linux/device.h:31,
>
> from
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:89,
>
> from
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30,
>
> from
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20:
>
> ./include/linux/device/class.h:230:54: note: expected ‘const char *’ but
> argument is of type ‘struct module *’
>
> 230 | struct class * __must_check class_create(const char *name);
>
> | ~~~~~~~~~~~~^~~~
>
> In file included from
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30,
>
> from
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20:
>
> /root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:52:9:
> error: too many arguments to function ‘class_create’
>
> 52 | class_create(owner, name)
>
>
>
>
>
>
>
>
>
> --
> This is my G-Mail account. I do not usually check it.
>
--
This is my G-Mail account. I do not usually check it.
|
|
From: Cris C. <clc...@gm...> - 2025-08-26 19:57:29
|
Trying to get the ni_usb_gpib driver to compile on a RHEL 9 system with the
5.14.0 kernel. But get the following error. We had been using 4.1.0 under
RHEL 7 without problem. Any help is appreciated.
CC [M]
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.o
In file included from
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30,
from
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20:
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:
In function ‘gpib_common_init_module’:
./include/linux/export.h:17:22: error: passing argument 1 of ‘class_create’
from incompatible pointer type [-Werror=incompatible-pointer-types]
17 | #define THIS_MODULE (&__this_module)
| ~^~~~~~~~~~~~~~~
| |
| struct module *
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:52:22:
note: in definition of macro ‘CLASS_CREATE’
52 | class_create(owner, name)
| ^~~~~
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:210:35:
note: in expansion of macro ‘THIS_MODULE’
210 | gpib_class = CLASS_CREATE(THIS_MODULE, "gpib_common");
| ^~~~~~~~~~~
In file included from ./include/linux/device.h:31,
from
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:89,
from
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30,
from
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20:
./include/linux/device/class.h:230:54: note: expected ‘const char *’ but
argument is of type ‘struct module *’
230 | struct class * __must_check class_create(const char *name);
| ~~~~~~~~~~~~^~~~
In file included from
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/include/compat_device_create.h:30,
from
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/sys/osinit.c:20:
/root/Downloads/linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/compat/include/linux/device.h:52:9:
error: too many arguments to function ‘class_create’
52 | class_create(owner, name)
--
This is my G-Mail account. I do not usually check it.
|
|
From: Stanley A. <st...@ne...> - 2025-08-22 14:48:23
|
Dave: Thanks for responding. We had a recurring problem with the agilent_82350b_accel_read() function. In almost all cases we are able to request and receive the correct number of bytes, but for one PAD/SAD pair we are requesting five bytes and receiving six. What makes it strange is that we have multiple units under test (UUTs) which are identical except for the PAD. The SADs for each PAD are the same. We are querying SAD 1 (the "status register") on each UUT and are getting five bytes from each, except for this one. We're migrating from the National Instruments GPIB PCIe card to the Keysight PCIe card. We've been using the NI driver with the NI card to talk to these UUTs for many years (20+) and have always received five bytes from each unit. So we don't believe the one unit itself is having a problem. Debugging showed the problem was associated with the acceleration/fifo portion of the read() operation. So we modified read() to avoid the accel/fifo logic altogether & the problem went away. The modified read() calls the tms9914_read() in all cases; but now reading large blocks of data is fairly slow. We thought we could review the spec to see if there was a problem with the accel/fifo logic. We do need to be concerned about throughput. Regards, Stanley |
|
From: Michael K <vk...@ya...> - 2025-08-17 21:16:24
|
I was having problems communicating with an HP5334B Universal Counter.It turns out that it did to assert EOI or look for EOI. After using the appropriate calls to use 0x0A as the END of string, I can read and write without problems. The unit does not respond to ibln() though. (e.g. findlisteners.c does not work for this reason). I think the 5334B is from the late 80s, so old but not ancient HPIB.Is it unusual or not uncommon for older GPIB gear to fail on ibln()?(perhaps this only works on IEEE 488.2 devices) Michael |
|
From: Philip P. <li...@ph...> - 2025-08-14 18:00:34
|
On 11/08/2025 02:36, Hernán Freschi wrote: > Hi, > mine certainly does not look anything like that video. Here's a photo of > the insides of my 82357B https://i.imgur.com/iJXaqzg.jpeg <https:// > i.imgur.com/iJXaqzg.jpeg>. It's well built but it doesn't really look > like an official product. Certainly the part number lasered off is > rather unusual. I think in HP era a major hardware change like this > would probably be released as an 82357C hehe. > > I did try it with Keysight's drivers and it worked "more or less". It > seemed to work with read/write commands. But I needed to open it in > Board mode to send a GET (Group Execute Trigger) command and it > segfaulted when I tried opening GPIB0::INTFC. > > My guess is that this is a "functionally equivalent" clone that > implements good enough compatibility and that's it. It doesn't even try > to use Cypress chips and copy Keysight's firmware. > > I tried shorting pins on the unpopulated header to see if I could make > it boot in bootloader mode, to see if it's at least detected as an FX2 > chip, but nothing changed. I'd be willing to bet that the lasered chip is some kind of ARM Cortex microcontroller. The 10pin header is probably an ARM JTAG one, in that case. If you can connect a JTAG pod up to it, you can probably do an ID read and identify the chip. Either way, I've never known Agilent/Keysight to laser the markings off of chips -- they usually use 18xx-xxxx house numbers but even that's rare these days. I'm willing to bet this is a clone, and someone's decided to "clone" the protocol after the firmware has been loaded, and only implemented the bare minimum. -- Phil. ph...@ph... http://www.philpem.me.uk |
|
From: dave p. <dpe...@gm...> - 2025-08-13 07:15:54
|
Hi Stanley, We don't have a spec. What problem are you seeing with the fifo's ? -dave On Mon, 11 Aug 2025 at 18:06, Stanley Allen <st...@ne...> wrote: > We're trying to resolve a problem with using the fifo/accel logic on the > Keysight 82351B. We've tried to get some descriptive documentation from > Keysight but they only have a table of bit fields. > > Is a true spec available? > > Stanley > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: dave p. <dpe...@gm...> - 2025-08-13 07:14:24
|
Hi Chris,
What version of linux-gpib are you using and which shield ?
cheers,
-Dave
On Wed, 13 Aug 2025 at 06:59, quips_roofing.0t--- via Linux-gpib-general <
lin...@li...> wrote:
> Hi, hoping I could get some help. I’m using a pi with a GPIB shield.
>
> I can query for devices on the GPIB bus, but only once. After that a
> reboot of the pi is required to get the bus to respond again.
>
>
>
> import gpib
>
> def select_device_with_identity(devices,desired_identity):
>
> for address, identity in devices:
> if desired_identity in identity:
> return address, identity
>
> return None, None # No matching device found
>
> def query_hpib_devices():
> # List to store device identities
> device_identities = []
>
> # Assuming GPIB board index 0, adjust if your board index differs
> board_index = 0
>
> # Loop through GPIB device addresses 0 to 30
> for device_address in range(0, 31):
> try:
> # Open the device at the given address
> device = gpib.dev(board_index, device_address)
>
> # Set the timeout for operations (e.g., T10s for 10 seconds)
> gpib.timeout(device, gpib.T10s)
>
> # Clear the device
> gpib.clear(device)
>
> # Send the identification query
> gpib.write(device, "*IDN?")
>
> # Read the response
> response = gpib.read(device, 1024)
>
> # If we get a response, add it to our list
> if response:
> device_identities.append((device_address,
> response.strip()))
>
> # Close the device
> gpib.close(device)
>
> except gpib.GpibError as e:
> # An error usually means no device at this address or a
> communication error
> print(f"No response from address {device_address} or an error
> occurred: {e}")
>
> return device_identities
>
> # Get the list of connected HPIB devices
> devices = query_hpib_devices()
>
> # Print out the list of devices
> for address, identity in devices:
> print(f"Device at address {address}: {identity}”)
>
>
>
>
> The first run of the code finds the device on the bus as expected (device
> 7) and returns its correct identity. The second run of the code receives an
> error when it finds the device -
>
> No response from address 0 or an error occurred: write() error: No such device (errno: 19)
> No response from address 1 or an error occurred: write() error: No such device (errno: 19)
> No response from address 2 or an error occurred: write() error: No such device (errno: 19)
> No response from address 3 or an error occurred: write() error: No such device (errno: 19)
> No response from address 4 or an error occurred: write() error: No such device (errno: 19)
> No response from address 5 or an error occurred: write() error: No such device (errno: 19)
> No response from address 6 or an error occurred: write() error: No such device (errno: 19)
> No response from address 7 or an error occurred: read() failed: A read or write of data bytes has been aborted, possibly due to a timeout or reception of a device clear command.
> No response from address 8 or an error occurred: write() error: No such device (errno: 19)
> No response from address 9 or an error occurred: write() error: No such device (errno: 19)
> No response from address 10 or an error occurred: write() error: No such device (errno: 19)
> No response from address 11 or an error occurred: write() error: No such device (errno: 19)
> No response from address 12 or an error occurred: write() error: No such device (errno: 19)
> …..
>
>
>
> This will then persist until the pi is rebooted. Powercycling the GPIB device has no effect.
>
>
> Glib.conf looks like -
>
>
> interface {
>
> minor = 0 /* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
>
> board_type = "gpib_bitbang" /* name of the driver */
>
> name = "raspi_gpio_interface" /* optional name, allows you to get a board descriptor using ibfind() */
>
> pad = 0 /* primary address of interface */
>
> sad = 0 /* secondary address of interface */
>
> eos = 0x0a /* EOS Byte, 0xa is newline and 0xd is carriage return */
>
> set-reos = yes /* Terminate read if EOS */
>
> set-bin = no /* Compare EOS 8-bit */
>
> set-xeos = no /* Assert EOI whenever EOS byte is sent */
>
> set-eot = yes /* Assert EOI with last byte on writes */
>
> timeout = T30s
>
> /* 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) */
>
>
> master = yes /* interface board is system controller */
>
> }
>
>
> Advice appreciated,
> Thanks,
> Chris
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
|
|
From: marcello.carla <mar...@gm...> - 2025-08-13 07:13:53
|
Dear Chris,
the following informations would be of help, to make clear if the
problem is in the gpib_bitbang module or in the python wrapper:
1) What GPIB shield has been used.
2) The command used to load the gpib_bitbang module.
3) The value of the pin_map and sn7516x_used parameters (obtainable with
"sudo cat /sys/module/gpib_bitbang/parameters/pin_map" and "sudo cat
/sys/module/gpib_bitbang/parameters/sn7516x_used"
4) Any message from the debug system (obtainable from a dedicated window
with "journalctl -f", to be activated before starting all other operations).
5) The result of a test of the device with the ibtest utility.
Thanks
Marcello
On 8/13/25 06:57, quips_roofing.0t--- via Linux-gpib-general wrote:
> Hi, hoping I could get some help. I’m using a pi with a GPIB shield.
>
> I can query for devices on the GPIB bus, but only once. After that a
> reboot of the pi is required to get the bus to respond again.
>
>
>
> import gpib
>
> def select_device_with_identity(devices,desired_identity):
> for address, identity in devices:
> if desired_identity in identity:
> return address, identity
>
> return None, None # No matching device found
>
> def query_hpib_devices():
> # List to store device identities
> device_identities = []
>
> # Assuming GPIB board index 0, adjust if your board index differs
> board_index = 0
>
> # Loop through GPIB device addresses 0 to 30
> for device_address in range(0, 31):
> try:
> # Open the device at the given address
> device = gpib.dev(board_index, device_address)
>
> # Set the timeout for operations (e.g., T10s for 10 seconds)
> gpib.timeout(device, gpib.T10s)
>
> # Clear the device
> gpib.clear(device)
>
> # Send the identification query
> gpib.write(device, "*IDN?")
>
> # Read the response
> response = gpib.read(device, 1024)
>
> # If we get a response, add it to our list
> if response:
> device_identities.append((device_address, response.strip()))
>
> # Close the device
> gpib.close(device)
>
> except gpib.GpibError as e:
> # An error usually means no device at this address or a
> communication error
> print(f"No response from address {device_address} or an
> error occurred: {e}")
>
> return device_identities
>
> # Get the list of connected HPIB devices
> devices = query_hpib_devices()
>
> # Print out the list of devices
> for address, identity in devices:
> print(f"Device at address {address}: {identity}”)
>
>
>
>
> The first run of the code finds the device on the bus as expected
> (device 7) and returns its correct identity. The second run of the
> code receives an error when it finds the device -
>
> No response from address 0 or an error occurred: write() error: No
> such device (errno: 19) No response from address 1 or an error
> occurred: write() error: No such device (errno: 19) No response from
> address 2 or an error occurred: write() error: No such device (errno:
> 19) No response from address 3 or an error occurred: write() error: No
> such device (errno: 19) No response from address 4 or an error
> occurred: write() error: No such device (errno: 19) No response from
> address 5 or an error occurred: write() error: No such device (errno:
> 19) No response from address 6 or an error occurred: write() error: No
> such device (errno: 19) No response from address 7 or an error
> occurred: read() failed: A read or write of data bytes has been
> aborted, possibly due to a timeout or reception of a device clear
> command. No response from address 8 or an error occurred: write()
> error: No such device (errno: 19) No response from address 9 or an
> error occurred: write() error: No such device (errno: 19) No response
> from address 10 or an error occurred: write() error: No such device
> (errno: 19) No response from address 11 or an error occurred: write()
> error: No such device (errno: 19) No response from address 12 or an
> error occurred: write() error: No such device (errno: 19) …..
> This will then persist until the pi is rebooted. Powercycling the GPIB
> device has no effect.
> Glib.conf looks like -
> interface {
> minor = 0 /* board index, minor = 0 uses
> /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
> board_type = "gpib_bitbang" /* name of the driver */
> name = "raspi_gpio_interface" /* optional name, allows you
> to get a board descriptor using ibfind() */
> pad = 0 /* primary address of
> interface */
> sad = 0 /* secondary address of
> interface */
> eos = 0x0a /* EOS Byte, 0xa is newline and 0xd is
> carriage return */
> set-reos = yes /* Terminate read if EOS */
> set-bin = no /* Compare EOS 8-bit */
> set-xeos = no /* Assert EOI whenever EOS byte is sent */
> set-eot = yes /* Assert EOI with last byte on writes */
> timeout = T30s
> /* 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) */
> master = yes /* interface board is system controller */
> }
> Advice appreciated,
> Thanks,
> Chris
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
|
|
From: <qui...@ic...> - 2025-08-13 04:58:22
|
Hi, hoping I could get some help. I’m using a pi with a GPIB shield.
I can query for devices on the GPIB bus, but only once. After that a reboot of the pi is required to get the bus to respond again.
import gpib
def select_device_with_identity(devices,desired_identity):
for address, identity in devices:
if desired_identity in identity:
return address, identity
return None, None # No matching device found
def query_hpib_devices():
# List to store device identities
device_identities = []
# Assuming GPIB board index 0, adjust if your board index differs
board_index = 0
# Loop through GPIB device addresses 0 to 30
for device_address in range(0, 31):
try:
# Open the device at the given address
device = gpib.dev(board_index, device_address)
# Set the timeout for operations (e.g., T10s for 10 seconds)
gpib.timeout(device, gpib.T10s)
# Clear the device
gpib.clear(device)
# Send the identification query
gpib.write(device, "*IDN?")
# Read the response
response = gpib.read(device, 1024)
# If we get a response, add it to our list
if response:
device_identities.append((device_address, response.strip()))
# Close the device
gpib.close(device)
except gpib.GpibError as e:
# An error usually means no device at this address or a communication error
print(f"No response from address {device_address} or an error occurred: {e}")
return device_identities
# Get the list of connected HPIB devices
devices = query_hpib_devices()
# Print out the list of devices
for address, identity in devices:
print(f"Device at address {address}: {identity}”)
The first run of the code finds the device on the bus as expected (device 7) and returns its correct identity. The second run of the code receives an error when it finds the device -
No response from address 0 or an error occurred: write() error: No such device (errno: 19)
No response from address 1 or an error occurred: write() error: No such device (errno: 19)
No response from address 2 or an error occurred: write() error: No such device (errno: 19)
No response from address 3 or an error occurred: write() error: No such device (errno: 19)
No response from address 4 or an error occurred: write() error: No such device (errno: 19)
No response from address 5 or an error occurred: write() error: No such device (errno: 19)
No response from address 6 or an error occurred: write() error: No such device (errno: 19)
No response from address 7 or an error occurred: read() failed: A read or write of data bytes has been aborted, possibly due to a timeout or reception of a device clear command.
No response from address 8 or an error occurred: write() error: No such device (errno: 19)
No response from address 9 or an error occurred: write() error: No such device (errno: 19)
No response from address 10 or an error occurred: write() error: No such device (errno: 19)
No response from address 11 or an error occurred: write() error: No such device (errno: 19)
No response from address 12 or an error occurred: write() error: No such device (errno: 19)
…..
This will then persist until the pi is rebooted. Powercycling the GPIB device has no effect.
Glib.conf looks like -
interface {
minor = 0 /* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
board_type = "gpib_bitbang" /* name of the driver */
name = "raspi_gpio_interface" /* optional name, allows you to get a board descriptor using ibfind() */
pad = 0 /* primary address of interface */
sad = 0 /* secondary address of interface */
eos = 0x0a /* EOS Byte, 0xa is newline and 0xd is carriage return */
set-reos = yes /* Terminate read if EOS */
set-bin = no /* Compare EOS 8-bit */
set-xeos = no /* Assert EOI whenever EOS byte is sent */
set-eot = yes /* Assert EOI with last byte on writes */
timeout = T30s
/* 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) */
master = yes /* interface board is system controller */
}
Advice appreciated,
Thanks,
Chris |
|
From: Stanley A. <st...@ne...> - 2025-08-11 16:05:38
|
We're trying to resolve a problem with using the fifo/accel logic on the Keysight 82351B. We've tried to get some descriptive documentation from Keysight but they only have a table of bit fields. Is a true spec available? Stanley |
|
From: Hernán F. <hj...@hj...> - 2025-08-11 01:58:32
|
Hi, mine certainly does not look anything like that video. Here's a photo of the insides of my 82357B https://i.imgur.com/iJXaqzg.jpeg. It's well built but it doesn't really look like an official product. Certainly the part number lasered off is rather unusual. I think in HP era a major hardware change like this would probably be released as an 82357C hehe. I did try it with Keysight's drivers and it worked "more or less". It seemed to work with read/write commands. But I needed to open it in Board mode to send a GET (Group Execute Trigger) command and it segfaulted when I tried opening GPIB0::INTFC. My guess is that this is a "functionally equivalent" clone that implements good enough compatibility and that's it. It doesn't even try to use Cypress chips and copy Keysight's firmware. I tried shorting pins on the unpopulated header to see if I could make it boot in bootloader mode, to see if it's at least detected as an FX2 chip, but nothing changed. On Sun, Aug 10, 2025 at 8:48 PM Jim Houston <ji...@ov...> wrote: > Hi, > > I was lucky and my 82357B mostly worked. I did have a problem using it > with an HP3478A > which took me down the rabbit hole of USB traces and logic analyzer > traces to debug. > That was 2 years ago so I have forgotten everything. > > I find it hard to imagine anyone going to the trouble to clone an > 82357B. It seems > more likely that Keysight would quietly release a new revision which > might not be > compatible with the open source driver. > I wonder if your 82357B works with the Keysight I/O libraries? They > have a Linux version. > I played with this when I was chasing my problem. > > This youtube video titled "Inside the clone Agilent 82357B" looks > exactly like my > 82357B which I'm sure is genuine. > https://www.youtube.com/watch?v=r3oedj3DCiU > > While I have been happy with Linux GPIB I would also recommend this > project: > https://github.com/xyphro/UsbGpib > > Jim Houston > > On 8/10/25 16:15, Hernán Freschi wrote: > > I got an obvious fake 82357B from ebay. It's branded Keysight but when > > I opened it up it has a lasered 64-pin TQFP IC and a few passives and > > that's it. > > > > I tried it with the agilent_82357a driver. gpib_config succeeds but it > > doesn't really work. All 3 LEDs remain lit. > > > > When plugged in, the USB ID is 0957:0718 Agilent Technologies, Inc. > > 82357B GPIB Interface. So it's not booting as 0957:0518 awaiting for > > firmware. I believe genuine ones will always boot as bootloader and > > then firmware will be uploaded. > > > > I thought I may be able to upload a different firmware but without any > > SMD markings, it's impossible to tell if this is even a Cypress device > > that can be programmed with fxload. > > > > full lsusb dump: > > > > sudo lsusb -vd 0957:0718 > > > > Bus 003 Device 003: ID 0957:0718 Agilent Technologies, Inc. 82357B > > GPIB Interface > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 2.00 > > bDeviceClass 0 > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 64 > > idVendor 0x0957 Agilent Technologies, Inc. > > idProduct 0x0718 82357B GPIB Interface > > bcdDevice 0.00 > > iManufacturer 1 Agilent Technologies, Inc. > > iProduct 2 82357B () > > iSerial 5 MY54153256 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 0x0027 > > bNumInterfaces 1 > > bConfigurationValue 1 > > iConfiguration 3 HIGHSPEED > > bmAttributes 0x80 > > (Bus Powered) > > MaxPower 500mA > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 3 > > bInterfaceClass 0 > > bInterfaceSubClass 0 > > bInterfaceProtocol 0 > > iInterface 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x82 EP 2 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 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 0x88 EP 8 IN > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0008 1x 8 bytes > > bInterval 1 > > Device Qualifier (for other device speed): > > bLength 10 > > bDescriptorType 6 > > bcdUSB 2.00 > > bDeviceClass 0 > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 64 > > bNumConfigurations 1 > > Device Status: 0x0000 > > (Bus Powered) > > > > When trying to open the device in board mode: > > > > ibtest > > Do you wish to open a (d)evice or an interface (b)oard? > > (you probably want to open a device): d > > enter primary gpib address for device you wish to open [0-30]: usb > > trying to open pad = 0 on /dev/gpib0 ... > > ibdev: address conflict with board pad > > ibdev error > > > > ibsta = 0x100 < CMPL > > > iberr= 4 > > > > ibcntl = 0 > > Aborted (core dumped) > > > > When trying to write with the device unplugged from the GPIB bus: > > > > ibtest > > Do you wish to open a (d)evice or an interface (b)oard? > > (you probably want to open a device): d > > enter primary gpib address for device you wish to open [0-30]: 12 > > trying to open pad = 12 on /dev/gpib0 ... > > > > : w > > enter a string to send to your device: *IDN? > > sending string: *IDN? > > > > gpib status is: > > ibsta = 0x8000 < ERR > > > iberr= 2 > > ENOL 2: No listeners > > > > ibcntl = 0 > > > > > > if I try with connecting it to the bus I'll get a TIMO error. > > > > Interestingly enough, when trying to open this device in board mode, > > using Keysight-VISA I get a segfault > > > > Has anyone had any experiences with these particular clones? > > > > > > _______________________________________________ > > 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: Jim H. <ji...@ov...> - 2025-08-10 23:47:11
|
Hi, I was lucky and my 82357B mostly worked. I did have a problem using it with an HP3478A which took me down the rabbit hole of USB traces and logic analyzer traces to debug. That was 2 years ago so I have forgotten everything. I find it hard to imagine anyone going to the trouble to clone an 82357B. It seems more likely that Keysight would quietly release a new revision which might not be compatible with the open source driver. I wonder if your 82357B works with the Keysight I/O libraries? They have a Linux version. I played with this when I was chasing my problem. This youtube video titled "Inside the clone Agilent 82357B" looks exactly like my 82357B which I'm sure is genuine. https://www.youtube.com/watch?v=r3oedj3DCiU While I have been happy with Linux GPIB I would also recommend this project: https://github.com/xyphro/UsbGpib Jim Houston On 8/10/25 16:15, Hernán Freschi wrote: > I got an obvious fake 82357B from ebay. It's branded Keysight but when > I opened it up it has a lasered 64-pin TQFP IC and a few passives and > that's it. > > I tried it with the agilent_82357a driver. gpib_config succeeds but it > doesn't really work. All 3 LEDs remain lit. > > When plugged in, the USB ID is 0957:0718 Agilent Technologies, Inc. > 82357B GPIB Interface. So it's not booting as 0957:0518 awaiting for > firmware. I believe genuine ones will always boot as bootloader and > then firmware will be uploaded. > > I thought I may be able to upload a different firmware but without any > SMD markings, it's impossible to tell if this is even a Cypress device > that can be programmed with fxload. > > full lsusb dump: > > sudo lsusb -vd 0957:0718 > > Bus 003 Device 003: ID 0957:0718 Agilent Technologies, Inc. 82357B > GPIB Interface > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0957 Agilent Technologies, Inc. > idProduct 0x0718 82357B GPIB Interface > bcdDevice 0.00 > iManufacturer 1 Agilent Technologies, Inc. > iProduct 2 82357B () > iSerial 5 MY54153256 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x0027 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 3 HIGHSPEED > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 0 > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 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 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 0x88 EP 8 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 1 > Device Qualifier (for other device speed): > bLength 10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > bNumConfigurations 1 > Device Status: 0x0000 > (Bus Powered) > > When trying to open the device in board mode: > > ibtest > Do you wish to open a (d)evice or an interface (b)oard? > (you probably want to open a device): d > enter primary gpib address for device you wish to open [0-30]: usb > trying to open pad = 0 on /dev/gpib0 ... > ibdev: address conflict with board pad > ibdev error > > ibsta = 0x100 < CMPL > > iberr= 4 > > ibcntl = 0 > Aborted (core dumped) > > When trying to write with the device unplugged from the GPIB bus: > > ibtest > Do you wish to open a (d)evice or an interface (b)oard? > (you probably want to open a device): d > enter primary gpib address for device you wish to open [0-30]: 12 > trying to open pad = 12 on /dev/gpib0 ... > > : w > enter a string to send to your device: *IDN? > sending string: *IDN? > > gpib status is: > ibsta = 0x8000 < ERR > > iberr= 2 > ENOL 2: No listeners > > ibcntl = 0 > > > if I try with connecting it to the bus I'll get a TIMO error. > > Interestingly enough, when trying to open this device in board mode, > using Keysight-VISA I get a segfault > > Has anyone had any experiences with these particular clones? > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general |
|
From: Hernán F. <hj...@hj...> - 2025-08-10 20:45:26
|
I got an obvious fake 82357B from ebay. It's branded Keysight but when I
opened it up it has a lasered 64-pin TQFP IC and a few passives and that's
it.
I tried it with the agilent_82357a driver. gpib_config succeeds but it
doesn't really work. All 3 LEDs remain lit.
When plugged in, the USB ID is 0957:0718 Agilent Technologies, Inc. 82357B
GPIB Interface. So it's not booting as 0957:0518 awaiting for firmware. I
believe genuine ones will always boot as bootloader and then firmware will
be uploaded.
I thought I may be able to upload a different firmware but without any SMD
markings, it's impossible to tell if this is even a Cypress device that can
be programmed with fxload.
full lsusb dump:
sudo lsusb -vd 0957:0718
Bus 003 Device 003: ID 0957:0718 Agilent Technologies, Inc. 82357B GPIB
Interface
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0957 Agilent Technologies, Inc.
idProduct 0x0718 82357B GPIB Interface
bcdDevice 0.00
iManufacturer 1 Agilent Technologies, Inc.
iProduct 2 82357B ()
iSerial 5 MY54153256
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0027
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 3 HIGHSPEED
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 0
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 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 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 0x88 EP 8 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
When trying to open the device in board mode:
ibtest
Do you wish to open a (d)evice or an interface (b)oard?
(you probably want to open a device): d
enter primary gpib address for device you wish to open [0-30]: usb
trying to open pad = 0 on /dev/gpib0 ...
ibdev: address conflict with board pad
ibdev error
ibsta = 0x100 < CMPL >
iberr= 4
ibcntl = 0
Aborted (core dumped)
When trying to write with the device unplugged from the GPIB bus:
ibtest
Do you wish to open a (d)evice or an interface (b)oard?
(you probably want to open a device): d
enter primary gpib address for device you wish to open [0-30]: 12
trying to open pad = 12 on /dev/gpib0 ...
: w
enter a string to send to your device: *IDN?
sending string: *IDN?
gpib status is:
ibsta = 0x8000 < ERR >
iberr= 2
ENOL 2: No listeners
ibcntl = 0
if I try with connecting it to the bus I'll get a TIMO error.
Interestingly enough, when trying to open this device in board mode, using
Keysight-VISA I get a segfault
Has anyone had any experiences with these particular clones?
|
|
From: Michael K <vk...@ya...> - 2025-08-09 03:35:32
|
So the next merge window would close mid October for a 6.18 stable release at the end of November. |
|
From: Michael K <vk...@ya...> - 2025-08-09 03:25:23
|
https://github.com/torvalds/linux/commit/1641684528815bb7e85737d5d2bceb551c55d5a8 Merge tag 'staging-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging updates from Greg KH: "Here is the "big" set of staging driver changes for 6.17-rc1. That's in quotes as it really isn't all that big of a set of changes this development cycle at all. Major things that stand out are: - gpib cleanups and tweaks with the majority of the big issues now taken care of. Odds are it will move out of staging/ in the next merge window if all goes well. |
|
From: Hernán F. <hj...@hj...> - 2025-08-06 13:10:21
|
dave, thanks for your suggestion. it almost worked. the only change I needed to make was to send the payload as a byte array instead of a string that is: replace: string(b) for: bytes(b) cheers El mié, 6 ago 2025, 04:56, dave penkler <dpe...@gm...> escribió: > There is no python binding for TriggerList() but you can do it with > gpib.command(board, string) > where board is the minor of your adapter and string is composed of the > unlisten command UNL 0x3f, the listen addresses of the instruments to > trigger and the GET command 0x08. > For device addresses 4 and 5 you could do something like: > > board = 0 > pad1 = 4 > pad2 = 5 > b = bytearray(4) > b[0] = 0x3f > b[1] = 0x20 + pad1 > b[2] = 0x20 + pad2 > b[3] = 0x08 > string = str(b) > gpib.command(board, string) > > On Wed, 6 Aug 2025 at 06:50, Hernán Freschi <hj...@hj...> wrote: > >> I'm using the gpib module in python and I've set up a couple instruments, >> a 34401A and a 53131A for external triggers. >> >> then I trigger them with >> gpib.trigger(voltmeter) >> gpib.trigger(counter) >> >> this is more than adequate for my application but given that both >> instruments support GET (group execute trigger) command, I'd like to >> trigger them this way. But I don't know how to call this from python. The >> manual for the 34401A mentions: >> >> You can also trigger the multimeter from the HP-IB interface by >> sending the IEEE-488 Group Execute Trigger (GET ) message. >> The multimeter must be in the wait-for-trigger state. The following >> statement shows how to send a GET using HP BASIC. >> >> TRIGGER 722 Group Execute Trigger >> >> How can I do this from Python? >> _______________________________________________ >> Linux-gpib-general mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general >> >> |
|
From: Matthias G. <m_g...@wi...> - 2025-08-06 11:04:28
|
Am 06.08.25 um 13:00 schrieb dave penkler: > It is going to take a while before the drivers appear in a mainline > kernel shipped by the distros. > I will release a separate user only package when the drivers do appear > in the mainline. > There will be differences between the user package just for mainline > drivers and the user package co-packaged with the kernel drivers. > In the meantime you can package the user and kernel parts separately > as Michael does for Fedora. > -dave > > Hi dave, thanks for considering this. Looking forward to when this happens; I'll get this enabled in the Debian kernel builds once it's been accepted in mainline. -- Freundliche Grüsse / Best regards Matthias Geiger __________________________________________________________________ Matthias Geiger Werkstudent Forschung & Entwicklung/Research & Development Phone : +49-6441-609-3004 Email : m_g...@wi... URL : www.wiwa.de WIWA Wilhelm Wagner GmbH & Co. KG Gewerbestrasse 1-3, 35633 Lahnau, Germany Besucheranschrift/visitor address: Georg-Ohm-Strasse 12, 35633 Lahnau, Germany AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363) UST-ID Nr: / VAT-No: DE113745802 Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber |
|
From: dave p. <dpe...@gm...> - 2025-08-06 11:00:35
|
It is going to take a while before the drivers appear in a mainline kernel shipped by the distros. I will release a separate user only package when the drivers do appear in the mainline. There will be differences between the user package just for mainline drivers and the user package co-packaged with the kernel drivers. In the meantime you can package the user and kernel parts separately as Michael does for Fedora. -dave On Wed, 6 Aug 2025 at 10:03, Matthias Geiger <m_g...@wi...> wrote: > Am 06.08.25 um 01:09 schrieb Michael K: > > Hi Matthias, > > I package up the Fedora RPMs from a zip of the git repo. > > (https://copr.fedorainfracloud.org/coprs/vk2bea/GPIB/) > > > > The RPM spec defines what and how the packages built from the source. > > The kernel module is built as a dkms module (so it recompiles when a > > new kernel is installed). > > From the SRPM the binary packages are created for installation .... > > > > dkms-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.noarch.rpm > > guile18-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > linux-gpib-devel-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > linux-gpib-doc-4.3.7-30.20250805git0fc6e300.fc42.noarch.rpm > > perl-LinuxGpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > php-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > python3-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > tcl-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > > > If the user doesn't want to install the kernel module, they don't > > install the dkms-linix-gpib package. > > I presume the same could be done with the debian (apt) build system. > > > > Michael > > > Hi Micheal, > > yeah, I see the point of shipping the dkms package. However, with the > driver being in mainline soon, I don't see the point of still providing > it in Debian, because it will be enabled anyway in the kernel. > > As all new packages land in unstable first anyway, I think there is > little benefit for me to enable then in Debian then. > > For me this is mostly a tooling problem though, because if I only want > to provide the userspace tools then I need to jump through some hoops to > get a tarball only containing those. > > Not really a big issue for me; however, I think it's sensible to have > two separate tarballs given that it will be mainline soon. > > -- > Freundliche Grüsse / Best regards > > Matthias Geiger > __________________________________________________________________ > Matthias Geiger > Werkstudent > Forschung & Entwicklung/Research & Development > > Phone : +49-6441-609-3004 > Email : m_g...@wi... > URL : www.wiwa.de > > WIWA Wilhelm Wagner GmbH & Co. KG > Gewerbestrasse 1-3, 35633 Lahnau, Germany > Besucheranschrift/visitor address: > Georg-Ohm-Strasse 12, 35633 Lahnau, Germany > > AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363) > UST-ID Nr: / VAT-No: DE113745802 > Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte > Weber > > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Matthias G. <m_g...@wi...> - 2025-08-06 08:03:04
|
Am 06.08.25 um 01:09 schrieb Michael K: > Hi Matthias, > I package up the Fedora RPMs from a zip of the git repo. > (https://copr.fedorainfracloud.org/coprs/vk2bea/GPIB/) > > The RPM spec defines what and how the packages built from the source. > The kernel module is built as a dkms module (so it recompiles when a > new kernel is installed). > From the SRPM the binary packages are created for installation .... > > dkms-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.noarch.rpm > guile18-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > linux-gpib-devel-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > linux-gpib-doc-4.3.7-30.20250805git0fc6e300.fc42.noarch.rpm > perl-LinuxGpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > php-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > python3-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > tcl-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm > > If the user doesn't want to install the kernel module, they don't > install the dkms-linix-gpib package. > I presume the same could be done with the debian (apt) build system. > > Michael > Hi Micheal, yeah, I see the point of shipping the dkms package. However, with the driver being in mainline soon, I don't see the point of still providing it in Debian, because it will be enabled anyway in the kernel. As all new packages land in unstable first anyway, I think there is little benefit for me to enable then in Debian then. For me this is mostly a tooling problem though, because if I only want to provide the userspace tools then I need to jump through some hoops to get a tarball only containing those. Not really a big issue for me; however, I think it's sensible to have two separate tarballs given that it will be mainline soon. -- Freundliche Grüsse / Best regards Matthias Geiger __________________________________________________________________ Matthias Geiger Werkstudent Forschung & Entwicklung/Research & Development Phone : +49-6441-609-3004 Email : m_g...@wi... URL : www.wiwa.de WIWA Wilhelm Wagner GmbH & Co. KG Gewerbestrasse 1-3, 35633 Lahnau, Germany Besucheranschrift/visitor address: Georg-Ohm-Strasse 12, 35633 Lahnau, Germany AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363) UST-ID Nr: / VAT-No: DE113745802 Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber |
|
From: dave p. <dpe...@gm...> - 2025-08-06 07:56:05
|
There is no python binding for TriggerList() but you can do it with gpib.command(board, string) where board is the minor of your adapter and string is composed of the unlisten command UNL 0x3f, the listen addresses of the instruments to trigger and the GET command 0x08. For device addresses 4 and 5 you could do something like: board = 0 pad1 = 4 pad2 = 5 b = bytearray(4) b[0] = 0x3f b[1] = 0x20 + pad1 b[2] = 0x20 + pad2 b[3] = 0x08 string = str(b) gpib.command(board, string) On Wed, 6 Aug 2025 at 06:50, Hernán Freschi <hj...@hj...> wrote: > I'm using the gpib module in python and I've set up a couple instruments, > a 34401A and a 53131A for external triggers. > > then I trigger them with > gpib.trigger(voltmeter) > gpib.trigger(counter) > > this is more than adequate for my application but given that both > instruments support GET (group execute trigger) command, I'd like to > trigger them this way. But I don't know how to call this from python. The > manual for the 34401A mentions: > > You can also trigger the multimeter from the HP-IB interface by > sending the IEEE-488 Group Execute Trigger (GET ) message. > The multimeter must be in the wait-for-trigger state. The following > statement shows how to send a GET using HP BASIC. > > TRIGGER 722 Group Execute Trigger > > How can I do this from Python? > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Hernán F. <hj...@hj...> - 2025-08-06 04:50:03
|
I'm using the gpib module in python and I've set up a couple instruments, a 34401A and a 53131A for external triggers. then I trigger them with gpib.trigger(voltmeter) gpib.trigger(counter) this is more than adequate for my application but given that both instruments support GET (group execute trigger) command, I'd like to trigger them this way. But I don't know how to call this from python. The manual for the 34401A mentions: You can also trigger the multimeter from the HP-IB interface by sending the IEEE-488 Group Execute Trigger (GET ) message. The multimeter must be in the wait-for-trigger state. The following statement shows how to send a GET using HP BASIC. TRIGGER 722 Group Execute Trigger How can I do this from Python? |
|
From: Michael K <vk...@ya...> - 2025-08-05 23:10:17
|
Hi Matthias, I package up the Fedora RPMs from a zip of the git repo. (https://copr.fedorainfracloud.org/coprs/vk2bea/GPIB/) The RPM spec defines what and how the packages built from the source. The kernel module is built as a dkms module (so it recompiles when a new kernel is installed).From the SRPM the binary packages are created for installation .... dkms-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.noarch.rpm guile18-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm linux-gpib-devel-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm linux-gpib-doc-4.3.7-30.20250805git0fc6e300.fc42.noarch.rpm perl-LinuxGpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm php-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm python3-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm tcl-linux-gpib-4.3.7-30.20250805git0fc6e300.fc42.x86_64.rpm If the user doesn't want to install the kernel module, they don't install the dkms-linix-gpib package.I presume the same could be done with the debian (apt) build system. Michael On Tuesday, August 5, 2025 at 03:51:23 AM EDT, Matthias Geiger <m_g...@wi...> wrote: Hi all, currently, the released tarball contains both the kernel and userspace tarballs. As the kernel components are close to being mainline, it would make sense IMO to release them separately from now on. This would allow users to download only the userspace parts if they have already installed the kernel module. It would also ease packaging as I am currently working on getting the userspace components provided as official Debian package. -- Freundliche Grüsse / Best regards Matthias Geiger __________________________________________________________________ Matthias Geiger Werkstudent Forschung & Entwicklung/Research & Development Phone : +49-6441-609-3004 Email : m_g...@wi... URL : www.wiwa.de WIWA Wilhelm Wagner GmbH & Co. KG Gewerbestrasse 1-3, 35633 Lahnau, Germany Besucheranschrift/visitor address: Georg-Ohm-Strasse 12, 35633 Lahnau, Germany AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363) UST-ID Nr: / VAT-No: DE113745802 Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber _______________________________________________ Linux-gpib-general mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-gpib-general |
|
From: Matthias G. <m_g...@wi...> - 2025-08-05 07:50:46
|
Hi all, currently, the released tarball contains both the kernel and userspace tarballs. As the kernel components are close to being mainline, it would make sense IMO to release them separately from now on. This would allow users to download only the userspace parts if they have already installed the kernel module. It would also ease packaging as I am currently working on getting the userspace components provided as official Debian package. -- Freundliche Grüsse / Best regards Matthias Geiger __________________________________________________________________ Matthias Geiger Werkstudent Forschung & Entwicklung/Research & Development Phone : +49-6441-609-3004 Email : m_g...@wi... URL : www.wiwa.de WIWA Wilhelm Wagner GmbH & Co. KG Gewerbestrasse 1-3, 35633 Lahnau, Germany Besucheranschrift/visitor address: Georg-Ohm-Strasse 12, 35633 Lahnau, Germany AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363) UST-ID Nr: / VAT-No: DE113745802 Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber |
|
From: Matthias G. <m_g...@wi...> - 2025-08-04 13:07:58
|
Am 04.08.25 um 13:54 schrieb Wilhelm Kusian: > Hi Matthias, > > I’m not sure whether I understand your issue correctly. The HP3488A is > a Switch/Control unit that can be controlled remotely via GPIB. > HP82335 is a GPIB ISA interface card for the ISA-bus in old > motherboards. The interface card needs a Kernel module, but the > HP3488A does not. > Ah, I see. > If you would like to control the HP3488A via GPIB, you can write for > instance a python program that sends the comands via the GPIB using > linux-gpib. The commands for controlling the HP3488A remotely via GPIB > you’ll find in the description for the device, like this > https://www.keysight.com/us/en/assets/9018-05356/user-manuals/9018-05356.pdf > > > Thanks, already had the datasheet at hand. I was able to get the basic communication up and running with the python example from the repo. Will ask again in case I run into any issues. best, Matthias Geiger |
5 messages has been excluded from this view by a project administrator.
