| Products > Test Equipment |
| AR488 problem: reading from one device causes reset in another |
| (1/2) > >> |
| 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: ---** 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 ** --- End code --- 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. |
| Navigation |
| Message Index |
| Next page |