Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

XP/GPIB to legacy NI gpib device communications

I am using a XP platform and Visual Studio 6.0 to try to communicate with an older gpib device.
I am trying to recieve a serial poll byte back from the older device.
The SPR is returned about 20% of the time.
Are there any compatibility issues that I may not know about.
It is as if the two devices work for a while and then stop talking.

The XP box uses the Ibtrg command to trigger the response and then uses the Ibrd command to receive
the response.
0 Kudos
Message 1 of 14
(4,264 Views)
Jason,

Are you using the ibrsp command anywhere to conduct the serial poll? Which GPIB hardware are you using and what GPIB instrument are you communicating with?

Craig H.
0 Kudos
Message 2 of 14
(4,252 Views)
The XP box uses the following code to issue the serial poll:

char BoardLevelSpoll( char DevicePrimaryAddr, char *spoll )
{
const char Terminate[] = { SPD, UNT, UNL } ;

static struct { char Untalk,
Unlisten,
ACIAU_ListenAddr,
SerialPollEnable,
DeviceTalkAddr ;
} SpollPreamble = { UNT, UNL, 0x20, SPE, 0 } ;

char ComFault ;

/* Add the talk address of the device to the spoll preamble.
see National Instruments' Software Reference Manual on calculating
a talk address. */
SpollPreamble.DeviceTalkAddr = 0x40 | DevicePrimaryAddr ;

/* Send the preamble, this sets up the serial poll transaction. */
ibcmd( aciau, &SpollPreamble, sizeof(SpollPreamble) ) ;


/* Read the serial poll byte. */
ibrd( aciau, spoll, 1 );



/* Save whether a comm error occurred. */
ComFault = (ibsta & (TIMO | ERR)) != 0 ;

/* Terminate the transaction. */
ibcmd( aciau, (PVOID)&Terminate, sizeof(Terminate) ) ;

return 0;//ComFault ;
}


The legacy device is using the ibrsv (similiar to the ibrsp, I believe) command followed by the ibwrt command to respond to the serial poll.

ibrsv(gbib, 0);
ibwrt(gpib, data, length);



This discussion is occuring between two computers. The XP box is requesting the serial poll and the AIX 3.2.5 box is responding to it. The XP box is using the NI-488.2 gpib card with driver version 2.3. The AIX box is using an old micro-channel gpib card. I don't know much more than that about it. It is probably 10-12 years old.

The exchange works sometimes. If I issue ~100 serial poll commands I get probably 25 or so back. They come back perfect.
0 Kudos
Message 3 of 14
(4,244 Views)
Here is a more detailed account of what the AIX box is doing. Sorry.

int send_control_message(device_id,data,length)
unsigned char device_id;
unsigned char *data;
int length;
{
unsigned char serial_poll;
int ctr;

/*------------------------------------
Mask out high nibble of device_id.
Set SRQ and Config Control
Request Service
Wait for device trigger
Un-assert SRQ
Write data to device
-------------------------------------*/


serial_poll = CONFIGURATION_CONTROL_MASK;
serial_poll = serial_poll | (device_id & MASK_OUT_HIGH_NIBBLE);

ibrsv(gpib,serial_poll);
ctr=0;
while (ctr<3) {
ibwait (gpib,TIMO|DTAS);
if (ibsta&TIMO) {
if (ctr==2) {
return (GPIB_ERROR);
} else {
ctr++;
} /* endif */
} else {
if (ibsta&DTAS) {
ctr=3;
} /* endif */
} /* endif */
} /* endwhile */

if (wait_for_event(TACS_Rx) == TACS_Rx)
{
ibrsv(gpib,0);
ibwrt(gpib,data,length);
if (ibsta & ERR)
{
#ifdef DEBUG
printf("%s:ibwrt#3--iberr=%d, ibcnt=%d\n",progname,iberr,ibcnt);
fflush(stdout);
#endif
return (GPIB_ERROR);
}
return(SUCCESS);
}
else
{
ibrsv(gpib,0);
#ifdef DEBUG
printf("%s:ibwait#3--iberr=%d, ibcnt=%d\n",progname,iberr,ibcnt);
fflush(stdout);
#endif
return (GPIB_ERROR);
}
}
0 Kudos
Message 4 of 14
(4,065 Views)
Jason,

