Using GPIB Commander Sessions

This section contains information specific to the Windows product.

Commander sessions are intended for use on GPIB interfaces that are not the active controller. In this mode, a computer that is not the controller is acting like a device on the GPIB bus. In a commander session, the data transfer routines only work when the GPIB interface is not the active controller.

The subtopics are:

• SICL Functions for GPIB Commander Sessions
• Addressing GPIB Commanders
  • GPIB Commander Sessions Interrupts
• Writing GPIB Interrupt Handlers
  • Multiple I_INTR_GPIB_TLAC Interrupts
  • Handling SRQs from Multiple GPIB Instruments
  • Sample: Servicing Requests (C)

NOTE: Because the Keysight 82357 USB/GPIB Interface Converter and the Keysight E5810 LAN to GPIB Gateway do not support non-controller roles, they also do not support GPIB commander sessions.

SICL Functions for GPIB Commander Sessions

This section describes how some SICL functions are implemented for GPIB commander sessions.

SICL Functions for GPIB Commander Sessions

Function	Description
iwrite	If the interface has been addressed to talk, the data is written directly to the interface. If the interface has not been addressed to talk, it will wait to be addressed to talk before writing the data.
iread	If the interface has been addressed to listen, the data is read directly from the interface. If the interface has not been addressed to listen, it will wait to be addressed to listen before reading the data.
isetstb	Sets the status value that will be returned on a ireadstb call (that is, when this device is SPOLLed). Bit 6 of the status byte has a special meaning. If bit 6 is set, the SRQ line will be set. If bit 6 is clear, the SRQ line will be cleared.

Addressing GPIB Commanders

To create a commander session on your GPIB interface, specify the particular interface logical unit or symbolic name in the addr parameter followed by a comma and the string cmdr in the iopen function.

The interface logical unit and symbolic name are set through Connection Expert.

For Example GPIB addresses for commander sessions follow.

Addressing GPIB Commanders

GPIB,cmdr	A commander session with the GPIB interface.
gpib0,cmdr	A commander session with the gpib0 interface
7,cmdr	A commander session with the interface at logical unit 7.

These code samples open a commander session with the GPIB interface.

C sample:

INST gpib;
gpib = iopen (“gpib0,cmdr”);

Visual Basic sample:

Dim gpib As Integer
gpib = iopen (“gpib0,cmdr”)

GPIB Commander Sessions Interrupts

There are specific commander session interrupts that can be used. See Writing GPIB Interrupt Handlers in the following section for more information.

Writing GPIB Interrupt Handlers

This section provides some additional information for writing interrupt handlers for GPIB applications in SICL.

Multiple I_INTR_GPIB_TLAC Interrupts

This interrupt occurs whenever a device has been addressed to talk or untalk, or a device has been addressed to listen or unlisten. Due to hardware limitations, your SICL interrupt handler may be called twice in response to any of these events.

Your GPIB application should be written to handle this situation gracefully. This can be done by keeping track of the current talk/listen state of the interface card and ignoring the interrupt if the state does not change.

Handling SRQs from Multiple GPIB Instruments

GPIB is a multiple-device bus and SICL allows multiple device sessions open at the same time. On the GPIB interface, when one device issues a Service Request (SRQ), the library will inform all GPIB device sessions that have SRQ handlers installed.

This is an artifact of how GPIB handles the SRQ line. The underlying GPIB hardware does not support session-specific interrupts like VXI does. Therefore, your application must reflect the nature of the GPIB hardware if you expect to reliably service SRQs from multiple devices on the same GPIB interface.

It is vital that you never exit an SRQ handler without first clearing the SRQ line. If the multiple devices are all controlled by the same process, the easiest technique is to service all devices from one handler. The pseudo-code for this follows. This algorithm loops through all the device sessions and does not exit until the SRQ line is released (not asserted).

while (srq_asserted) {
serial_poll (device1)
if (needs_service) service_device1
serial_poll (device2)
if (needs_service) service_device2
...
check_SRQ_line
}

Sample: Servicing Requests (C)

This sample shows a SICL program segment that implements this algorithm. Checking the state of the SRQ line requires an interface session. Only one device session needs to execute ionsrq because that handler is invoked regardless of which instrument asserted the SRQ line. Assuming IEEE-488 compliance, an ireadstb is all that is needed to clear the device’s SRQ.

Since the program cannot leave the handler until all devices have released SRQ, it is recommended that the handler do as little as possible for each device. The previous sample assumed that only one iscanf was needed to service the SRQ. If lengthy operations are needed, a better technique is to perform the ireadstb and set a flag in the handler. Then, the main program can test the flags for each device and perform the more lengthy service.

Even if the different device sessions are in different processes, it is still important to stay in the SRQ handler until the SRQ line is released. However, it is not likely that a process that only knows about Device A can do anything to make Device B release the SRQ line.

In such a configuration, a single unserviced instrument can effectively disable SRQs for all processes attempting to use that interface. Again, this is a hardware characteristic of GPIB. The only way to ensure true independence of multiple GPIB processes is to use multiple GPIB interfaces.

/* Must be global */
INST id1, id2, bus;

void handler (dummy)
INST dummy;
{
int srq_asserted = 1;
unsigned char statusbyte;

/* Service all sessions in turn until no one is
requesting service */
while (srq_asserted) {
ireadstb(id1, &statusbyte);
if (statusbyte & SRQ_BIT)
  {
/* Actual service actions depend upon the
application */
iscanf(id1, “%f”, &data1);
}
ireadstb(id2, &statusbyte);
if (statusbyte & SRQ_BIT) {
iscanf(id2, “%f”, &data2);
}
igpibbusstatus(bus, I_GPIB_BUS_SRQ,
&srq_asserted);
}
}

main() {
/* Device sessions for instruments */
id1 = iopen(“gpib0, 17”);
id2 = iopen(“gpib0, 18”);

/* Interface session for SRQ test */
bus = iopen(“gpib0”);

/* Only one handler needs to be installed */
ionsrq(id1, handler);
.
.