#14 Allow 127 as secondary address
The constant gpib_addr_max = 30 (0x1E) is used to limit the range of both the primary and the secondary addresses. This is consistent with National Instrument GPIB documentation.
While that is always true for the PAD (31 is reserved for universal commands), it is not always true for the SAD where 127 (= 96 + 31 respectively 0x60 + 0x1F) is a valid address. At least it was in earlier HP-IB days.
For reference, two versions of the HP-IB Tutorial (in one the PAD is mentioned, in the other one the SAD)
and the HP 9121D/S command set where 0x1F is used to initiate the selftest.
HPIB_tutorial_HP.pdf
Tutorial Description of the Hewlett-Packard Interface Bus
Page 23
2.6.4 Secondary Commands
Secondary Commands consist of the ASCII characters 96-127 decimal.
hp-ib_tutorial_1980.pdf
5952-0 Tutorial Description of the Hewlett-Packard Interface Bus
Page 60
Regarding the IEEE-488/ANSI MC1.1/IEC 625-1 standards
There are 31 available primary Talk and Listen addresses. 0-30 are
available, 31 is reserved for the Universal Untalk and Universal Un-
listen commands.
HP Flexible Disc Drive Command Set
Appendix A
Page A-6
Command Table
8290X Compatible Commands
See also
#9 max address error
https://sourceforge.net/p/linux-gpib/bugs/9/
Thanks for this patch.
Applied 4dce09
-Dave
Hi Dave,
ieee 488.1 section 8.3.3 explicitly forbids secondary address 31.
Wasn't it used for that weird non-GPIB protocol?
On Fri, Jun 19, 2026 at 11:00 AM DaveP dpenkler@users.sourceforge.net wrote:
--
Frank
Related
Patches:
#14Hi Frank,
You are right section 6.3.3 forbids a secondary address of all ones. However there is no specific function assigned to this code by the standard and there are a bunch of devices out there that respond to secondary address 0x1f to trigger some or other function. So rather than the guys having to construct an ibcmd() with the illegal secondary address I figured that there was no harm in removing the restriction of max SAD to 0x1e.
-dave
I guess you're adding this for that non-GPIB "HP Flexible Disc Drive
Command Set" thing. I remember that guy's patch, it was horrible. It
added a backdoor that let the user break the library/driver by doing
arbitrary register writes to the hardware. Really, it should have
been done as adding a board level ioctl for setting/querying the
"protocol" which could be set to IEEE488 or to whatever the HPDrive
protocol is called. Then an optional driver function could be added
to handle the user changing the protocol. By default, drivers could
ignore it and the default behavior would be to return an "unsupported"
error on attempts to change the protocol away from the IEEE488
default.
On Fri, Jun 19, 2026 at 12:16 PM DaveP dpenkler@users.sourceforge.net wrote:
Hi Frank,
First of all, thank you for finally recognizing my patch after nearly three years. And to clarify: no, I am not the author of that non-GPIB "HP Flexible Disc Drive Command Set" patch.
My patch simply allows SAD 127—a fact I thoroughly explained and justified in the original description. I see absolutely no possibility of this being a backdoor. However, feel free to revert the patch if you must; it will only force me to fork the user part of the linux-gpib package for absolutely no good reason.
You are welcome,
Christian
I read the bug report again, but what was the justification? The bug
report said 31 used to be allowed before 488.1, well ok but who cares?
You can set your instrument's secondary address to something in the
0-30 range. You also say you are not the guy who cares about "HP
Flexible Disc Drive Command Set" so I'll ignore that part of the bug
report. Then you have a link to another bug report, which was a bug
about sad 30 being wrongly rejected, which was a valid bug but
unrelated to sad 31.
On Fri, Jun 19, 2026 at 2:50 PM Boeingflieger
boeingflieger@users.sourceforge.net wrote:
I'll also add that not all GPIB chips handle sad 31 "correctly".
Indeed, there is no reason they should as it is an illegal address.
So if the library is not going to reject it, every driver needs to
handle the possibility of the board getting assigned a SAD the
hardware can't handle.
Frank,
What you say is totaly reasonable. The use case we wanted to enable was to be able to address devices which have a SAD of 0x1f with ibrd() and ibwrt(). I will fix the check in internal_ibsad() to prevent a SAD of 0x1f from being assigned to a board while still allowing SAD 0x1f for remote devices.