Trouble with comms to R&K 680A prober over IEEE488

[valbrite]

"Using LABVIEW 6i, and a NI 488.2 PCI card installed in a high end Dell computer, my R&K 680A probe station responds to some commands (home, load) but I cannot position it or properly read position. I believe it has something to do with the device being older and not 488.2 compliant. I get timeout errors when I try to communicate with the device using iMAX. A simple command like "home" (sends an ASCII "H") execute with no errors. Anybody have ideas?
All the hardware checks out. The prober uses a 68488 chip for IEEE 488 interfacing."

[Ryan_M]

Are you able to establish communication using IBIC (ibic.exe)? The interactive control utility is the lowest level of interface to the GPIB contoller independent of any software programming environment. If you have difficulty getting IBIC to work then things you may have to verify are bus timing, termination, and command strings. Slowing down the handshaking process, many times, helps the controller communicate with older instruments. You can tweak this option from your GPIB configuration utility (Device Manager or ibconf or Control Panels)

[kiver]

I recently developed some prober software for a Ultracision 680e prober using LV 5.1 and have experienced GPIB read time outs (error code 6) which would happen at intermittent intervals which makes the root cause of the problem even more difficult to nail down.
From what I understand the 680e does have a different command set than the 680a but perhaps the hardware is "bug for bug compatible". You mentioned that you have a high end Dell computer but you did not indicate which OS you were using but I am betting that it is Win 2000!
I suspect that this problem is either system speed or Win 2000 related, I experienced this problem as recently as last week when I switched from a 450mHz IBM box with Win 98 to a 800Mhz clone with Win 2000 installed on it. I first loaded the NI 1.70
GPIB software with no success then I switched the OS back to Win 98 and the occurrence of this problem was drastically reduced but was not entirely eliminated. I added a delay of 50ms between the GPIB write and the GPIB read functions and I have been running for 2 days now without a bus hang. The 50ms was arbitrarily chosen and other values may or may not work as well. Also, please bear in mind that while this "fix" seems to have worked for me it may be something that will not work for you as the 680a and 680e are different. I still consider this fix as a "Band-Aid" until I can get to the root of the problem. I will be going back to Win 2000 and trying this experiment again, if I am successful I will be looking for a more elegant way around this problem.
I hope this has helped and if you happen to find a better fix for this before I do or if this has helped you out please let me know!

[gandhiss]

I have been working with gpib interface with an automated prober(680e). I had a program in Matlab for interfacing with the prober and a LCR meter. The program used to work properly. Now after two weeks when I try to run it again I get the EHDL 23 error in NI spy when the prober is accessed. I do not get any error when I connect to other devices. The prober is an older model

and is not 488.2 complaint. I have checked the document which explains about the gpib errors and I have used ibic to check for the board and device address. They appear to be fine. Do you have any suggestions to debug this issue.

[gandhiss]

Just wanted to add that there is no change in the PC configuration between the time when I was able to access the prober and when I am not able to

[Meghan R]

Hello gandhiss,

Error code 23 relates to the device handle being invalid.  Have you double checked your device name in Measurement & Automation Explorer to make sure you are using the correct name?  You said you checked the KB 3CO9NH3F: GPIB Error Codes and Common Solutions (Part 3)  but you didn't say if you tried the solutions?  What was the outcome?  From that KB: 

EHDL(23)
Error Condition: Input Handle is invalid.
Possible Cause: Several GPIB commands take in the input handle of the board or the device as an input parameter which can be the source of this error. This error can occur under several circumstances. Some scenarios are listed below:

• A valid board handle is passed in as a device handle parameter or vice versa
• An invalid board or device descriptor is passed as input to any NI-488.2 function
• A board id outside the range of 0-99 is passed in to a traditional NI-488.2 board-level function or NI-488.2 routine
• ibconfig or ibmask is called with a device unit descriptor and a board-only configuration option, or with a board unit descriptor and a device-only configuration option

Solutions:

• Check to see if the device-level and board-level functions are not mixed up when calling the respective functions
• Also check if the board index passed to the NI 488.2 call is a valid index number

Thanks,

Meghan