Can't get RQS to work

Question

I'm new to gpib programming and the various forum threads on this topic haven't helped me. If I understand correctly, If I have serial autopolling set then I can wait on RQS otherwise I can wait on SRQI. I've written a short test that prints ibsta, iberr, and ibcnt after each gpib command. Regardless of how I set IbaAUTOPOLL, ibsta after ibwait reports TIMO. I'd appreciate any hints on what I don't understand. This was done on very old Solar is 8 OS/Sun hardware using NI SBUS card and drivers; this code correctly reads a resistor from an Agilent dmm.
When enabled I see:
ibsta = 0x4100  < TIMO CMPL >
iberr = 0 EDVR <DOS Error>
ibcnt = 5
When disabled I see:
ibsta = 0x4128  < TIMO CMPL CIC TACS >
iberr = 768 <UNKNOWN>
ibcnt = 15319040
I've included the source of my test case(renamed dotc cause .c wouldnt attach) and both runs as attachements. I'd really appreciate any clue on what's wrong. (so stuck)
TIA
gary
Attachments:
sAUTO_enabled.log ‏3 KB
sAUTO_disabled.log ‏3 KB
solI3e_dotc ‏5 KB

Answer 1

RQS is one of those GPIB features that can bite hard.  So let me dig out a bit of a history lesson.
RQS as designed was a means to notify the controller in charge that an instrument was in need of attention but, more than that HP provided for a "Prioritization" of when to service service requests.  Service requsts a served in ascending address order.  If device at address 2 has an unserviced service request you cannot see a newer RQS on anything other than address 1 (assuming the CIC is address 0).   Many a year ago I learned the hard way when our lab's ovens raised RQS by default upon reaching the stable setpoint.  Our ovens were usually at address 4  blocking service reqests on our TEK scopes with a default address in the teens.  Not fun when your perfectly functioning code "Suddenly quits" from one iteration to the next.
You can usually avoid raising RQS.  It can be rather tricky as soon as more than 1 instrument is on the bus.
Jeff