GPIB SRQ causes data loss?

[Anonymous]

We hired a guy to write a GPIB driver for a new instrument. For the
most part it works fine but sometimes the host times out on the
device. Since the guy who wrote this code seems to be absent from the
planet I've been forced to try to fix it myself.

After some research it seems that the host times out due to a lost
byte of data. The data byte appears to get lost when SRQ is asserted
by the device during transmission of reply data. Specifically, in the
instance I've been able to trap, the device should have responded with
the data string and then an "OK" handshake string. A second driver
thread issued an SRQ between the data string and the "OK" handshake
string and the 'O' of the "OK" string never appeared on the GPIB bus.

Can anyone offer suggestions as to why this might occur? Or, pointers
to where I should be looking?

I'm a total GPIB newbie and am somewhat lost. It seems that SRQ is a
bus state that should not interfere with data transmission but a GPIB
analyzer does show that a data byte is being lost.

Thanks in advance for any suggestions.

[Anonymous]

On Jan 7, 11:47 am, kwsch...@gmail.com wrote:
> We hired a guy to write a GPIB driver for a new instrument. For the
> most part it works fine but sometimes the host times out on the
> device. Since the guy who wrote this code seems to be absent from the
> planet I've been forced to try to fix it myself.
>
> After some research it seems that the host times out due to a lost
> byte of data. The data byte appears to get lost when SRQ is asserted
> by the device during transmission of reply data. Specifically, in the
> instance I've been able to trap, the device should have responded with
> the data string and then an "OK" handshake string. A second driver
> thread issued an SRQ between the data string and the "OK" handshake
> string and the 'O' of the "OK" string never appeared on the GPIB bus.
>
> Can anyone offer suggestions as to why this might occur? Or, pointers
> to where I should be looking?
>
> I'm a total GPIB newbie and am somewhat lost. It seems that SRQ is a
> bus state that should not interfere with data transmission but a GPIB
> analyzer does show that a data byte is being lost.
>
> Thanks in advance for any suggestions.

After further analysis it looks like the driver on the device side is
sensitive
to the timing of when the host issues the serial poll enable. The SRQ
from
the device seems to be pending for awhile, but if the host issues the
SPE
at the "wrong" time the byte that gets loaded into the data byte out
register is lost.

Should the driver be looking at some bus condition before loading each
byte for transmission?

[Ted_H]

Hi,

The SRQ line can be asserted by a device on the GPIB bus for any number of reasons.  Typically devices will assert the SRQ when they have data ready, though this is different for each device.  If you are using the NI-488.2 drivers, and have automatic serial polling enabled, when the SRQ line is asserted, the 488.2 driver will automatically perform a serial poll to determine what device on the bus sent the request. When a device is polled it will respond with a single status byte. I would suggest disabling automatic serial polling from Measurement and Automation Explorer, at least for testing purposes to see if we can avoid this data loss issue.

The issuance of the SPE by the host is questionable to me.  Do you know why a SPE would be issued in your code in the middle of receiving data? You mentioned in your first post that a second driver thread issued an SRQ, can you elaborate a bit on that? I would also recommend looking into the instrument documentation to see under what circumstances the device will issue an SRQ.  I hope this information helps.  Please post back with any developments or additional questions.  Thanks!

Ted

[Anonymous]

Hello Ted,

Thanks for the reply! I will talk to the person who wrote the host
side code to see if SPE can be disabled.

To be clear, the only code I have control of is the code running on
the instrument that the host talks to. My post was not clear about
that. This is a SCPI instrument
and the host issues commands and instrument replies. Many commands can
result in two reply strings to the host, a data string and an "OK"
handshake string. Each string is CR/LF terminated (which implies two
EOMs for each command, maybe this is the problem?)

The instrument code has two threads, one i/o thread that actually
receives and transmits data and an application thread that interfaces
to other code on the instrument. The app thread can issue devctl()
calls to issue SRQs when data becomes available for transmission. So
the two threads were not synchronized.

I changed the code to synchronize assertion of SRQ so it cannot get
raised while a data string is being transmitted. That greatly helped
the problem, but did
not eliminate it entirely.

Please consider this scenario:

1. Host sends a command to query some data
2. Instrument replies with a data string
3. Data becomes available, and SRQ is raised
4. Host issues SPE
5. Instrument replies with "OK" handshake string.

