03-12-2014 06:17 PM - edited 03-12-2014 06:25 PM
Hi,
I would greatly appreciate any help with this issue and I will provide any extra information I have missed.
Hardware setup: There is a computer (XP Professional SP 3) with a PCI-GPIB board (driver 3.1.0.49152) installed. This computer has been used for years with three GPIB instruments connected. Cable lengths are short and cables are in good condition.
Problem onset: With no warning, GPIB communication via a LV program dropped out completely today. No changes were made to the computer's software, but two of the instruments had been disconnected to run a newer LV program that only talks to one instrument. The two unused instruments were disconnected in such a way as to leave only a direct link between the PC and the sole GPIB device with no dangling cables or attached and inactive devices. After the new software was run a few times successfully, the GPIB cables were connected to all three instruments. The old software was run with the three instruments once successfully, and GPIB communication failed when it was run a second time.
Steps taken so far: I have restarted the computer, power cycled the instruments, and limited my troubleshooting to get one GPIB insturment connected directly to the computer. I am using NI MAX (5.5.0f0) and whereas both NI MAX and Windows Device Manager can see the PCI-GPIB board, no instruments are shown when I select "Scan For Instruments".
I have also run the NI-488.2 Troubleshooting Utility several times, testing Software and GPIB0, and they always pass.
I should note that there is something I have not been able to find an explanation for: As soon as I select "Scan for Instruments" the message "There was an error performing the instrument scan" appears in the Connected Instruments pane. The message appears instantly, which might suggest an issue with the board configuration. Given this, I turned to ibic.exe and began following this document:
http://www.ni.com/support/gpib/max/ibic.htm
It suggests some initial troubleshooting steps, which I followed. I know for a fact that the GPIB address of the sole device connected to the PCI-GPIB board is 2. This is after a fresh restart and power cycling the device. Note the ECIC error.
At this point I am at a loss, since:
Apart from resolving my issue, I am looking for help with the following:
Thank you in advance.
Paul
03-12-2014 06:24 PM
03-12-2014 07:16 PM
I wasn't the one making the switchover, but it is a very real possibility that the instruments were not powered down before disconnecting the cables.
I would rather keep the 'damaged board' alternative on hold for now unless there is a better way of diagnosing the board's health other than with the Troubleshooting Utility (a test that the board did pass). The reason is, I do not know of a method to prove or disprove this hypothesis or to investigate it further, so it's a bit of a dead end for now.
03-12-2014 07:21 PM
Some additional information, two points.
1) A very similar issue occurred on another computer with the same set of three devices connected. I couldn't for the life of me get one of the devices talking to the GPIB board again (it is old and noncompliant to the standard (Burleigh WA-1000 wavemeter), so who knows what was going on with it. I can confirm that eventually the right combination of restarts and power cycles occurred, and I was able to talk to the instruments again. Point 2) below is taken from this computer, so this suggests that this error is reversible and probably not a result of a dead board.
2) This is what NI MAX looks like on a different computer with the same setup and with a functional pair of devices attached. Yes, both responses are normal for the devices.
03-13-2014 12:16 PM
I would like to offer some additional information.
I found this forum post, where someone had a similar situation. A knowledgeable user posted the following:
The fact the ATN is already asserted on the bus is the concern. If you have another controller on the system (is the other GPIB board still connected?) that is asserting ATN, that will prevent the NI board from being the active controller in charge. This in turn will prevent the NI board from being able to detect device on the bus.
The ATN could be asserted for a number of reasons, such as:
1) Another system controller is on the bus that is driving ATN high.
2) You have a cable problem that is shorting the ATN line.
3) Your cable is upside down (?) so the lines are misconnected. Typically this cannot happen as cables are keyed, but I have seen this before with an instrument that had the connector keying removed.
4) The GPIB board has a problem
If you
disconnect the cable from the GPIB board (the NI board) and relaunch ibic and try the first four commands again and you get the same result, I would think you have a defective board. If instead of 0110 for the status you get 0130 than the board is likely working find and you have another device on the bus asserting ATN. If so, disconnect each device from the bus until you determine which device is asserting ATN.
I restarted the computer, disconnected the cable from the board, and ran ibic.exe:
As you can see, ATN is asserted even with no cable connected. Per the user's information, it would seem like there is a hardware issue. Could someone with experience confirm this interpretation?
Thank you!
03-13-2014 02:19 PM
03-18-2014 04:58 PM
Thank you, Dennis. I took an alternate route and removed GPIB communication from our program completely, opting instead for USB with a newer device. The company has been wanting to move away from it for quite a while now, and this turned out to be a useful incentive to get this part of the task done at least.
Thanks again for your input!