Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Can't get RQS to work

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

Download All
0 Kudos
Message 1 of 3
(4,460 Views)

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.


"Should be" isn't "Is" -Jay
Message 2 of 3
(4,447 Views)

Jeff thanks for answering. Are you saying you can tell that is the issue from the logs or code I attached or it is something I need to watch for? In trying to eliminate the later, the dmm is the only device connected and I rebooted the machine. I'm hoping it wouldn't persistent across a reboot. Prior to running my test case, ibic->ibfind gpib0->iblines reports that SRQ == 0, ibsta still reports TIMO on the ibwait regardless if I'm checking RQS or SRQI. I would suspect the meter except I've tried it on a couple of them (HP34401As).

 

TIA

gary

0 Kudos
Message 3 of 3
(4,428 Views)