EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: ornea on August 05, 2021, 01:50:13 am
-
Is it possible to set a GPIB HOST Master to become a GPIB HOST Slave and behave like an instrument.
Have been experiencing issues lately with GPIB instrument connectivity and after much investigation seems like faulty cables are the culprit.
Some of these cables are old and some have been used lots. Could not find any data on mating cycles. And we have many that are now suspect.
Have looked at connectors under a microscope and nothing conclusive.
So having been thinking of a way to do GPIB cable testing and recently considered HOST to HOST connectivity but I have been unable to connect one host to another in the Agilent Connection Expert. I can connect to INSTR like GPIB0::1::INSTR but not to HOST interface to HOST interface.
Ideally I would like to set up a send/receive script (perhaps in python) between two hosts that continuously hammers the connection.
Then simply test the cables by connecting the cable in question between HOSTs, run the script and flex and wiggle etc and see if the messages get mangled.
Would welcome any snippets of info or suggestions on an elegant way to test GPIB cables and connectors.
Cheers Ornea
-
The expected type of failure would be an open connection. A short would be rare. To test the connection it would be more like testing the resistance of the connections, possibly more in series and than more the cable a little. So it would take 2 connectors with bridges to make the current go though multiple of the wires in sereis. Ideally one could test from 1 end.
-
You can just use some GPIB device for that.
Find a GPIB command that the slave device can respond fairly quickly like the "ID?" and just spam the command quickly over and over, printing the results to a console. Then just look at the console output while giving the cable the rough handling.
Weird random glitches could also be caused by your cables being too long, or too many devices on it. The timings for GPIB are not all that strictly defined so various devices can talk at varying speeds, so it could be your problematic device is running the bus particularly fast.
-
Have decided to sacrifice once cable so can do the snake thing. That is:- probes on pin1 1 and 24 and cross connect the other pins.
Then do a standard resistance test and maybe send a tone in and monitor while wiggling connectors etc.
Yes, this has worked for years but over time became more un-reliable and was proving difficult to pinpoint and all the gear is old and potential suspects.
Changing a cable helped but whenever there are issues the cables are now suspect and there are many, So we just need a way to test them.
Thanks for the suggestions