Is the GPIB-ENET/100 device compatible with GPIB ibln() function?

[RichMyers]

I am using a GPIB-ENET/100 device for the first time in a LabWindows CVI
project. I have an HP8903B audio analyzer as one of the GPIB devices.
I downloaded and am attempting to use the driver as indicated by the
following excerpt from the file;

/*= HP 8903B AUDIO ANALYSER ===============================================*/
/* LabWindows 2.3 Instrument Driver */
/* Original Release: August 1994 */
/* . . . .
/* Dec 1999: changed ibwait mask in measure() from 0xc800 */
/* to 0x4100. */
/*================================
=========================================*/

When I attempt to initialize the unit from my CVI program using:
hp8903b_init (GPIB_ADR_HP8903B, 1, &iidHP8903B);

the following error is received:
NON-FATAL RUNTIME ERROR
"HP8903B.C", line 84, col 9
Function ibln: (iberr == 1 [0x1]).

I have traced through the device driver, and everything appears to be fine
up until the call to ibln(). I noticed the following in the help screen for
the ibln() function:
"from ibln() help panel"
Due to hardware limitations, this function is not
available on the GPIB-PC2, GPIB-PC2A, and GPIB-PC CONV
interface boards.

So apparently the ibln() function is not compatible with all GPIB hardware.
Does anyone know if the ibln() function can be used with the GPIB-ENET/100?

[Ryan_M]

Yes, IBLN does work on the ENET. I would suggest using IBIC (ibic.exe) as outlined at http://www.ni.com/support/gpib/max/ibic.htm as a means to determine if your bus is working properly. I might suggest adding an IBSIC call in your program to make sure you are taking control of the bus. The ECIC is typically the result of not having control.

[RichMyers]

Thanks to Ryan for posting a response. His answer, as it turned out, explores the correct problem area. The problem was/is with the control card ud returned from the ibdev command. The value I get is 31,256 for whatever reason. NI support informed me that some people (depending on CVI version and OS platform) have experienced a software glitch if the value returned from ibdev is greater than 1024. I assume the issue is the declaration of a variable type to hold the value in some gpib dll.
I "patched" around it by removing the ibln call from the instrument driver that I was using. Don't know what this will mean if the program is run and the unit is not powered or on the gpib bus...