GPIB communication issues between PC and device

[Minions · Accepted solution]

You can have two controllers tied together except that they both cannot be at the same GPIB address.  By default, the controller is given GPIB address 0.  The other choice is to configure the second controller as a listener prior to connecting it to the bus.

[JÞB]

---

@Minions wrote:

You can have two controllers tied together except that they both cannot be at the same GPIB address.  By default, the controller is given GPIB address 0.  The other choice is to configure the second controller as a listener prior to connecting it to the bus.

---

And, of course there can only be one CIC (Controller in charge) Both controllers would be defaulted as the CIC and therefore each would prevent the other from actually controlling the communications on the bus.

So, Go read up on GPIB Start with a Google search of IEEE-488 (Or read any Hewlett-Packard, Agilent or Keysight manual) then STOP just hooking things up wrong and expecting them to work right.

Next Read the Manual for your device. (Or at least tell us what it is and likely we will read the manual for you and even point out what you are doing wrong) 

 PEBKAC

[jonathan27]

Ok, so that is the reason. I get it now I need to set my listener to different primary address (PAD) correct?I'll try that one.

Thanks!

[jonathan27]

Thanks, yeah I've been reading the GPIB manual and been lurking on the forums. I'll try what minions suggested.

I don't have the device manual, and it is not something you can google. That is why I'm planning to hook a PC as a listener, with the communicating device.

I'm trying to contact vendor for the manual though,  this is a pretty old and bulky equipment 😄

Thanks!

[jonathan27]

Device already communicated, hooking another GPIB device in parallel helped it communicate with my PC.

(once it responded on my IDN query, everything went smooth)

Not sure why, though.

Thanks for your help guys!

[JÞB]

---

@jonathan27 wrote:

Device already communicated, hooking another GPIB device in parallel helped it communicate with my PC.

(once it responded on my IDN query, everything went smooth)

Not sure why, though.

Thanks for your help guys!

---

If addind another device to the bus fixed the communications the hardware drivers for the handshaking lines are under designed or faulty.

[jonathan27]

Hi Jeff,

Can you help elaborate? I can't just accept in my side that it just worked by doing that there has to be a logical explanation haha.

How can adding something in parallel fix a faulty driver?

Thanks!
Marcus

[AnalogKid2DigitalMan]

Did you piggyback the GPIB cable to the 2nd instrument on top of the existing cable at the 1st instrument?

Perhaps the cable to the 1st instrument had an intermittent connection? Try removing and reinstalling all cables to make sure they are seated properly and tightened.

Sea Story:

In one of our labs someone purchased several inferior coax cables. An engineer spent over a day trying to troubleshoot a circuit with an o'scope, he could not figure out why the signal of interest was not at full amplitude. Turns out the BNC's of the cables over time had developed a layer of oxidation preventing a good connection.I swapped out the cable out with a good one solved the issue, then immediate threw out all of the junk ones.

-AK2DM

[JÞB]

If the device meets IEEE 488 standard, no trouble!

If the device is poorly designed.... You need a compliant device to hold the handshake lines in an appropriate state.

Google your heart out.

[jonathan27]

Hi  AnalogKid2DigitalMan,

If piggyback means in parallel yes, I was thinking maybe we have some issue with the GPIB port itself of the primary (1st) instrument. And connecting the second instrument in parallel seem to fix it...somehow.

Thanks for the inputs! I'll put that one on my watchlist whenever I would have a problem in GPIB communication again.