Intermittent GPIB error 6 (EABO)

[Chris_Regan]

my system: Mac OS 8.6, Labview 5.1, NI-488.2 for Mac OS version 7.6.3, PCI-GPIB card, Keithley 2182 Nanovoltmeter and Keithley 24xx Sourcemeters.

I have a Labview application (modeled on Keithley's application note "Automatic Resistance Measurements on High Temperature Superconductors") which runs well with >99% reliability. The other times it hangs on a GPIB read with a EABO error. The Keithley instruments will complain "Query interrupted" or "Query unterminated". These problems seem to be more prevalent if the computer is distracted with mouse action or other applications, but it'll fail even without such challenges.

Since the application runs, I know my syntax is good. I've tried increasing the timeouts, but this does not pr
ovide immunity. Software delays help somewhat, but with an unacceptable duty cycle penalty. I suspected that I was getting spurious SRQ's for a while, but the GPIB reads that fail most frequently are not those preceded by Wait RQS.

All my GPIB functions are the old style (not 488.2). I'm not using VISA anywhere, since I've found the VISA functions to be even less reliable on my system.

Any suggestions?

[Ray K]

That is a strange problem. You may want to slow down the bus timing and check to make sure you are within the 488.2 cabling specs.
Ray K
NI Applications Engineer

[GP]

Chris,

I know this is an old problem but did you ever solve it? I just did a forum search and it found your message.

I have a similar GPIB EABO error that happens in a routine very occasionally (but stops my data logging).

Its really annoying as the vi runs fine for hours (reading data from various modules through RS232 and GPIB) and then I'll get a GPIB read error and the EABO dialog. The vi then hangs.

I'd be interested to know if you managed to solve this one. Or a way round it to carry on logging after the error has occurred.

Geoff

[Chris_Regan]

Hi Geoff,

I'm now running my application on a variety of different systems (PC, Mac, tower, laptop). On some of these the problem has never occurred, and on others it happens more than once an hour. In one case the frequency was egregiously high, but in that instance the problem was traced to an insufficiently tightened GPIB connector.

I've concluded that spurious signals sometimes get onto the bus, either through the cabling or inside one of the boxes. It's obviously a good idea to pay attention to your cable routing, but at some level this problem seems to be unavoidable (I'd love to learn that I'm wrong about this).

My solution has been to build traps in the software for the error. Ideally the timeouts are not too much longer than they
have to be to achieve normal function. When a spurious signal is received and the system hangs, it will timeout relatively quickly. My application notifies the operator with a pop-up window and then attempts to proceed as if everything was ok. Usually this works with no more ill effect than a gap in the data. In some instances I imagine that the instument (vs. the computer) might end up in a funny state that would require sending an extra command to nudge it along.

Hope this helps. Let me know if you learn anything more.

Chris

[GP]

Thanks Chris,

I've tried adapting my vi by cutting some timing delays
and also increasing timeout settings. I'm running it again to see if this cures the problem.

I've paid attention to checking the GPIB connectors and
also that there are no unwanted programs or processes running on the same computer before I start it running.

Hopefully, this might make it stable enough.

Can I ask how you went about getting the routine to try and keep running after error? I haven't attempted a work-round yet. If I got an error message in the middle of the night, the logging halted (as I wasn't around to click continue)! Some of the finer points to GPIB error handling look a bit esoteric to me. What approach did you use to keep it running?

Best Wishes


Geoff

[MT]

I'm also facing this strange problem.  Using a Keithly 182 voltmeter, I am receiving the EABO 6 error message after long periods of perfect functionality.  I have tried modifying the GPIB timeout to more than 10 seconds without any noticeable difference.  After the system produces this error, I am unable to rescue it.  The device reads the 'TALK' indicator on the front, indicating that it is communicating over the GPIB interface.  Normally this indicator turns on while triggering and reading the voltage then turns off. 

After the error condition is established, the Measurement & Automation program is unable to detect this device or any other on the GPIB interface.  The only method so far determined to return to a working mode is to completely turn off the voltmeter and turn it back on. 

I've tried the following commands to change the system back to a working order, without success.  The GPIB address of the device is 6.

sic
cac 0
cac 1
off 6
off
loc 6
gts 1
lstn - this command returns no devices.

None of these commands seems to change the system at all.  Any suggestions would be appreciated.

Thanks,
-Michael

edit:  NI Spy capture log posted at http://www.its.caltech.edu/~mike/Capture4.spy .  Problems begin around message 118800.

Message Edited by MT on 07-13-2005 02:36 PM

[ScottieB]

One curious thing I notice on your spy capture is that your IBWRTA() is the one that times out eventually, but your instrument says "TALK", which usually means that it is still responding to an IBRDA() where it would be sending data to the GPIB.  The Keithley 182 may not have this, but most instruments have both a "talk" and a "listen" state.  The "talk" state would indicate that it was not being re-addressed as a listener for the ibwrta().  This is one of the first things that the ibwrta() command should do; it should address the instrument as a listener so that the controller can then write data to a listening instrument.  Does Keithley have anything to say about this issue?  It sounds like the instrument is "dropping the ball".  Do you have a GPIB analyzer card like the PCI-GPIB+ board that you could attach to the bus and get an analyzer capture of this behavior?

Also, could you post what version of LabVIEW and what version of NI-488.2 you're using, as well as your OS?

Thanks,

Scott B.

GPIB SW

National Instruments

[JLS]

Hello,

I realize I getting into this stream after some correspondence, and that you are asking another poster a question.  But, if you are simply trying to get your LabVIEW program not to stop and indicate an error, rather continue and discard it, all you have to do is monitor the error cluster, for example, by wiring it to an error cluster selector input, and then in the error case, simply pass out a fresh, new error cluster constant with status = false (no error), code = 0, and an empty source string.  The easiest way to do this is to first wire through the no error case to create a tunnel at the output, and then right click to create a constant in the error case.  Attached is a screenshot showing both the the error case and no error cases in a quick example.

I hope this helps!  Repost if you are having any further or continued problems!

Best Regards,

Jassem

[JLS]

I realize I am... missed a word in the previous post 😉

Best Regards,

JLS

[MT]

Thanks Scott,

I'm using Windows XP SP2, LabVIEW 5.1, NI 488.2 version 2.20.  We do not have a GPIB+ analyzer board available.

The Keithley 182 does have both a "talk" and "listen" state.  By stepping into the KE182read vi, the state is the following:
[Initialize the instrument]
(LSTN=ON, TALK=OFF)
GPIBWRITE {addressstring="6",data="H0X", mode=3}
(LSTN=ON, TALK=OFF)
GPIBREAD {addressstring="6", bytecount=25, mode=0}
(LSTN=OFF, TALK=ON) --> reads data off GPIB
GPIBWRITE {addressstring="6",data="H0X", mode=3}
(LSTN=ON, TALK=OFF)

This is the sequence during the correct readings.  I haven't been completely able to tell how this changes during the erroneous communications.

I've also tried the following things:
Modify the KE182 to assert SQR when it is ready for a trigger to read the device.  In LabVIEW wait for this RQS to assert the manual trigger command to read off the KE182.  In this setup, the previous problems still occur - it is able to read several thousand readings, then fails in the TALK state on the KE182. 

Also noteworthy is that this problem seems to occur most frequently when there is a load on the CPU, but it also occurs without any load at all.
Thanks
-Michael