Poking around in software I can't find a reason why Error 13 occurs. There's got to be a hardware difference between the VXI mainframe and this plain VME backplane, despite the standard saying that VXI is a superset of VME.

So let's look at the VXI frame again.

There's a little board in the VXI frame that supplies the ACFAIL* signal. Just two LM339 quad comparators. Disconnecting it does not result in the same behavior as the plain VME backplane.

Another look at the VXI backplane. What I presumed to be simple buffers are actually 74ACT32. Quad 2-Input OR gates. Maybe it is some bus arbitration issue? Maybe they are just used as buffers?

I cannot find a schematic for the backplane, of course not. And I couldn't find anything in the standard either.

I can buzz out the upper row without having to take the chassis apart.
First column are the OR-gate's pins, second the functions, third what they connect to. BGnIN* and BGnOUT* n = 1..4 are bus grant lines needed for busmastering. Those gates are not present on my plain VME backplane. But I have my doubts that this could be the reason. I doubt my meters even use busmastering. I scoped one of the lines out and couldn't see any activity.
Guess I have to take the chassis apart and maybe even go in there with a logic analyzer to find out what is causing Error 13.

And at this point I decided to give the PSU in the mainframe another chance. Turns out, it is fine as long as I keep that 200dB 240V mains powered fan connected. My poor ears

I will order replacement fans for this and have another look at the PSU again. But not now. Onward! No more rabbit holes.

I wasn't able to get a response from the command module on GPIB before. I found out why. My python setup is not working in the first place. Dug out some other piece of GPIB test gear I know works to figure that out.

But I also need to address the command module using a non zero secondary address (sad). You'd expect the CM to live at sad=0 and primary address (pad) whatever you set it to, in this case pad=9. But there is silence. You need to add 96 to the sad, at least for linux-gpib. What an odd quirk!

It lives! 🎉

Forcing pyvisa to use a GPIB resource by instantiating an instrument on the GPIB bus

inst = rm.open_resource('GPIB0::9::96::INSTR')

ValueError: Please install linux-gpib (Linux) or gpib-ctypes (Windows, Linux) to use this resource type. Note that installing gpib-ctypes will give you access to a broader range of functionalities.
No module named 'gpib'

Now, that would explain a few things.

Let's try gpib-ctypes then..

Whoops

gpib is a small wrapper module for libgpib.so supplied by the linux-gpib-user sources. The makefile installed it into /usr/local/lib/python3.12/dist-packages/ not /usr/lib/python3/dist-packages/, and my venv doesn't even use either path. D'oh

After moving the wrapper in the right place, plain gpib works, but pyvisa still segfaults. Great

ChatGPT starts to scare me.

I was hunting down this bug, through pyvisa, the bindings, into libgpib. And I figured I'll ask it for a few hints on how to approach it. It plainly asked me for the stack trace and immediately correctly determined where the bug was. It had the libgpib source in its training data and knew about the bug. It only needed the trace to verify that it's indeed that particular bug that I triggered. Maybe it also had a discussion about it in its training data, but I couldn't find one and it claims it never saw one either.

I hate how it plays with our expectations and fears of intelligence in LLMs.