Error 15 Occurred at Wait for GPIB RQS

[JÞB]

---

billko wrote:

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

---

Bill-

At the risk of getting off topic---- Appologies to the others!

Essentially the VISA issue with 7.0 boils down to the handeling of the controler specific properties contained in the VISA resource.  The controller is in charge of deciding weather or not to autopoll, send Termination character on EOI, selecting the termination character and several other things that are part of the VISA GPIB inst class.  Not a problem if there is 1 controller and 1 instrument and you've set up the properties in the device initialization.  Huge problem if you have two instruments (And two VISA sessions) that have different requirements for the controller specific properties. 

Imagine if you will, you write the VISA property Term Char enable in two device init routines and those values remain, and are different, in each VISA session wire.  However, the controller was given ONLY two commands so IT is in the last state set.  The Hardware no longer matches the properties in the first VISA session.  The work around was to use straight 488 commands to have access to the "mode" so that the controller properties were set on each read or write. 

Sorry to rant.

[billko]

---

Jeff Bohrer wrote:

---

billko wrote:

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

---

Bill-

At the risk of getting off topic---- Appologies to the others!

Essentially the VISA issue with 7.0 boils down to the handeling of the controler specific properties contained in the VISA resource.  The controller is in charge of deciding weather or not to autopoll, send Termination character on EOI, selecting the termination character and several other things that are part of the VISA GPIB inst class.  Not a problem if there is 1 controller and 1 instrument and you've set up the properties in the device initialization.  Huge problem if you have two instruments (And two VISA sessions) that have different requirements for the controller specific properties. 

Imagine if you will, you write the VISA property Term Char enable in two device init routines and those values remain, and are different, in each VISA session wire.  However, the controller was given ONLY two commands so IT is in the last state set.  The Hardware no longer matches the properties in the first VISA session.  The work around was to use straight 488 commands to have access to the "mode" so that the controller properties were set on each read or write. 

Sorry to rant.

---

Rant???  No way is what you said a rant!  In a later post I believe I acknowledged the shortcomings of VISA in LV 7.0, which was a learning experience for me.  I did acknowledge that in an earlier post, but I still don't think of your post as a rant.  It's all good learning for me.  🙂

Bill

Edit:

It did sound like the teaser from the opening of a "Twilight Zone" episode, though: "Imagine if you will..." 😄

Message Edited by billko on 10-01-2009 10:25 AM

[Crusher]

---

Jeff Bohrer wrote:

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.

---

Please tell me if I am understanding this correctly:

When autopolling is enabled, the GPIB controller card will automatically serial poll whenever the RQS is asserted.  The serial poll results are stored in a buffer wher they wait for a block such as "Wait for GPIB RQS" to retrieve them.  If the "Wait for GPIB RQS" is not executed at least as frequent as the frequency of the RQS line is asserted, then the autopoll will overflow the serial poll buffer.

[Crusher]

BTW I'm itching to try some of these suggestions out but right now another engineer is running a fatigue test on the instron.

The last time I tried messing with Labview while he was running a test, the Instron went haywire, his test specimen fell off the machine and landed on the instron controller, and then the controller went non-responsive.  So my judgement tells me that I should wait for it to complete before I start messing with labview.

His test is at 1.5 million cycles and has to go to 3 million.  So at 3 Hz his test wont complete until Wednesday.  Of couse there's always premature failure, knock on wood.

[billko]

---

Crusher wrote:

BTW I'm itching to try some of these suggestions out but right now another engineer is running a fatigue test on the instron.

The last time I tried messing with Labview while he was running a test, the Instron went haywire, his test specimen fell off the machine and landed on the instron controller, and then the controller went non-responsive.  So my judgement tells me that I should wait for it to complete before I start messing with labview.

His test is at 1.5 million cycles and has to go to 3 million.  So at 3 Hz his test wont complete until Wednesday.  Of couse there's always premature failure, knock on wood.

---

Jus t "accidentally" run your LV app again.  😄

[Crusher]

---

billko wrote:

---

Crusher wrote:

BTW I'm itching to try some of these suggestions out but right now another engineer is running a fatigue test on the instron.

The last time I tried messing with Labview while he was running a test, the Instron went haywire, his test specimen fell off the machine and landed on the instron controller, and then the controller went non-responsive.  So my judgement tells me that I should wait for it to complete before I start messing with labview.

His test is at 1.5 million cycles and has to go to 3 million.  So at 3 Hz his test wont complete until Wednesday.  Of couse there's always premature failure, knock on wood.

---

Jus t "accidentally" run your LV app again.  😄

---

I think if I did that the sample might just "accidentally" fall on my head this time.  🙂

[JÞB]

"It did sound like the teaser from the opening of a "Twilight Zone" episode, though: "Imagine if you will..." "

Nice spot on the subtle referance

While I was experiencing the effects I kept thinking to myself "Is Rod Sperling about to shake my hand?" But, it made me a better programmer! 

[JÞB]

---

Crusher wrote:

BTW I'm itching to try some of these suggestions out but right now another engineer is running a fatigue test on the instron.

The last time I tried messing with Labview while he was running a test, the Instron went haywire, his test specimen fell off the machine and landed on the instron controller, and then the controller went non-responsive.  So my judgement tells me that I should wait for it to complete before I start messing with labview.

---

Probably a wise judgment.  a further caution:  If your app needs specific MAX configuration settings save your MAX configuration! and document the settings you need in your VI info.   Remember someone else's app may be depending on the current MAX settings.  You gotta play nice with others too!

[M.P.Singh]

can u give me the steps how to use labview in fatigue test. i am conducting fatigue test on constant bending stress machine where the specimen will be rotating at 4200 rpm .how to acquire the signal from a rotating specimen.

[Crusher]

M. P. Singh

The machine I was using is a linear hydraulic machine and has nothing in common with a rotating bending (R.R. Moore) machine.  It seems that your question has nothing to do with this thread.  I recommend that you start a new thread.  I also recommend that you provide much more information in your new thread such as a complete description of your hardware.

Good luck.

-Daniel