AR488 problem: reading from one device causes reset in another

[intabits]

I've just made an AR488 GPIB interface adapter as described by WaveyDipole in the mega-thread on the subject.

But rather than each connected instrument having a dedicated controller, I preferred to have a single Arduino Nano with SN7516x drivers connected by a 26 way ribbon cable, daisy chained to simple adapter boards for each instrument.
While waiting for the adapter PCBs to be manufactured, I made the controller on a DIY PCB.



After resolving several minor issues, the interface worked very nicely, thanks in large part to the excellent manual.
I could control all the modes and functions of my HP3456A voltmeter, including reading it's measured values.

Then I attached my Systron Donner M107 DC voltage source, and was able to control all its functions as well.

But when I tried to read the M107's output voltage from the 3456 using "++READ", the M107 performed a reset, and then output nothing.
I could continue operating both devices - The only problem I've seen is this M107 reset when ++READing from the 3456.
After fooling around with commands, trying everything I could think of to solve the problem without success, I tried attaching a second HP3456A to see what that did.

(M107 is not calibrated)


To my surprise, I was able to read from 3456#2 without upsetting the M107, whereas reading from 3456#1 still caused a reset of the M107 every time.
So it seems not to be a fundamental problem, but rather something about meter #1 (or the M107)

Sample activity:-

Code: [Select]

** Connecting...
** Connected to AR488 GPIB Adapter ***

Send: ++ADDR 10             Select SD M107 DC voltage Source
Send: A1B2C3D4E5F6R1P1S     Set its output to 1.23456V

Send: ++ADDR 23             Select HP3456A #2
Send: ++READ                Read its value
Resp: +01.22889E+0          Cool!
Send: ++READ                And again...             
Resp: +01.22890E+0
Send: ++READ                And again...
Resp: +01.22895E+0

Send: ++ADDR 20             Select HP3456A #1
Send: ++READ                Read its value -> Also Resets the M107 !?
Resp: +000.1937E-3          Output is now 0v
Send: ++READ                And again...
Resp: +000.0000E-3
Send: ++READ                And again...
Resp: +000.0001E-3

** Disconnected **

Knowing very little about GPIB, I have no idea how to proceed with fixing this, so I'm hoping those with more experience in this areas can point me in the right direction.
(I have enabled the GPIB debug options in the firmware, but that shows identical messages when ++READing from both meters.)

Thanks in advance for any pointers...

[coromonadalix]

to go the cheap and safest way to go around your problem, i would use another gpib interface on your m107  keeping it separated from the others ...


but sure finding the problem is a must

not sure i would have made flat cable extenders .... ground loop, control voltages on the pins ?  even if you have used buffers on the controller side ?

1 data pin, 1 ground, 1 data pin,  etc ....

[Gribo]

1. Try with just DMM1 and the PSU connected to the chain.
2. Try without any device connected to the middle connector.
3. Get proper GPIB shielded cables ($$$).

[Kean]

@intabits I'd suggest keeping the ribbon cables as short as possible.
I can send you some old shielded GPIB cables if you don't have any.  Will need to dig out my box of them and see what lengths I have.

[intabits]

Thanks for the responses.

All of them point the finger at the use of flat ribbon cable vs "proper" GPIB shielded cables, and I agree, this is the very obvious suspect.
But my gut feeling is that this is not the problem.

@coromonadalix,
Using a separate interface for the M107 may end up being the solution, but I'd like to avoid that.
As to ground loops and control voltages on the pins, isn't this the exact same wiring (i.e. DC wise) as when proper cables are used?

A proper cable does have shielding, and uses twisted pairs. (at least my cable has alternating grounds for the  for the handshake signals)
Not that there aren't other considerations associated with shielding, but the only reasons I've seen in documentation by HP and others  for shielding is to reduce EMI, rather than to ensure proper operation.

And after all, I'm only looking at a bus length of 2 meters maximum, nowhere near the 20 meter max specified for GPIB, and with at most 5 devices on the bus, being well below the limit of 15.     

