Bun's Lab – Telegram
Bun's Lab
147 subscribers
1.81K photos
102 videos
63 files
49 links
Electronics projects, vintæg computing, programming and repairs. A minimalist blog of sorts.
@BunsGarden @BunsNook
Download Telegram
Two of the commands mapped to the function keys by default there are these
Calls to
VXI:CONF:DLAD?
VXI:CONF:DLIS? 0
VXI:CONF:DLIS? 16
Using function keys F1 and F2.

It recognizes there being an instrument at LADDR 16
So, let's understand the output of DLIS?

The Command module:
- has device ID 0
- has no commander
- is made by manufacturer 4095 (guess that's HP)
- has the model code 1306 (HP E1306A)
- is in an unknown slot. For B sized mainframes this is always the case.
- has "Slot 0 Logical Address" of 0. Whatever that is
- is a HYBRID device
- takes up no memory space on the VXI bus
- has a memory offset of 0
- has a memory size of 0
- reports it's READY to receive commands
- not used
- not used
- not used
- the last field can contain strings. It lets us know there's been error 13

The multimeter:
- has device ID 16
- has device 0 as its commander
- is made by manufacturer 4095 (guess that's HP)
- has the model code 65344. It's an HP E1326B, so something seems odd there.
- is in an unknown slot. For B sized mainframes this is always the case.
- has "Slot 0 Logical Address" of 0. Odd that this is also 0
- is a REGISTER based device
- lives within the A16 address space of the VXI bus
- has a memory offset of 0
- has a memory size of 0
- reports it's READY to receive commands
- not used
- not used
- not used
- the last field can contain strings. It lets us know there's been error 13
Now, let's access those configuration registers
HP E1326B, E1411B User.pdf
1.9 MB
User manual for the HP E1326B and HP E1411B multimeters
Annoyingly enough, it returns the register contents as signed decimals. Ugh

And there is no way to change that.
- ID Register: 0b1111111111111111 = 0xFFFF
Makes sense, just as the manual said.
- Device Type Register: 0b1111111101000000 = 0xFF40
Also sane.
- Status Register: 0b1111111111001111 = 0xFFCF
Also sane.
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
😁1