ibdev() returns EDVR after repeated successful calls.

[AgeeWasOut]

After between 800 and 1400 repeated successful calls, ibdev() returns EDVR

I have a DLL that makes a single call to ibdev().  Communications to the instrument use the single device ID returned by ibdev() until the DLL is released.  The DLL may be loaded and release hundreds of times by the parent program.  After between 800 and 1400 successful calls ibdev() returns EDVR.  The number of call varies by operating system and/or NI-488.2 version, but is exactly predictabe for a particular host computer.  It fails after 800 calls for Windows XP 2gb ram with Ni 2.7.  It fails after 1400 calls for WIndows 7 8gb ram with Ni 3.  The behavior seems to indicate that a specific number of device accesses is being exceeded.  Another possibility would be that there is some sort of buffer overrun in NI-488.2, but that doesn't seem to agree with a predictable failure point.

I get the sense that I need to explicitely release the device when I terminate the DLL, but I know of no NI-488.2 call to do that.

Any thoughts?

Thanks

AWO

[nyc_(is_out_of_here)]

What programming language are you using such that you need a DLL to make calls to ibdev()?

[AgeeWasOut]

I am working under Visual C++.  That the calls are being made from a DLL is not related to the GPIB communications but to the fact that the calls are coming from independent agents (DLLs) that are plug-ins to my program.  In other words, the use of DLLs is related to the larger program design and not to the fact that a few of these agents do GPIB communications.

Thanks for the attention

AWO

[Leah-L]

AWO,

What I suspect is happening is that when we make ibdev calls some referenced are being opened that are never closed. 

Have you considered looking into the ibonl function?

I went ahead and copied the function help in CVI for this function.

 This function does the following:

Description for Online:

Cancels any asynchronous I/O in progress. Resets all
configurable software parameters to their default values.
If called on a board, reinitializes the board.

Description for Offline:

Disables a board or device from GPIB operations.
Disassociates the descriptor from the board or device.

Note: If the device descriptor was obtained from OpenDev,
do NOT use this function to take the device offline.
Instead, use CloseDev (the "Close Device" panel).

/*-------------------- Prototype ---------------------*/
int ibonl (int BoardDevice, int Operation_Mode); 

Regards,

Leah

[AgeeWasOut · Accepted solution]

Leah,

Thanks for the advice.  I will give ibonl a try.  However, I am out of the office for the week, so it will be next Monday before I can see if this works for me.  I will leave this thread open until then.

Thanks again,

AWO

[AgeeWasOut]

Leah,

I don't know if you continue to check these posts after such a period of time.  I tried ibonl() immediately after the ibdev() call to reset the device and place it online.  This did no harm, but also did not correct the problem.  This is unfortunate, because it is a very simple coding issue.  Next I tried the ibonl() call to take the device offline after communications had terminated.  This appears to have worked.  Yippee.  Unfortunately, for reasons peculiar to my program, this is a bigger coding issue, but I now have a path to a full fix.

Thanks for pointing me in the right direction.  I have accepted your suggestion as a solution.  I presume that will close this thread.

Thanks again...

AWO