Keithley 238 GPIB Communication

[Ray00]

I am using LabView 6.1 and writing an application that communicates to this instrument (among others) via GPIB. My communication to the Keithley is usually okay for a while in the beginning, but after the program has ran for about 5-10 minutes, it loses communication with it. The Keithley drivers I am using just timeout and it looks like there is not really a specific error code except for ERR(0). Has anyone had issues communicating with this or a similar instrument, and how was it resolved?

I did see someone post that it may be a good idea to modify the Keithley drivers to use VISA instead of the older GPIB communication vi's.

Any help would be greatly appreciated.

Thanks in advance.

Rey

[A.S.]

Rey,
It seems like you may be getting EDVR(0) error since 0 is its error code. If that is the case, check out this link: http://digital.ni.com/public.nsf/websearch/2FA525A8585A92E9862566EE002A3755#EDVR and see if it helps any.

What kind of communication are you conducting? Is it something that could perhaps build up data to the point that the device become inaccessible? You should try to replicate the problem at as small a scale as possible. This will help you isolate the problem. Try sending a simple *IDN? to it or getting a single point reading or something similar repeatedly for 5-10 minutes.
It is recommended to use VISA drivers since they are better integrated. Also, without an error code, it is hard to determine the problem. Have you used the Keithley
238 Device Errors VI that is included in the device drivers? This VI will interpret any Keithley error codes. You can also try to wire the error clusters that are generated from the GPIB Read and Write VIs. These will give you the LabVIEW errors.

Any additional information will be helpful.

A.S.

[Ray00]

A.S. Thank you for your reply. I used the Keithley 238 Device Errors VI to try and get more info., but it still returned the same thing. I had looked at EDVR(0), but I couldn't find any place where the name could have been changed. Although, I am using an Event loop, so I will double check and make sure this does not reset a value that I set somewhere else.

Here is an interesting thing that I did. There is a part in my program where I am just reading a measurement from the Keithley 238 on a continual basis, and this where it seemed to usually crash after a few minutes. So I opened up the Keithley VIs (namely the Read Measurement one) and ran it in LabView debug mode (slow motion). The funny thing was that when I did this, I had no problem. It ran fo
r 45 minutes in this mode and never failed. I noticed in the Read Measurement VI that they do some writes/reads and even poll the intstrument once or twice in a while loop. So what I did was added some delays in a couple of different places of about 500ms. I also slowed down the polling in the while loops to like 250ms. Once I did this the program, so far, seems to work. I know all the delays (and the times) might be overkill, but it looks like it may be a step in the right direction. We are not looking for super fast response times, so if this did indeed fix the problem, it should be okay. So far for the last couple of days it seems to have worked. I will continue to monitor it, to see if it ever fails even with the delays.

Does any of this seem to make sense? The thing that I don't understand is that I am sure there are people that must have used these VIs from Keithley without any issues, so it seems weird that they would behave differently on my machine, as far as tim
ing. It is not a fast machine by todays standards (PXI 1000B, I think ~1GHz).

Thanks for you input,
Rey

[A.S.]

Rey,
It seems like you found the problem. It could very well need delays. If are reading immediately after writing to the instrument, you usually want some sort of delay in between to allow the instrument to respond. 500ms is overkill, but something smaller like 50ms may be more practical. You will have to try different values yourself. But the delay between the writes and reads or loop delay needs to be big enough to allow the bus lines to settle and the instrument to respond.

A.S.

[jfong]

Replying to an old thread, but here is a solution I found:

The hang-up seems to only occur when "Keith 238 Read Measurement.vi" is called, and always between the two case structures of the first sequence (see the attached file)

I added a 50ms time delay, and haven't seen a problem for a good period of time.