Why is the RQS bit ONLY being set in the STB register?

[MikiLV]

I am writing a LabVIEW driver for our instrument and I have coded an application example. The application runs reliably on a number of PCs using PCI-GPIB cards.  This problem only occurs when using the NI GPIB-USB HS card I have just purchased. There is only one device attached to the GPIB bus. 

In my application I use Service Request events to set or query instrument settings. I have been able to capture events leading to the fault using the NI-Spy utility and I have discovered that the contents of the Status Register following a Service Request causes my application to fail.

The problem seems to occur when I Query instrument settings. I set up the Status Registers to raise a Service Request when data becomes available in the instrument's output queue, i.e. to raise an SRQ when the 'MAV' bit is set (*CLS;*ESE 57;*SRE 48; query command?)

When I get a Service Request, the contents of the Status Byte returned by the Wait for RQS.vi, report only the RQS bit being set (64 decimal), when I expected the RQS bit and the MAV bit to be set (80 decimal). My application will check for the MAV bit to be set before attempting to retrieve data from the output queue. If the MAV bit isn't set, data pending in the output queue will NOT be fetched, causing the application to fail when further queries are performed.

Does the ieee 488.2 standard allow for these 'false' SRQs? In other words, Is it permissible to receive a Service Request with ONLY the RQS bit set in the Status Byte?

Please find attached an NI spy highlighting the problem.

[K_Bull]

Hi MikiLV,
Can I ask what NI-488.2 driver version you have?
By using the GPIB Misc function, it is possible to set any status bit of the 488.2 by using the rsv command. The address 0x40 ( ASCII @ ) corresponds to the Service Request. For more detail, click here. Other then that, there are labview functions, TestSRQ and WaitSRQ, which as I understand, are not helpful for you.
Best Regards,

[Andy L]

Hi MikiLV,

It seems that you are expecting both of the bits to be set in the returned status byte.  When you call viReadSTB it returns the status byte of the instrument.  Are you expecting both an event to have occurred as well as a message be available?  If an event happens OR MAV is set, the instrument will SRQ.  If you are only interested in one of these status changes (MAV) you might try disabling all other bits in the status register or try using *SRE 32 ?

Have you tried the GPIB-USB HS on different computers?  Also are you using a computer that has USB 1.0 or 2.0 ports?  USB 1.0 has much longer latency and might be causing response issues.  I have attached graph showing much slower in latency USB 1.0 is below . Something else you might try is inserting waits in the program so the instrument has more time to respond. 

Regards,

[MikiLV]

Hi Andy L,

Thank you for your reply.  The reason why I send *SRE 48, is because I would like an SRQ event to notify that a message is available (MAV bit and RQS bits set). I also need to be notified, via the ESB bit,  if an instrument error has occurred while attempting to make measurements (this can be an EXE, CMD, DDE error). In the event of an error, I will not attempt to fetch measurements from the output queue, but will perform an Error Query instead.

What seems to be happening, as I mentioned in my earlier posts, is that neither the MAV bit nor the ESB bit are set when I receive a Service Request event, but only the RQS bit is set.  I am trying to establish whether this 'false' Service Request condition is at all permitted by the GPIB specification, but more importantly whether the GPIB driver on our instrument may have a problem.

The computer I am using is a 2GHz P4 with Windows 2000 service pack 4.  I have verified that all USB ports are USB 2.0 compliant.  I am a little confused by the latency issue. Since USB 2.0 appears to have a worse latency than a PCI-GPIB card, I would have thought this should give the instrument more time to respond 'correctly'.

At the moment I have modified the driver to discard these 'false' Service Request events, and wait for the 'wanted' event. I am testing this solution as we speak and will be testing the GPIB-USB HS card on different Computers.  Although in my view it is good practice to implement safer coding, it does not get to the bottom of the issue and this is what I am trying to do at the moment.

Thanks again for you help.

Michele

[Andy L]

Hi Michele,

The GPIB controller will only listen for the Service Request (SRQ) and then serial poll all devices with open handles.  That is where the serial poll status byte will come from.  When the instrument requests service for any of the bits that have a 1 instead of a 0, there is no way to get the instrument to only request service when all bits are set.  If any of the bits cause the Service Request (SRQ) line to go high then we will stop reading.  The issue with the USB controller could be due to the USB lower latency; the bits might be getting read too soon and we are not reading the MAV bit.  I would suggest trying a slight wait between the read. 

Regards,