Error 15 Occurred at Wait for GPIB RQS

[billko]

In my experience, VISA was always easier to use because it automated a lot of what you had to do manually with straight GPIB.  The reason is that VISA talks to the instrument driver so you can concentrate on what commands to send, rather than how to send it.  You should then not have to worry about line assertions and all that.

Bill

[JÞB]

Knowledge Base

Crusher,

I'e attached a link to the knowledge base artical that describes how these errors can be worked around.  Additionally I would recommend looking at the termination mode of your reads and writes.  You are using the default mode (0) but the instrument may be expecting a termination character.  You'll need to read the instruments manual to determine the best mode.  

As to using VISA-  If you were working in LabVIEW 7.1 or later I would strongly recommend using VISA.  As you are using 7.0 I would caution against using VISA for GPIB.  I remember several unexpected behaviors with the 7.0 implementation of VISA functions to GPIB instruments especially when non-488.2 compliant instruments were on the bus.  That Instron 8511 is not 488.2 compliant!

Definately, take a look at the instrument's status byte when the error occurs.  I think this will point towards a possible causes  such as: a flakey GPIB cable (or too much cable) or a shakey GPIB card that is loosing its ability to sink a handshaking line, or possibly the intrument is being put in LOCAL.  (I appologize for the bad pun earlier Local = Lo-cal = "diet mode"  as in - Nope, the test sytem isn't broke, It just went on a diet!)

[billko]

---

Jeff Bohrer wrote:

Knowledge Base

Crusher,

I'e attached a link to the knowledge base artical that describes how these errors can be worked around.  Additionally I would recommend looking at the termination mode of your reads and writes.  You are using the default mode (0) but the instrument may be expecting a termination character.  You'll need to read the instruments manual to determine the best mode.  

As to using VISA-  If you were working in LabVIEW 7.1 or later I would strongly recommend using VISA.  As you are using 7.0 I would caution against using VISA for GPIB.  I remember several unexpected behaviors with the 7.0 implementation of VISA functions to GPIB instruments especially when non-488.2 compliant instruments were on the bus.  That Instron 8511 is not 488.2 compliant!

Definately, take a look at the instrument's status byte when the error occurs.  I think this will point towards a possible causes  such as: a flakey GPIB cable (or too much cable) or a shakey GPIB card that is loosing its ability to sink a handshaking line, or possibly the intrument is being put in LOCAL.  (I appologize for the bad pun earlier Local = Lo-cal = "diet mode"  as in - Nope, the test sytem isn't broke, It just went on a diet!)

---

Jeff:

I'm learning so much here!  I didn't know that tidbit about LV 7.0.  Kudos!

[Crusher]

---

Jeff Bohrer wrote:

Knowledge Base

Crusher,

I'e attached a link to the knowledge base artical that describes how these errors can be worked around.  Additionally I would recommend looking at the termination mode of your reads and writes.  You are using the default mode (0) but the instrument may be expecting a termination character.  You'll need to read the instruments manual to determine the best mode.  

As to using VISA-  If you were working in LabVIEW 7.1 or later I would strongly recommend using VISA.  As you are using 7.0 I would caution against using VISA for GPIB.  I remember several unexpected behaviors with the 7.0 implementation of VISA functions to GPIB instruments especially when non-488.2 compliant instruments were on the bus.  That Instron 8511 is not 488.2 compliant!

Definately, take a look at the instrument's status byte when the error occurs.  I think this will point towards a possible causes  such as: a flakey GPIB cable (or too much cable) or a shakey GPIB card that is loosing its ability to sink a handshaking line, or possibly the intrument is being put in LOCAL.  (I appologize for the bad pun earlier Local = Lo-cal = "diet mode"  as in - Nope, the test sytem isn't broke, It just went on a diet!)

---

Thanks for the link!  That is definately helpful.  Here is a quote from the Knowledge Base:

"ESTB is reported only by the ibrsp function. ESTB indicates that one or more serial poll status bytes received from automatic serial polls have been discarded due to lack of storage space."

What is autopoll?  When I look up the "Wait for GPIB RQS" block Labview help doesn't mention anything about autopoll.  When I look up autopoll I also do not get any results.

Here is a quote from the Instron Interface Manual:

"The terminator element for a Program Message may be iether an SR2, which is the LF=0A Hex character, permitted when sending an all-ASCII command string; or an SR3, which is the END Message (GPIB EOI asserted with the last data byte), which must be used if the command string contains any binary data."

