VISA viOpen cause an interrupt to other instrument (GPIB Chip NI-9914) when running multiple instruments with Fast PC (P4 > 2.8GHz) using NI-PCI GPIB card.

[Dominator]

Hi,

When run multiple instruments using VISA with Fast CPU P4 2.8 GHz or faster using NI-PCI-GPIB card, viOpen cause an unexpected interrupt to other instrument.  The following simple pseudo code program is described below, this test is written in LabView 7 for testing 2 instruments:

1.        i = 1

2.        Itegration = 0

3.        LOOP until Error

4.        if (i modulus 2) = 0 then Res="GPIB0::2::INSTR"

5.        else

6.            Res="GPIB0::1:INSTR"

7.            Itegration = Itegration + 1

8.        endif

9.        viOpen(Res, &viAddress)

10.      viWrite (viAddress, "CLOSE 1")

11.      viWrite (viAddress, "OPC?")

12.      viRead (viAddress, &Buffer)

13.       viClose (Res)

14.       i = i + 1

15.       goto LOOP

I've noticed that, after the second itegration the Instrument 1 reuse the viAddress of the Instrument 2 and vise versa, so when viOpen the Instrument 1, it causes the unexpected interrupt to Instrument 2 and causes the extra character added to the output when try to read.  Sometimes it case an extra character to the input, and cause an invalid command.

I probe the interrupt line of the NI-9914A and I found this problem.

I already fix the Firmware from the instrument to avoid the extra character and the hangging, but the unexpected interrupt is still there,  this cause by the VISA viOpen when other instrument recycle the viAddress from other instrument.

This problem does not occur for CPU other than P4 2.8 GHz and above and also depends on the mother board.  I've tested the no name PC with P4 3GHz but can not reproduce.  The PC brand I've tested that can be reproduced is the DELL P4 2.8 GHz, the Eclipse P4 3-GHz.

Is there any body see this problem ? Please help.

[Collin M]

First, can you post an NI Spy capture showing the good and bad cases?

You said you were getting an unexpected interrupt. I assume this interrupt happens at the NAT9914. Can you read all of the ISRs to determine what interrupt you are receiving?

[Dominator]

Hi DittoHead,

Thanks for the reply, here is the NI-Spy file for the test.  The instrument 1 is used GPIB Address 6 which has old F/W (BAD), and the instrument 2 is used GPIB Address 8 with new F/W (GOOD) that discard the extra character when there is an unexpected interrupt. Actually, when the Output Buffer is empty, and user request a read, it sends message "NO DATA\r\n" to GPIB port, so when there is an unexpected interrupt only one character is sent.  Therefore, the BAD one will have an extra character from the message "NO DATA\r\n".

The unexpected interrupt happened when viOpen is called with one instrument reused the other instrument viAddress. In the ISR handler function has flag to check either Write or Read, but 99% is the Read interrupt.

Please find 2 attachment files: Test_Visa.vi and BadInst6_GoodInst8.spy

The attachment for spy file extention is txt (spy does not on the list of valid extention), please rename the extention back to spy to view it.

[Collin M]

Can you modify the vi so that it only communicates with the instrument that has the failure? Does the failure still happen in this case?

It seems from the NI Spy capture that in the failing case when you write "CLOSE 1" the instrument accepts 1 byte but no additional bytes. Can you tell what state the instrument is in at this point? My guess is that the 9914 has accepted the byte but the firmware has not read it from the DIR and the 9914 is in an RFD holdoff state.

You mentioned an unexpected interrupt in the 9914. Can you tell me which bit in which interrupt register is being set that is unexpected? Could it be the case that the BI interrupt asserts (meaning that the 9914 has accepted a data byte) and another unexpected interrupt is also asserted, and the firmware ISR doesn't correctly handle this case?

[Dominator]

Hi dittohead,

Thanks for the reply.  When the unexpected interrupt ocurred, EITHER the bit BO is set (99%) for Read Interrupt or bit BI is set (1%) for Write interrupt when viOpen is called from OTHER instrument(s) AND when viAddress of OTHER instrument(s) reused THIS instrument viAddress previousely used and closed.  This ONLY happended when we use VISA DRIVER and ONLY for FAST PC (P4 with 2.8 GHz and above).  For IEEE-488.2 commands, no problem at all for any CPU speed.

