REN is not set automatically by device functions

[FreddyBZ]

I've encountered some interesting problem on our customer's computer (ATE environment). The computer is connected with GPIB (using NI PCI-GPIB card) to our instrument and to an IC handler. Somehow the handler, or the handler software in the computer, causes the gpib driver or hardware to get into a mode where the REN signal is not asserted automatically with ibclr or ibwrt commands. The sequence looks like:

[Handler software]

.

.

[Our instrument software]

ud = ibfind("DEV6");

ibonl(ud, 1);

ibtmo(ud, T3s);

ibeos(ud, 0);

ibeot(ud, 1);

ibclr(ud);

ibwrt(ud, cmd, strlen(cmd));

Under normal circumstances (for example - without the handler) the ibclr should cause REN to be asserted but in this case it does not. I managed to work around the problem by adding between the handler software and our instruments software the following lines:

ud = ibfind("GPIB0");

ibrsc(ud, 1);

ibsre(ud, 1);

ibonl(ud, 0);

This works but it requires our software to know the name of the GPIB interface ("GPIB0" in this case). Currently our software is given by the user only the instrument identification string ("DEV6" in this case).

My main question: How can the handler software or hardware prevent the NI driver (or hardware) from asserting REN?

Another question: Is there a way to get a board handle or ID from a device handle or ID?

Thanks.

[MXI Master]

FreddyBZ,

I looked into this a little, and the way you have it set up in your workaround is the proper way to set the REN. REN must be asserted with a board level call.  And there is no easy way to figure out which board is used with a device descriptor.  I would recommend to using ibdev, this uses a number indicating the gpib board (0 means gpib0, 1 means gpib1).  This would allow you to know what board they are using with the device.


Message Edited by MXI Master on 02-26-2008 06:59 PM

[FreddyBZ]

Thanks Marshall. The problem with changing to ibdev is backwards compatibility. In any case (and more important) this leaves open the question - what could prevent the NI driver of the PCI-GPIB from setting REN automatically when I call ibclr() or ibwrt()? Can another GPIB device, or the software driving it, leave the PCI-GPIB board or the software driving it in a state that wil behave that way?

[MXI Master]

FreddyBZ,

If you look at the ibclr and the ibwrt in 488.2 help file, you will see that ibclr does not assert REN and ibwrt does not assert it by default.

There is however a setting in Measurement and Automation Explorer for the GPIB cards, "Assert REN with SC". If you select this option and the GPIB interface is the System Controller (SC), the GPIB Remote Enable (REN) line is automatically asserted whenever a device-level call is made. By default, REN is not asserted when the GPIB interface is the System Controller.

[FreddyBZ]

Marshall, what you say is not completely accurate. Without other GPIB controlling software in the machine, the REN is asserted when I call ibclr or ibwrt - without having to configure the driver to assert REN when it is system controller (I saw it many times, in programs and interactively). Also in the documentation of the ibloc function it says "Unless the REN (Remote Enable) line has been unasserted with the ibsre function, all device-level calls automatically place the specified device in remote program mode". But now looking again at this line of documentation, it makes me think that maybe the other program calls for some reason ibsre(ud, 0) to unassert REN and this is the cause of my problem! I'll try to reproduce the problem with ni-spy running and see if this is right.

Thanks.

[MXI Master]

FreddyBZ, I follow your line of thinking. Give it a try and post back here with what you figure out, I think other people would benefit from these findings. I will see what I can recreate as well.