keithley smu hangs during communication over GPIB

[crock]

We've been experiencing problems with Keithley 237 and 238 smu's locking up when running an automated test.  We never had any of these problems until we upgraded our labview to 8.6 from 7.2. 

Now, within a few seconds of starting the test, one of our smu's will hang with the listen (LSTN) light active. Trying to stop the test does nothing.  I have to kill the labview process or power down and then power up the smu.  The GPIB Write block is still executing when the hang occurs.

We were running the 2.7.1 version of the NI 488.2 drivers but I saw in the release notes for 2.7.3 that one issue fixed was

Possible Failure on ibln() and FindLstn()
182620: PCI type GPIB interfaces (PCI, PCIe, PMC, PXI) were not waiting the recommended time of 1.5 ms for instruments to respond to ibln() and FindLstn() calls. This typically would affect only older instruments with significantly slow response time and does not affect most recent instruments. This has been fixed

So we upgraded to 2.7.3 and saw no change.  We even changed the timing parameters for our GPIB device to 2 us with no effect.  The only way we have been able to keep our test running for more than a few seconds is to open and run NI SPY while our test is running.  With NI SPY open we can run the test for many hours but the lock up still occurs.

Any ideas what to do next?  I don't think this is a problem with SMU's since they worked fine with Labview 7.2 and almost work as expected with NI SPY running.

[pflores]

crock,

I have a couple of suggestions:

- check for firmware updates to your keithley devices.

- confirm the settings (especially termination) for the GPIB devices in MAX, it is possible that these were chaned when upgrading your software.

questions:

- does the same behavior happen to both devices?

- does the "locking up" behavior happen at the same command every time?

- try using the GPIB example programs found under Help>>Find Examples...>>Hardware Input and Output>>GPIB

- can your run this same program on another computer?

- can you post your code?

- can you post the NI-SPY capture, and indicate where the devices freeze?

[Albert.Geven]

Si it looks like a timing issue. PC's and even some software is getting faster.

Maybe you should also disable autopolling. It is not sure that it helps but is also an attempt to react faster on machines.

An extreem solution would be to send characters one by one but then you need to change the low level layer and be sore that end or identfy is not sent.

Good luck