TNT4882 listener behaviour

[botnico]

Hello,

i have a TNT4882 in an embedded system connected to a PCI GPIB Card (PC).

The PC is the controller.

The NI Explorer finds the TNT4882 when scanning.

When i try to write a string (no query) using the NI Explorer, the following happens:

the TNT4882 goes to listener state and receives the string.

Immediately after this, it goes to talker state and my firmware tries to send something

(as always when addressed as a talker). But there is no transfer, so the write in the embedded system fails with a timeout.

Is this a usual behaviour, that there is a talk request after a listen request when only a write is desired?

best regards,

steffen

[Steven_T]

Hello Steffen,

I'm afraid that I may not understand the problem you are facing.  I think that the problem you are describing is one of the following.

1.  The PC (using a PCI-GPIB) writes a string to the TNT4882.  The TNT4882 is addressed as listener, accepts the message, but is then addressed as talker.  At that point, it attempts to send it's message, but either there is no listener or the listener does not read the data off of the GPIB.

2.  Same as before...The TNT4882 is addressed as listener, accepts the message, but is then addressed as talker.  However, its output buffer is empty, so it has no message to send and does not write anything.

3.  Same as before...The TNT4882 is addressed as listener, accepts the message, but then attempts to reply even though it is not addressed as talker. 

Please let me know which issue you are facing (of if it is actually some funny hybrid).  I believe that you are facing issue number 1, but there is a possibility different problems could be causing 2 or 3.

Thanks,

Steven T.

[botnico]

Hello Steven,

my first problem was:

- I want to query (write and then read) the TNT4882 from my PC.

The following happens then:

1. The TNT is addressed as listener and receives the string. The firmware processes the string and prepares data to be sent back.

2. The TNT is addressed as talker and tries to write the prepared data. It fails with a timeout because noone listens.

3. The TNT is addressed as talker again and writes the prepared data. The PC is listening and receives the firmware output data.

I tried to find the error so stopped querying and reduced it to a write (from the PC application).

And whats happening here seems to be Point 1 in your post.

The TNT is definetely addressed as a talker after being addressed as a listener. But why?

Thanks,

Steffen

[Steven_T]

Hello Steffen,

The only time that I have seen the TNT4882 go into talker address mode is when it receives the talker command.  Would you be able to get a spy capture of what is happening on the PC/PCI-GPIB side?  The spy capture would allow us to see if your controller test program is accidentally sending a TA command to your instrument.

Here is a link on how to take a "good" spy capture.

http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9

Also, I would like to know how many other instruments are on the GPIB as well as all of the primary addresses. 

Steven T.

[JÞB]

---

@botnico wrote:

1. The TNT is addressed as listener and receives the string. The firmware processes the string and prepares data to be sent back.

2. The TNT is addressed as talker and tries to write the prepared data. It fails with a timeout because noone listens.

3. The TNT is addressed as talker again and writes the prepared data. The PC is listening and receives the firmware output data.

Thanks,

Steffen

---

Steffen-

I think you may have found a case for unaddressing!  from your discription above the device would only be unaddressed after step 2 (since it ended in failure) allowing a new handshake to be generated in step 3.

This property is setable in a VISA GPIB instr class session from a property node GBIP Settings>Unaddressing.

Let me know if that helps