You may have an autopolling issue here. You're doing a board-level serial poll, so the NI-488.2 driver isn't "involved" in the serial poll at all because you're manually sending the command bytes down to the AIX box. If your code has any ibdev() calls in it where you open a handle to the device, I can see what you're describing happening. See the help topic "Automatic Serial Polling Overview" for more information. To test out this theory, on your XP box (the controller), make the call ibconfig(ud, IbcAUTOPOLL, 0) after you open your board handle with ibfind. If the problem goes away, then you have averted the race condition that could've been caused by autopolling competing with your polling mechanism in the post above.

If the problem stays around, let us know. I'm curious what the return value is when the serial poll byte fails...I assume you just get a timeout on the read? Is there a specific reason that you're doing board-level serial polls? The NI-488.2 driver will handle all the command bytes for you if you just use the ibrsp() function on a device-level handle.

Thanks,
Scott B.
GPIB Software
National Instruments
0 Kudos
Message 5 of 14
(4,207 Views)

Thanks for the help.  I do believe we had a auto-polling issue.  Once I issued the ibconfig() command our bus cleared up dramatically.  Polling seems to only be happening when I direct it to through my application.  I do have a couple more question for you.  First, does the ibconfig() command stay active if I shut my application down and then re-start it?  That is, if I use the ibconfig command to turn off auto-polling and then shut off the application and restart it is auto-polling still disabled.  I ask because once I issued the command the phasing stopped.  I was doing some testing and took the command out of my application, re-compiled and re ran the program.  I expected the phasing to return, but it never did.  Is this to be expected?

Second, my application runs great for about an hour and then the gpib bus seems to stop working.  I lose status on all my devices.  When I turn on NI Spy I see all the ibread() commands returning with the EADR(3) error and all other gpib commands returning with EABO(6) errors.  I have a control panel that I can use to control my threads.  GPIB is a dedicated thread.  If I stop and start the thread the bus clears and all is good for about another hour or so.  Any ideas why this might be happening.  If not, what is the best command to issue to clear the bus or to reset the card without losing all the settings?

Thanks for all your help. 

0 Kudos
Message 6 of 14
(4,161 Views)
On the autopolling setting, I also see that behavior on my machine.  To make sure autopolling is turned off, you can call ibask(ibaautopoll) to query it (0 means off) or ibconfig(ibcautopoll) to set it.  Additionally, you can turn off automatic serial polling on your GPIB board in the MAX properties for that board.  To "pull in" the MAX properties, make sure you do an IBONL 1 on the board when you open it with IBFIND.
 
The best way is to guarantee the autopoll setting with an ibconfig call, in my opinion.
 
As far as your other errors, ibrd() returning EADR means that the GPIB board is not addressed as a listener when you invoke ibrd.  This is necessary for you to perform a board-level read, so make sure that your ibcmd call that does the addressing is correct and is executing BEFORE your ibrd call.
 
Hope this helps.
 
Scott B.
GPIB Software
National Instruments
0 Kudos
Message 7 of 14
(4,136 Views)

What is the difference between the ibrsv and ibrsp commands?  The legacy device I am communicating with uses the ibrsv command.  I am wondering if my new NI card is having a tough time interfacing using this command.

 

Thanks...

0 Kudos
Message 8 of 14
(4,126 Views)

Jason,

The difference is that ibrsv sets the serial poll response byte and requests service (if bit 6 is set in the byte).  The ibrsp() command is called by a controller, and causes the controller to read the serial poll response byte by serial polling the device.  The commands are somewhat complementary, almost equivalent to a "write" and a "read".  They should work just fine together when used in this way.

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 9 of 14
(4,104 Views)
I have some more information concerning why my application shuts down after about 1 1/2 hours.  I happened to have NI Spy running when the application went down and for the first time saw the initial error.  It was a EBUS(14) error.  Before I get this error everything works great.  After an hour or so this error pops up and none of my serial polls work thereafter.  Have any of you seen this before.  My program loops around this serial poll.  If I don't get anything I try again until I do get something.  Again, all is good for about an hour and then EBUS(14) and then nothing but EADR(3)'s and EABO(6)'s.  If I start and stop the bus everything is good and the application runs for about another hour or so.
0 Kudos
Message 10 of 14
(4,090 Views)