TNT4882 Response Time Problem

[SteveW]

I designed a GPIB interface into an instrument (a high power RF amplifier) using the TNT4882. The majority of users have no problems communicating with the instrument. However, several have had problems, usually involving timeout errors. In a couple of cases the problems involved the use of bus extenders and GPIB/Ethernet converters. I got things working by adding a delay between the poll to my instrument and the response, and more oddly, adding a delay between each character sent to the FIFO in the TNT4882. I am not overrunning the FIFO (my longest message is only about a dozen characters, and I monitor NFF). Shouldn't the default handshake function of the TNT4882 make delays between characters unnecessary?

I don't have a bus analyzer, but have used NI Spy and traps in my code to get some idea of what is happening. It appears that there are no problems with processing the polls. The problem appears to be only with responses. For example, when a bus extenders is used without the delays mentioned above, the entire query is read correctly, but typically only the the first one or two characters are received by the bus controller in response to a query.

The uP controlling the TNT4882 is performing system monitoring functions, and unnecessary delays, even a few mS, are problematic. Equally important is my nagging feeling that I am doing something blatantly wrong! Any ideas as to where to start looking?

Regards,

Steve

[Steven_T]

SteveW,

With these types of problems, it is sometimes necessary to pull out some type of analyzer so that you can find out what is actually making it onto the GPIB.  You can use anything that will allow you to see the handshaking lines and data lines of the GPIB.  Looking at the extender problem, you should take out the waits that get things to work and monitor the FIFO.  Make sure that the entire message is in the FIFO and that the FIFOs eventually become empty after your message is actually output to the the GPIB.  This test will verify that you are putting the entire message into the FIFO and that the FIFO is emptying when you are done.

You should also monitor both sides of the extender with the analyzer of your choice.  Verify that all of the data is being put onto the GPIB and that the same data is being translated across the extender.  This test will simply verify that the extender is working as expected.

If we find that the data is on the GPIB when the timeout errors happen, then the application is not reading the GPIB correctly.  I think this problem is very unlikely, but we can cross this bridge if we must.

Even the first experiment may give you some results you can start acting on.  Let us know if you find any new information.

I hope this helps,
Steven T.

[SteveW]

Steven,

With a combination of your suggestions and an old response I found from GPIB Guru, I found the problem. Somehow I neglected to look for Done following my write to the FIFO, so if the bus controller was fast, it got the entire message before I re-initialized the TNT4882 for reception, which of course includes a reset FIFO command. So anything slowing transmissions, like a bus extender, resulted in losing part of the message. This explains Thanks for the help.

Steve