GPIB (TNT4882): Is a delay needed between Rx and Tx?

[SteveW]

I designed a GPIB interface into an instrument (a high power RF amplifier) using the TNT4882. One user kept getting timeouts when communicating with this instrument. After extensive remote troubleshooting it was determined that the instrument was responding to his queries before his controller was ready, so the controller never saw the response. It was determined that a delay of around 1 ms prior to responding to the queries solved the problem. A delay of approximately 2 ms was added to provide margin. Recently another customer has run into a similar problem of time-outs. Is there a specification that I have missed regarding a setup time prior to responding to queries?

Regards,

Steve

[Albert.Geven]

are you connecting the error out of the write to the error in of the read?
in that case it should work.
otherwise you probably have a race condition.
starting the read directly after the write with a default of 10 seconds should give you good results.

[Steven_T]

Hello Steve,

What is your T1 Delay?  This is the amount of time between when the data is put onto the data lines (DIO[8-1]) and when DAV is asserted to indicate that the data is available.  Perhaps setting the T1 Delay to the maximum (2000ns) could help you.

Can you tell if a complete handshake is happening?  Normally the data stays on the bus until NDAC shows that the data was received by the listeners.  Does the listener ever indicate that the data was read and accepted?

Steven T.

[SteveW]

Hi,

I'm sorry, but I do not understand the terms "error out of read/write". Some explanation would be appreciated.

Steve

[SteveW]

Hi Steven,

Sorry for my delay in responding (no pun intended); I was out of town.

My T1 delay is the default. What is your recommended method of setting it higher? Setting the value via the PT1 register appears to only affect the second and subsequent bytes, and whatever is causing my problem seems to affect all bytes.

Do I know if a complete handshaking is happening? No. All I know is that my customer, who is in Europe, says that he gets timeouts. Again, I have other customers who are not experiencing any problems.

My code is fairly straightforward, based on the "cookbook" flow in the Programmer Reference Manual. After processing a received message, I send a reply as soon as the GPIB_TALK  bit is set. Am I possibly missing something really basic?

Thanks,

Steve

[Steven_T]

Hello Steve,

Do you have any control over the driver that your customer is using?  Do you publish any driver software for your instrument?  It seems like the talk command is being sent to the instrument before the controller is really ready to receive the data.  I only ask because it may be easier to fix this problem on the controller end by debugging the code that the customer is using. 

Since this only happens with one customer, I would find out their driver/hardware combination to see if there is a way to delay the talk command in their program. 

I also checked with the holdoffs for the chip, but they only apply to acceptors (you instrument would be listener instead of talker).  I have found nothing else about required delays between accept and reply.

Let me know if you can get anywhere with their driver.

Steven T.

Message Edited by Steven T on 03-02-2007 08:57 AM

[SteveW]

Hi Steven,

The problem turned out to be that (supposedly) Agilent Vee cannot deal with only EOI following a string, but needs a termination character (i.e., a LF), which I do not provide. Supposedly Vee can deal with "data" and an EOI, but needs a LF following a string. When I asked why Vee differentiated between a "string" and "data", I didn't get a clear answer. I any case, they found a workaround, the details of which I do not know.

Should a "string" have to be terminated with a LF? This is more or less a standard practice for serial communications, but GPIB is not serial, and has the EOI to handle the end of transmissions.

My plan for the next software update is to give the user the option of having a LF termination character.

Your thoughts will be appreciated.

Steve

[Steven_T]

Hello Steve,

I'm glad you isolated the problem.  It seems strange and inflexible that a LF would be necessary to get it to read the information back into your customer's program.  Perhaps your customer could read it back as a data type and convert it into a string.  The string could be read as an array of U8s (bytes) and then converted into strings easily by the ascii codes.  But I know this is fairly complicated.

Since there is not much of a work-around from the Vee side of things (I've never used it), your best bet would be to have an optional LF in your software.  It just seems like a waste if this fix will only affect and help one of your customers.

Thanks for letting us know what the problem was!

Steven T.