GPIB lock up

[TLE]

Hello,
 
I am troubleshooting a problem with a test system.  There are three "identical" systems all running LabVIEW 7.1.1 on Windows XP with a VXI data acquisition system.  All three systems have been running for 10 years with minimal changes.  Recently, one of the systems has been experiencing "lock ups."  I have determined that part of the code is hanging up, probably the GPIB communications.  The test system communicates with a couple of JCS Systems PID controllers over GPIB.  It is suspected that one of the controllers could be failing.
 
I have limited experience with the GPIB primitives.  Has anyone seen a VI get stuck in one of the GPIB primitives if there is a GPIB communications problem, even if the timeout is set to a number greater than 0 (like 3000)?  Is it possible for LabVIEW to ignore a timeout?  The code is using GPIB Read, GPIB Write, and GPIB Misc.  Only the GPIB Misc. does not have a timeout input to it.  Does it use the default 488.2 timeout of 10 seconds?
 
Any troubleshooting suggestions?  The problem is difficult to reproduce and seems to happen at random.
 
Thanks for your help!
 
Tim

[Albert.Geven]

Hi Tim

Did you swap the hardware as prposed in LVinfo? And did loosening and reconnecting the gpib connectors help?

It sometimes happen, hardware gets killed.

[TLE]

Hi Albert,

We cleaned the GPIB connectors and re-tightened.  I have not swapped any hardware yet.  We are currently trying to get another UUT.  I also plan to run the system in development mode so that I have more troubleshooting tools.  Unfortunately, the problem does not show up every test and each test takes two hours.

Thanks for you suggestions, I will let you know.

[Albert.Geven]

good luck

[JÞB]

Any troubleshooting suggestions?  The problem is difficult to reproduce and seems to happen at random

Not a fun situation and my condolences!

TS suggestions:

Intermittant failures can be a royal pain (set sea story = True)  on board my second ship we observed that most evenings (3 out of 4) just after dinner the VSWR alarm would go off on the Radar system.  A reset from the console ALWAYS restored the system.  This went on for WEEKS until just after dinner one night I happened to walk through officers county and found <wait for it....>  Ensign Bright-n-Young doing his 10 nightly chin-ups while hanging on the radars waveguide!  1 night out of 4 he was on watch and skipped his evening calisthenics!

The point:

look at everything that did change- did a maintenance release happen, a driver update, a new janitor/operator/IT guy/ new web site been accessed from the unit?

Then suspect aging components- Stress test the GPIB bus with a high load of traffic- remove the equipment and cables 1 at a time to see if a specific GPIB handshaking line driver is not pulling its weight.  Measure the cable lengths: did someone replace a couple short ones with longer ones and violate the max cable length spec?  Not fun at all- and it may take some time.  keep us posted!