Application conflict for PCI-GPIB card control and EOWN error

[WRL127]

Hello,

I am trying to set up a computer controller for an Instron 5848 system after a failed hard drive forced me to start with a fresh installation of Windows and all of the drivers and software. The Instron is controlled through a PCI-GPIB interface.

The 5800 Console software and the Labview VIs that I used to control the load frame before are both back up and running, but only when it's either the Instron or NI software alone. If I try to run 5800 Console concurrently with any other software that tries to communicate with the Instron via the GPIB card, one or both programs will freeze and/or crash. An NI Spy capture shows that the iberr 13 precedes the crash. The only other errors I've observed are iberr 6 (I/O timeout) that follow this first error. Though iberr 13 is not listed in the NI 488.2 manual, an online search gave the error definition EOWN: "Shareable board exclusively owned" from an NI help page for Labview 7.1. All of the software is, as far as I know, the same versions that were running concurrently without any issues prior to the hard drive failure.

Trying a different card, moving it between PCI slots, alternate driver versions, and different startup or installation sequences don't seem to be helping. My system specifications are as follows:

Dell GX260 (Pentium 4 2.0GHz, 2GB Ram)

NI PCI-GPIB card 10437FE

NI 488.2 v2.42

VISA 3.2

Labview 7.1

Instron 5800 Console 7.6

Windows 2000 SP2

I've also tried using Windows 2000 SP4 and the complete NI 488.2 2.6 package, but that didn't help. I went back to SP2 because that's what was working pre-crash.

Any feedback at all will be appreciated. Let me know if I can provide any more information or NI Spy captures.

Regards,

Wade

I'll attach a NI Spy log starting with a functioning 5800 Console running before it is disrupted by starting up our Labview VI.

Quick notes from log:
Line 528: Point where I start the labview VI
Line 531: iberr 13 appears
Line 583: First errors recognized by NI Spy show up (iberr 6 I/0 timeouts)
Line 5025: More I/O timeouts and 5800 Console seems to give up trying to communicate with instrument

[WRL127]

I should add that though NI Spy captures started after 5800 Console is already running work, captures started before I open 5800 Console cause it to fail to start properly. Also, even though I was able to find a definition of iberr 13: EOWN, I could find no troubleshooting help pages for the error.

[Steven_T]

Hello WRL,

The iberr 13 that you are referencing does not exist.  The manual shows that ibtmo will place the previous timeout value in iberr.  Also, the manual says that the iberr value does not indicate an error unless the ERR bit is also set in ibsta (also, Spy will color any error lines in red).

After looking at the Spy capture, there are three different processes accessing the PCI-GPIB at the same time.  One seems to be performing a query/read operation every half second.  Another process is constantly polling for SRQ and performing parallel and serial polls when SRQ is asserted (every now and then it will also send/receive data).  The last process seems to be performing some random reads and writes, but sometime uses asynchronous writes.  The major errors seem to happen when these a synchronous writes occur.

How are the three processes arbitrating the use of the GPIB bus so they don't mess each other up?  In other words it is possible for this to happen...

Process A writes Query to Instrument "*IDN?" <instrument places the response into its internal output buffer>

Process B writes Query to Instrument "*MEAS?" <instrument places the response into its internal output buffer>

Process A reads from Instrument "1.225mA" <process A just received the response from Process B's query...whoops!>

1.  You may also want to limit the amount of asynchronous IO that is happening in LabVIEW (check this by right clicking on each GPIB Write and GPIB Read).

Steven T.