If the lack of shielding etc. was the cause of the problem, I'd expect to sometimes see more general "flakey" behavior, but this M107 reset issue is the only incorrect behavior I've observed. All other commands work correctly every time on all 3 devices.
The reset problem has never happened with DMM#2, but happens with DMM#1 every single time.

@Gribo,
I've tried using just the M107 and DMM#1, using only two cables of the shortest possible length (30cm), and also tested with the device positions on the cable swapped both ways - still always the same behavior.

I can't help thinking of DEC PDP-11 computers that allowed the Unibus to extend for 10+ feet, also using flat ribbon cable with alternating ground wires, and it still transferred data at megabytes per second. This was also an active-low, open collector, handshaking system. It did use special drivers and receivers, but standard TTL has been used without issues.

@Kean, The offer to let me try proper cables is most kind, and I may someday want to take you up on that. Are you in Melbourne by any chance?

My next approach might be to see if I can swap parts of the HPIB sections between the two HP3456A's, and see where that leads me.
 

[intabits]

I guess I was hoping for a "Yeah, I've seen that too, the problem was caused by xyz" type of response.

But if messing around inside the 3456A's yields nothing, I imagine that putting a logic analyzer on the bus should at least show the problem at the basic level (and hopefully the cause).
I was hoping to avoid getting into the nitty-gritty of the GPIBus transactions, but if that's what it takes, I'd better finish that LA project that I started a couple of years ago...

[intabits]

Swapping the A3 boards (containing the HPIB interface) should be simple, and it will be interesting to see if the problem shifts to the other meter.
I'm expecting that it will, and if so, my money is on a dodgy MC3448. I'll try the swap in a couple of days.

[Kean]

I am based in Sydney, although I was visiting Melbourne for work only recently.  I have a GPIB analyser somewhere, but it is only very basic and mostly manual.  I guess one of my vintage HP devices could also do some GPIB diagnostics.

I do agree with your observations, and was about to ask if the HPIB interface was removable and could be swapped between the units.  I agree is it most likely one of the MC3448 ICs.

[intabits]

Hmmm.

I moved the A3 board from DMM#2(working) to DMM#1(not working).
But it made no difference, the M107 still resets itself when I do a ++READ from DMM#1. All other functions over HPIB continued to work. (++READ also always worked too, just that it also reset the M107)

The only other part of the meter directly involved with HPIB is the A1 board on the back panel, that contains the HPIB connector and addressing DIP switches. So, just to be thorough, I also moved the A1 board from DMM#2 to DMM#1.

The A3 board is easy to swap, but the A1 is a bit more fiddly, requiring enough screws to be removed so that the back panel can be pulled back enough at one end to slip the 26way ribbon cable (that connects the 2 boards), clear of the box. (If HP can use such a cable, then so can I!)

Because the A1 PCB contains the DIP switches, the address of DMM#1 has now changed from 20 to 23.

I did ++ADDR 23 to select the meter, followed by ++READ to get the measurement. It worked! - No M107 reset!
I found this most curious, as there's so little on the A1 PCB to cause a problem. I couldn't believe it was at fault.

Wondering if there is something funny about address 20, I tried ++ADDR 20 and ++READ. It failed! - The M107 did a reset!
Maybe my earlier allowance for a M107 fault was correct? Is it responding inappropriately to HPIB activity?
So I tried selecting all the valid device address (1 to 30), followed by a read. Only Addr23 returned data of course, but interestingly, only Addr20 caused a reset. All others were simply ignored.

So maybe there is something weird about address 20 and the M107. But hopefully I can worry about that some other time, (or never) and for now, just change the address of DMM#1.

I've now put everything back as it was originally, and of course, the same initial problem appeared.
Then flipped 1 DIP switch on DMM#1 to change address from 20 to 22. Got some strange results until I bounced the power to all devices and the AR488, and now everything is sweet! I can read from both DMM's without upsetting the M107 (which still resets if I select Addr20 and Read). Maybe I'll look into that one day...

So instead of all that messing about, all I needed to do was flip 1 DIP switch!

Lesson learned: If HPIB devices seem to react when they shouldn't, check/play with addresses.