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