NI-PXI-GPIB - communication - Change in data received compared to actual data

[Karthik_DP]

Hi,

We are using NI-PXI-GPIB card in one of our systems for interfacing with nearly 20 differently addressed instruments. The GPIB card is fit into a cPCI backplane, controlled by the Advantech cPCI Processor (MIC3358), which controls the full system. The GPIB driver Ver 2.4.0.3500 is installed for the GPIB card accessing. All the instruments are GPIB interfaced through GPIB IEEE 488 cables. During our testing with the Agilent Instrument Counter timer (53131A), the data that is displayed in the Instrument, is not received the same in the software. Eg : Actual value displayed:50442.7Hz, but Received value:0.0000504227Hz. We have also spied the GPIB commn using NI Spy software, where we could not trace what is the value received. We have carried out the following, but still this decimal point variation issue remains unsolved.

1. Replacement of the Counter timer (53131A) instrument with another of same model

2. Replacement of GPIB cable

3. Replacement of NI-PXI-GPIB card

FYI : The NI-GPIB pcb had the details as : ASSY183923H-01 DC1402 UL94V-0 183925C-01

[Dennis_Knutson]

Repeat your query with NI-SPY/Trace turned on. You need to attach it if you need help understanding the contents.

[Karthik_DP]

Here with, I am attaching the spied (NI Spy) data FYRef.

[Dennis_Knutson]

I'm sorry but in the image, I don't see where you are measuring frequency at all and in the captures, I don't see any values close to what you say you are reading. What is the code doing? Can you run some brief code where all you do is read the frequency? What happens when you execute the commands in MAX?

[JÞB]

A few things:  First make sure you have the range set right on the 53131A  Your response seams to be in GHz not Hz.

More importantly, 20 devices on one GPIB?  It might just work anyway but, this is in excess of the max number of devices the bus is designed to handle.  The fanout capabilities for the drivers limit the PHY layer to 14 devices and 20M of cable without a second bus or a bus expander.  The Handshaking line drivers of the devices might be getting stressed and may fail over time when operated in this high stress enviornment. This article offers sugestions on how to design large systems.

[Karthik_DP]

Better, shortly I will post the captured spy document. Pls. comment after that.

[Karthik_DP]

We carried out the same check for one more time. This time, we tried adding 1 sec delay and finally our issue itself got solved. The delay that was added between the final setting made in the counter timer and the data read from the same instrument had eliminated the issue. Still my worry is that our system was running good for the past 5 years, without any issue. How can then this software delay correction solve the issues???

Added to this, I have one more open issue, related to similar data read from a Microwave pulse counter Instrument (585C from Phase matrix). The Error is that during data read, the NI Spy shows that the correct data is read, whereas the captured data is not received, instead an error called EABO (iberr value 6) is displayed in the spy and a huge data value is printed. Pls. refer attachments for the relevant images captured. Pls. help me in sorting out this issue.

[Karthik_DP]

Can anybody go through the problem and sort out this EABO (iberr value 6) issue???

[Karthik_DP]

Is this an unsolvable issue or Is any more input required for sorting out this issue of EABO (iberr value 6)??

[JÞB]

---

@Karthik_DP wrote:

Is this an unsolvable issue or Is any more input required for sorting out this issue of EABO (iberr value 6)??

---

I do not believe this is unsolvable

BUT, ( and that is a large but,) we need a lot more information to help.  First, did you reduce your system to the IEEE-488 limits?  Specifically, what are the devices on the GPIB?  Can you reduce the issue to a specific software problem? (Have you tried replacing cables?)

As I stated earlier GPIB interfaces are only capable of sinking or sourcing a certain amount of current.  You have violated those specifications.  Damage to equipment from missuse would be high on my list of suspects if I were investigating this issue.  Race conditions on the bus would also be near the top of my list.  "Bad" or loose cables would rank high too.

Did this system ever work?  what devices are on the bus? can you post the code?

[EDIT] I re-read your posts and "It worked well for 5 years"  Yup, I strongly suspect that you may have damaged some of the GPIB hardware inside your equipment.   I have a basement that floods with heavy rains.  The house was designed poorly and I get to deal with the effects of poor architecture.  You may never find the crack missuse caused in this system.  (Why has it not been scheduled for review?)  What maintenance has been performed on the PXI Chassis?  Do all of those instruments have proper airflow?...   Yes, The system needs proper care and handeling - was that considered?