Frank Mori Hess

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.

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,...

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...

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: status: unread --> closed [patches:#14] Allow 127 as secondary address Status: closed Group: Unstable (example) Created: Mon Oct 14, 2024 07:52 PM UTC by Boeingflieger Last Updated: Wed Oct 16, 2024 09:05 AM UTC Owner: nobody Attachments: allow_sad_127.patch (sourceforge.net) (2.9 kB; text/x-patch)...