The problem is the timing of event 4. It seems that when a reply data
byte is loaded into the data out register when SPE is issued by the
host, the instrument side GPIB chip responds with a status byte - but
the data byte in the data out register is lost. When this happens the
host side generates an error, either a timeout
or an invalid string received.

Is there a way for the device side driver to know when it is and is
not safe to load data into the data out register?

I apologize for my newbieness, there's a lot to know here.

[Ted_H]

You are right, if there is a reply byte in the data out register, and an SPE is issued, the device will reply with a status byte, and you will lose the previous data in the register.  To get around this, you will need to wait to put the data in the output register until after the device is polled.  Optionally you can simply remove the SPE altogther. So long as you know what device is asserting the SRQ, you don't need to poll the device. This could cause problems if you have multiple devices on the bus. 

Also, what language are you programming in? LabVIEW, C++, Basic?  Also, are you using the NI-488.2 driver, or are you developing your own driver?

I hope this helps, and if you have any additional questions don't hesitate to post back. 

Thanks!

[Anonymous]

Hi Ted,

Thanks very much, that's the problem I was suspecting..

One last question please ... At the chip level what's the best way to
determine when the SPE transaction has been received and the status
byte returned?

The code is straight C running on QNX, which we developed ourselves.

Again, Thanks VERY much! You are a lifesaver.
Cheers,
Ken

[Anonymous]

As a follow-up, I implemented code to poll the serial poll status
register after asserting SRQ, waiting for the pending bit to clear,
and it takes nearly fours seconds from SRQ assertion until the
pending bit clears. Is that length of time normal? Seems like forever,
esp. since this is currently the only device on the bus (but it may
not be in the field).

Thanks again!

[Anonymous]

As yet another follow-up, I discovered the SPMS bit in the address
mode register. By waiting for
that bit to clear before loading a byte for transmit the problem has
been reduced 10 fold, but it still
happens every minute or so instead of every couple of seconds as
before.

Any more suggestions as to what could cause this?

[Steven_T]

Hello,

There could be quite a bit causing this problem.  I could probably get a little farther by getting the gpib ASIC used in your instrument.  I would also like to know what your instrument's firmware is based on.  Did the programmer (who is unfortunately absent) use the example provided by NI (ESP-488)?

The usual way of doing these types of actions is to only perform one action through the GPIB at a time.  According to the TNT4882 manual, there are certain actions that need to take place to tranfer data.  However, these actions should not be started until after the instrument is addressed to talk or listen by the controller.  One of the last things to happen is actually putting data into the FIFO or Data Out register.  Under what conditions does your instrument assert SRQ?  Is there a way to make sure that your instrument is not requesting service during any transfer or during preparation for a transfer?  I believe we use locks to make sure these things don't happen.

I hope this helps,
Steven T.

[Anonymous]

Thanks for your reply, it does help.

The chip is a Measurement Computing I-CB7210-R.

I don't think he based his code on anything. He was supposed to be
well experienced in GPIB but the driver is pretty simple. Maybe that's
the problem.

Basically, the ISR waits for an interrupt.

If it's a receive interrupt it reads and buffers the byte. If the
receive interrupt status indicates EOS, or the buffer is full, it
holds the RFD pin until the buffer empties.

If it's a transmit interrupt it loads the next transmit byte into the
data out buffer. If there are no more bytes to transmit it disables
transmit interrupts and is done.

Normally the instrument is in strictly half-duplex operation where the
host issues queries and the instrument replies with data. In that mode
everything works well.

The sticky part is the SRQ. The host has the option to turn on service
requests, that get asserted when a data sample is available to read.

Originally this was being done in a secondary thread and it would be
asserted at any time, without regard to anything else that was
happening in the driver. I changed this so that SRQ would be asserted
immediately if no data transmission was in progress, otherwise the SRQ
is delayed until the current transmission is complete. I also changed
the transmit logic so that a byte is never loaded into the data out
register when the address status register SPMS bit is set.

These changes helped a LOT, but still, once a minute or so, a data
byte is lost. At this time I think we are generally only doing one
thing at a time, but the driver blissfully ignores whether it's a
talker or listener.

Maybe I need to explicitly check for TALK mode before sending any
data?