I always assumed that Labview automatically asserted the EOI when sending messages.  Is this true?

Yes it is true that the 8511 is not 488.2 compliant.

I will definitely look at the status byte when I get a chance.

I have never heard of this "LOCAL" you keep mentioning.  Can you please explain?

[billko]

The "Local" (sometimes abbreviated "LCL") button provides a non-programmatical way to return control to the instrument's front panel.  Most (all?) programmable test instruments disable the front panel when being used in program mode.

Bill

[Crusher]

Thanks Bill!

Ahh yes of course.  The instron does have local/remote modes.  In fact the C909,1 in the begining puts it into remote mode and the C909,0 puts it into local mode.  However I am not sure this is the the problem because the Instron manual states that query messages may be sent in local mode.

[billko]

---

Crusher wrote:

Thanks Bill!

Ahh yes of course.  The instron does have local/remote modes.  In fact the C909,1 in the begining puts it into remote mode and the C909,0 puts it into local mode.  However I am not sure this is the the problem because the Instron manual states that query messages may be sent in local mode.

---

Sorry, Crusher:

I was addressing only that small part of the post.  I'm still not sure why measurements are backing up in the queue until there's a buffer overflow.  😞

[Dennis_Knutson]

---

Crusher wrote:

.....

I always assumed that Labview automatically asserted the EOI when sending messages.  Is this true?

---

You determine whether to send EOI or not when you use the Write function. EOI is sent by the GPIB driver and when you select mode 0 (the default) for a GPIB Write, that is all that you are sending. Look at the help for the function. You can select different modes. For example, if you use mode 2, you will send a LF along with EOI.

[Crusher]

Thanks Dennis.

I forgot about the mode node.

[JÞB]

---

Crusher wrote: 

Thanks for the link!  That is definately helpful.  Here is a quote from the Knowledge Base:

"ESTB is reported only by the ibrsp function. ESTB indicates that one or more serial poll status bytes received from automatic serial polls have been discarded due to lack of storage space."

What is autopoll?  Hard to find but--- You can change the feature VIA MAX Source: NI 488.2 help>App Development>Advanced techniques>Serial Polling>Automatic serial polling overviewAutomatic Serial Polling Overview

Automatic Serial Polling Overview

If you want your application to conduct a serial poll automatically when the SRQ line is asserted, you can enable automatic serial polling. You can use automatic serial polling with traditional device-level calls only. The autopolling procedure occurs as follows:

1. Autopolling is enabled by default. However, if you want to disable autopolling, use the configuration function, ibconfig, with the IbcAUTOPOLL option, or Measurement & Automation Explorer.
2. When the SRQ line is asserted, the driver automatically serial polls the open devices.
3. Each positive serial poll response (bit 6 or hex 40 is set) is stored in a queue associated with the device that sent it. The RQS bit of the device status word, Ibsta, is set.
4. The polling continues until SRQ is unasserted or an error condition is detected.
5. To empty the queue, use the ibrsp function. ibrsp returns the first queued response. Other responses are read in first-in-first-out (FIFO) fashion. If the RQS bit of the status word is not set when ibrsp is called, a serial poll is conducted and returns the response received. You should empty the queue as soon as an automatic serial poll occurs.
6. If the RQS bit of the status word is still set after ibrsp is called, the response byte queue contains at least one more response byte. If this happens, you should continue to call ibrsp until RQS is cleared.

Here is a quote from the Instron Interface Manual:

"The terminator element for a Program Message may be iether an SR2, which is the LF=0A Hex character, permitted when sending an all-ASCII command string; or an SR3, which is the END Message (GPIB EOI asserted with the last data byte), which must be used if the command string contains any binary data."

I always assumed that Labview automatically asserted the EOI when sending messages.  Is this true?

Again this depends on the config of the controller.  With VISA this is a property for GPIB which sometimes is overwritten by MAX in LV7.0 (one of the unexpected operations I cautioned about )

With straight 488 commands you must append the LF (0x0A) to each string.

Yes it is true that the 8511 is not 488.2 compliant.

I will definitely look at the status byte when I get a chance.

I have never heard of this "LOCAL" you keep mentioning.  Can you please explain?  

A lot of old devices will still respond to queries if they are in local (vs Remote) but the instrument isn't necessarilly expecting to announce its status via the remote connection.  So having the device in local mode makes its remote connection unreliable.  Place the device in remote and leave it in that mode if you want reliable remote access.

---

Are we having fun yet?