I am running into a problem distinguishing serial polls that GPIB-USB is apparently initiating, from serial polls initiated from our windows application.
A little background first, I am developing an instrument utilizing the NAT9914 chip that will provide our GPIB interface. We are communicating to the instrument with a Windows application that utilizes the interrupt handler function to detect and service requests when the SRQ line is set. When the service request is detected, the windows application will do a serial poll (ibrsp) to get the status byte. The GPIB specification states that the RQS bit in the status byte should be cleared immediately by the instrument on reception of the serial poll.
Now, after my instrument sets the SRQ line to request service, it appears that the GPIB-USB is performing its own serial poll of the instrument prior to our windows application performing its serial poll. However, I need keep the the RQS bit "on" long enough for our application to see it, so I need to clear the RQS only after I see the serial poll that is received from the windows application.
The problem I'm running into is that I haven't been able to find a way on the instrument side to distinguish the serial poll I get from the windows application from any other serial poll (that is apparently initiated by the GPIB-USB).
I would like to find something already in the NAT9914 or GPIB that will accomplish this without having to resort to implementing special handshaking between the windows app and the instrument that would end up being a special non-standard addition to the GPIB communication.
Any help would be greatly appreciated.
Update:
Today, I began looking into the autopolling setting. After changing this setting on the GPIB-USB-HS for the first time, my instrument no longer gets two serial polls, one at the SRQ line enable and one at the first "ibrsp" that follows.
I get the first serial poll only:
1. at SRQ line enable, when autopolling is enabled
or
2. at the first "ibrsp", when autopolling is disabled.
I suspect that if autopolling has never been set one way or the other, autopolling "on" and "off" are somehow simultaneously active. Perhaps something in either the driver or the GPIP-USB-HS is not initialized properly until it gets its first autopoll setting command. I can't verify this, as this is a one-shot deal, and once initialized, it apparently is permanently working correctly.