GPIB Handshake Lines

[JasonLM]

I am rehosting a older piece of equipment onto a newer platform.  The system utilizes gpib for most of its communication with other h/w.  I bought the requisite h/w plugged it in and recompiled the application and most everything worked.  Two devices, however, are not working.  I have a gpib+ card and have verified the data is ok, but the handshaking between the two pieces of h/w is different.  Is there a way to modify this behavior?  Does NI have any documents on how handshaking works?  I am not sure how to change this behavior at the application level.

If anyone needs more information, post and I can provide GPIB Analyzer screenshots...

Thanks...

[Collin M]

Some screenshots would be great. You can also save the analyzer captures and post those files here.

[JLS]

Hello,

The handshaking for GPIB is very well defined and is part of the 488 family/evolution of standards.  I don't think you'll want to change the handshaking mechanism for any 488.2 device or controller, since it would then break its compatibility with other 488.2 devices.  Posting analyzer captures would be helpful for sure!  The handshaking should go something like:

.

.

.

Device: Ready for Data (via NRFD)

Controller: Data Available (via DAV)

Device: Data Accepted (via NDAC)

.

.

.

That's the basic 3-wire handshake.  Post some analyzer captures and we'll check out the details.  For efficiency in reading the capture, post as simple a communication as possible!!!

Thanks, and looking forward to your post!

Best Regards,

JLS

[JasonLM]

Here are two snippets of captured data.  The first is from the old machine and the second is from the new machine.  I was wrong, I believe, in assuming it was the handshake lines.  After further evaluation I believe it is the control lines that are causing my problems.

Here is the old command transfer:

          --  --  --     O  4f  01001111  0 0 0 1 0  0 1 1  DAB
          --  --  --     X  58  01011000  0 0 0 1 0  0 1 1  DAB
          --  --  --     1  31  00110001  0 0 0 1 0  0 1 1  DAB
          --  --  --     A  41  01000001  0 0 0 1 0  0 1 1  DAB
          --  --  --     ,  2c  00101100  0 0 0 1 0  0 1 1  DAB
          --  --  --     0  30  00110000  0 0 0 1 0  0 1 1  DAB
          --  --  --     1  31  00110001  1 0 0 1 0  0 1 1  DAB  END
          --  --  --     ?  3f  00111111  0 1 0 1 0  0 1 1  UNL
          --  --  --     @  40  01000000  0 1 0 1 0  0 1 1  TA0
          --  --  --     ?  3f  00111111  0 1 0 1 0  0 1 1  UNL
          --  --  --     $  24  00100100  0 1 0 1 0  0 1 1  LA4
          --  --  --     O  4f  01001111  0 0 0 1 0  0 1 1  DAB
          --  --  --     X  58  01011000  0 0 0 1 0  0 1 1  DAB
          --  --  --     2  32  00110010  0 0 0 1 0  0 1 1  DAB
          --  --  --     A  41  01000001  0 0 0 1 0  0 1 1  DAB
          --  --  --     ,  2c  00101100  0 0 0 1 0  0 1 1  DAB
          --  --  --     1  31  00110001  0 0 0 1 0  0 1 1  DAB
          --  --  --     4  34  00110100  1 0 0 1 0  0 1 1  DAB  END
          --  --  --     ?  3f  00111111  0 1 0 1 0  0 1 1  UNL

[JasonLM]

Continued...

Here is the new machines transfer:

          --  --  --     O  4f  01001111  0 0 1 0 0  1 1 1  DAB
          --  --  --     X  58  01011000  0 0 1 0 0  1 1 1  DAB
          --  --  --     1  31  00110001  0 0 1 0 0  1 1 1  DAB
          --  --  --     A  41  01000001  0 0 1 0 0  1 1 1  DAB
          --  --  --     ,  2c  00101100  0 0 1 0 0  1 1 1  DAB
          --  --  --     0  30  00110000  0 0 1 0 0  1 1 1  DAB
          --  --  --     1  31  00110001  1 0 1 0 0  1 1 1  DAB  END
          --  --  --     ?  3f  00111111  0 1 1 0 0  0 1 1  UNL
          --  --  --     @  40  01000000  0 1 1 0 0  0 1 1  TA0
          --  --  --     ?  3f  00111111  0 1 1 0 0  1 1 1  UNL
          --  --  --     $  24  00100100  0 1 1 0 0  1 1 1  LA4
          --  --  --     O  4f  01001111  0 0 1 0 0  1 1 1  DAB
          --  --  --     X  58  01011000  0 0 1 0 0  1 1 1  DAB
          --  --  --     2  32  00110010  0 0 1 0 0  1 1 1  DAB
          --  --  --     A  41  01000001  0 0 1 0 0  1 1 1  DAB
          --  --  --     ,  2c  00101100  0 0 1 0 0  1 1 1  DAB
          --  --  --     1  31  00110001  0 0 1 0 0  1 1 1  DAB
          --  --  --     4  34  00110100  1 0 1 0 0  1 1 1  DAB  END
          --  --  --     ?  3f  00111111  0 1 1 0 0  0 1 1  UNL 

The command is the OX1A,XX and the OX2A,XX.  If you notice on the first capture the REN control line is on and it is off on the second.  If I manually turn this control line on with the Command Window my commands work perfectly.  You will also notice the ATN line high in the second transfer and not the first.  What would cause this.  I am using the same configuration file in both applications.  The older machine is using a 12+ year old NI card and the new machine is using a 6 month old NI card.

My question is, how do I turn this control line all the time with my application?  Is this the best solution?

[Collin M]

You can control the REN line with the ibsre command. This command should be documented in NI-4882 help file available through MAX. Are you able to modify the original application?

I don't see any difference between the ATN line in the two captures.

I do see that the state of SRQ is different between the two captures. Is this causing any problem for your application? It seems that it is always asserted in the second capture.

[JasonLM]

I was able to use the RemoteEnable command to make the REN line go high.  This has cleared up my commanding problem.  I am going to investigate a little more before I call it fixed, though.  Any comment on this function?

[Collin M]

ibsre (or EnableRemote) is very straightforward. The sole purpose is to assert or unassert REN. Note that the GPIB controller must be system controller to assert REN. If you are using the NI 488.2 driver, the GPIB controller will be system controller by default.

Did you have a chance to investigate why SRQ is asserted? SRQ is like an interrupt for GPIB. It is used by GPIB devices to signal to GPIB controllers that there is some state the GPIB device wants to convey to the GPIB controller. The specific reason for asserting SRQ is device-dependant.

A good description of the GPIB signals is given in the TNT4882 Programmer Reference Manual, available at http://digital.ni.com/manuals.nsf/websearch/3A8AB50CEBB34BCD86256DB00073E9CD

[JasonLM]

I am not sure why the SRQ line is being asserted. It is not being asserted in the old aplication.  The controller sends a command preamble and then the command to the two I/O cards in the device.  The SRQ line is asserted being asserted when the controller issues the Unlisten command.  I don't see any reason for this to happen.  Like I said earlier the old application is using a very old GPIB card.  Is there any reason you can think of why this would be happening?  There is nothing in my code that makes me think this should happen.  Is this

inherent with newer cards?  Everything seems to be working fine, so I am not too concerned.  I am getting ready to put the application thru its paces during unit testing.  If anything is going to pop up we'll find it then.

Thanks for your help...

[Collin M]

Does your application ever serial poll the device? When you look at the analyzer capture of the old system, does the device ever assert SRQ? Does the device have any indicators that indicate state or any error condition?

Is there a manual or any documentation for the device? You could serial poll it while it is asserting SRQ to find out what status byte it returns.