Asking for *OPC? causes EADR error

[Ransu]

The story so far...

A program controlling several DVMs on a GPIB-bus queries OPC? at the end of a series of commands. The DVM's happily respond by executing the commands but before they are finished the card gives a general error: " GPIB Controller Not Addressed Correctly ". The problem is intermittant - not every call for OPC? results in the error - and running the same section of the problem again might work fine next time. The problem is consistent even when giving the program different DVM's from different manufacturer's to run.

On the error NI SPY gives this red line:

Receive(0, 0x0006, "", 511 (0x1FF), STEPend (0x100))   iberr: EADR (3)

I've checked that my CIC is the zero on the bus and all others have separate addresses.

In fact the program has run just fine on previous occations and never resulted in this error. What has changed though is that the computer running the program was updated recently from WIN2K to XP and consequently the NI-488-PCI drivers were also updated to the latest version (v.2.5). 

Reading the ISO 60448-2, it appears that none of the OPC? operations should result in a EADR error - especially when all other commands in the program manage to execute just fine without causing this error (which as I understand it, is most often caused by having the devices communicating which have the same address).

How would you propose I continue with troubleshooting the problem?

[Ransu · Accepted solution]

for the benefit of others...

Original cause of the problem was that the DMV had changed termination off on its own and had termination off by default and I didn't rerun the program back long enough to hit the right termination setting so resetting the DVM and rerunning the last set of measurements always led to the same situation. This should've been obvious when looking at NI-SPY more closely. The DVM kept sending the right measurement information to the bus but the PC card never finished reading it off the bus, finally timing out with the EADR error.

Meanwhile my troubleshooting created new problems. The new computer, an IBM Lenovo, had a flimsy PCI-card locking mechanism and the weight of the GPIB-connectors twisted both NI-GPIB-PCI cards off their slots, damaging one of them. After reseating the cards, one of them could only issue commands to the bus but did not receive corrently. I finally found the faulty card by swapping cards. The PCI-card locking mechanism is faulty by design and there is nothing one can do other than be careful with the pull you place of the GPIB-connector attached to it. I've now placed 8-Port GPIB Strips on the racks to make it easier to swap devices and troubleshoot faulty connections in the future.

I'm missing an analyser card for such situations. NI stopped making the PCMCIA-GPIB+ card and offer no USB with analyser feature as an alternative. The PCI-GPIB+ doens't help when you're having to troubleshooting several diffent racks all over the lab.

Sincerely

- Miikka Raninen, Finnish Airforces Materiel Command


Message Edited by Ransu on 02-21-2008 04:37 PM