Corect me if I'm wrong, the viClose maybe did not cleanup probably and the memory address mapping from PCI still pointing to BOTH instruments, if I instroduce viClear before viClose, the unexpected interrupt does NOT happend anymore, BUT with 3 or more instruments, this unexpected interrupt is still there !!!!! 

[ScottieB]

Hello,

I'm still not following your problem.  Is this "unexpected interrupt" you speak of the BO or BI bit being set on the instrument at PAD 8 when you do a viOpen on PAD 6?  So, at your spy line 106, you see BO or BI set on PAD 8, which seems incorrect since you're only talking to PAD 6.  Is that what you're seeing?

Scott B.
GPIB Software
National Instruments

[GPIB_Guru]

What version of NI-488.2 are you using? I am guessing that you are using NI-488.2 2.3 or earlier on the host side. The change from NI-488.2 version 2.3 to version 2.4 is that that ibln call (which is a call to verify that a listener is present) now sends the command UNT across the bus to make sure that there are not any talkers on the bus when the listener is verified. Previously, it did not send the UNT command byte.

Within your loop, the first time through, device one is opened, written to twice, read from, and then closed. The VISA close doesn't do anything on the bus, so the last thing that happened on the bus is that the device was addressed to be a talker. It is currently in TACS when the loop cycles around.

The next device is then opened. The default behavior of VISA when a device is opened is to check to make sure that it is present in the system by making an ibln call. In NI-488.2 2.3, this will assert ATN (taking device 1 from TACS->TADS), send UNL, MLA of device 2, and then unassert ATN. This will place device to in LACS and device 1 will now go from TADS->TACS, generating a BO interrupt.

This is a side effect that you don't want to happen, which is why 2.4 modified its behavior.

Solutions:

1. Upgrade to NI-488.2 version 2.4.
2. Make the VISA open calls outside the loop and pass the wires into the while loop. To the switch on the two passed-in wires and call the Write, Write, and Read calls just as you do. My calling open outside the loop, they will both be tested once at the beginning and this problem will disappear.
3. Before the close, add a VI to send the GPIB Command byte UNT to untalk the bus and make sure the device is quiescent. The VISA Send GPIB Command.vi requries a intf session, so you will need another VISA session. You can probably parse the incoming VISA sessions up to the :: and create a new string for the intf session "on the fly".
4. Open visaconf.ini (c:\vxipnp\WinNT\Nivisa) and find the line  "DisableIbListen = 0" and change the 0 to a 1 to disable the listen. This is ugly as it is not very portable, but is a valid solution.
   

[Dominator]

Hi GPIB Guru,

Thank you very much for your help.  The problem is gone.

I only follow your step 1 and step 4.  Do I still need Step 3?

But step 2 you suggest will not have viAddress reuse, unless I put the another while loop outside the viOpen and viClose. I rewrote my program to reproduce the viAddress recycle from other instrument for the test.

Loop

        For i = 1 to 3 //(3 instruments)

             viOpen(Res(i), &viAddress(i)

Until Error

Thanks again

[Dominator]

Hi GPIB Guru,

Thank you very much for your help.  The problem is gone.

I only follow your step 1 and step 4.  Do I still need Step 3?

But step 2 you suggest will not have viAddress reuse, unless I put the another while loop outside the viOpen and viClose. I rewrote my program to reproduce the viAddress recycle from other instrument for the test.

Loop

        For i = 1 to 3 //(3 instruments)

             viOpen(Res(i), &viAddress(i)

Until Error

Thanks again

[Dominator]

Hi GPIB Guru,

Thank you very much for your help.  The problem is gone.

I only follow your step 1 and step 4.  Do I still need Step 3?

But step 2 you suggest will not have viAddress reuse, unless I put the another while loop outside the viOpen and viClose. I rewrote my program to reproduce the viAddress recycle from other instrument for the test.

Loop

        For i = 1 to 3 //(3 instruments)

             viOpen(Res(i), &viAddress(i)

Until Error

Thanks again