Difference programmatically between NI GPIB-PCI and NI GPIB-USB-HS?

[JPIBer]

Hello all,

I am writing an application that accesses some GPIB equipment. On my development machine I have an NI GPIB-USB-HS connection and that is working just fine. On my first test machine I have a NI GPIB-PCI connection. The app seems to have a problem when sending commands to the GPIB over the PCI connection.

Using MAX on the test machine I can connect to the equipment and send commands over the PCI connection with no issues. Both the USB connection on my development machine and the PCI connection on the test machine are address 0.  The addresses of the GPIB equipment in both scenarios are the same, 4 and 12.

Because I am able to send commands through MAX on the test machine with the PCI connection, I am guessing I do not have a faulty hardware issue. I did try replacing the PCI connection on the test machine with another GPIB-USB-HS but my app is still not able to send commands to the GPIB equipment. But, through MAX I am able to send commands to the GPIB equipment over the new connection.

I was thinking there was some kind of difference needed in the code to use the PCI connection, but the behavior of the USB replacement has me confused.

Any ideas?

[Minions]

If both interfaces are on the same machine, then it is an issue in your code sending across the GPIB.  In MAX, it assigns GPIB0 (default) for the first interface and GPIB1 for the next.  If you do not specify which bus is to control in your code, it will default to GPIB0.

GPIB1::4::INSTR

[JPIBer]

They are not both on the same machine. One each machine the interface is GPIB0.

[Minions]

Simple questions to further understand your setup.

When you tested the first working interface to the equipment, was the second removed?  Likewise, when testing the second interface, was the first removed?

[JPIBer · Accepted solution]

Yes they were completely isolated.

I am getting a sinking feeling that there is no difference in the interfaces from a programming perspective. That means I have a different problem that will be trouble to find.  I appreciate the help though.

[Albert.Geven]

Maybe you have a speed problem. Officially it is a handshaked bus so that should not occur, but sometimes it does.

Do you have old instruments or brand new ones?

[hwalke]

I have a similar problem where I am getting different behavior between the PCI and USB-HS adapters. PCI works fine with my application but the USB adapter is giving me trouble.

[AndersGustafsson]

Does anyone know if it is at all possible to get more detailed error info from the NI USB GPIB adapter? That EBUS error is not very descriptive and can mean a plethora of things. The issue hwalker sees is that we have a NI PCI card talking to a Prologix-compatible device and all works fine, even reconfiguring the Prologix-compatible device. With the NI USB adapter though, the NI adapter will lose contact with the prologix-compatible device if you issue any ++command, even a ++ver that does nothing but returns the FW version.

Does anyone know in what way the USB adapter differs from the PCI one. I had assumed that they both had similar GPIB circuitry.

[TimothyDug]

Hi hwalke and AndersGustaffson,

I would suggest making a new post to get more traffic to this post, since this post is 7 months old, however I will attempt to help as best as I can!

---

hwalke,

1. how is the USB Adapter giving you trouble?

2. Can you try a different USB port?

3. Which Operating System are you running?

4. How are you interfacing with the PCI and USB-HS adapters? Are you using NI MAX? Some other program?

---

AndersGustafsson,

Can you look here and scroll down to the EBUS section. Does that shine any light on the EBUS error you are seeing?

As far as differences, I'm not aware of any ways that the USB and PCI adapters should differ.

Thanks!

[AndersGustafsson]

Sorry, no. I already read that page. Problem is that the unit that we are communicating with implements GPIB entirely in a microcontroller. I am sure that there are subtle differences in GPIB that causes this, but then again are there differences even among HP instruments. That particular code/solution works fine for emulating devices such as printers and plotters and also for emulating mass storage via the Amigo and CS/80 protocols, but then again does Amigo/CS/80 vilolate the 488-spec 🙂

The EBUS error is really a catch-all for a number of possible bus errors that can be reported by the NI CPIB Chips.

Anyway, I have an NI USB adapter enroute so I will investigate further.

[TimothyDug]

AndersGustafsson,

Just to be clear, you have installed our 488.2 drivers, right?

Also, the USB and PCI form factors will perform similarly for most normal DAQ applications. However, for very high speed applications or situations where synchronization timing is very critical, I would recommend the PCI or PCIe form factors over usb, just because the USB interface introduces more latency. So, I wonder if this could be related to the source of this EBUS error?

Let me know what results from your investigation!

Thanks!

[hwalke]

Yes we have the 488.2 drivers installed. Performing "similarly" is debatable. We do not need a recommendation on a new adapter we need to know why the PCI adapter works perfectly fine with the same code and the USB adapter fails after a simple version check (it communicates fully before). We have tried extending the timeout to the longest possible settings in NI Max and it still times out. There is definitely a difference between PCI and USB adapters that is VERY clear since someone else has encountered the same type of problem (original poster). Anders and I have been testing this for months now.

[AndersGustafsson]

Yes, drivers are in place. This is not a very high-speed application, quite the contrary. The purpose is to send simple commands to a device for configuration. I am aware of the latency issues with USB, but they should not play in here as the problems seem to happen on the GPIB side.

As a developer, I am less interested in "who's fault is it". What I want to find out is simply "why" so we can fix it. The PCI card has let us sort out several wrinkles where the NI Card /Software would act differently from say a HP 3852. Not "incorrectly" just differently.

Thing is that there is zero bus activity when we reconfigure at our end. Still does the NI USB adapter drop the connection. Odd..

[PowayBob]

Any progress here or enlightening discoveries?   I too want to understand this better so it can be fixed or prevented.

For my case the GPIB-USB-HS is the one that works.  GPIB-PCI and GPIB-USB-HS+ are the ones that stop working with the same application.  Occurs about once per day.

The frequency of the hardware hang-up improved when going from 5m to 3m cable.

[Albert.Geven]

Do you mean improved that is hangs faster or improved that it hangs later?

Or maybe a better question, did you play with the bus speed, by making it slower to improve the system by making it more robust although a bit slower?

[PowayBob]

Going with the shorter GPIB cable made the hang-up less frequent.  This is better as expected with a shorter cable.

Do you have experience with slowing down the bus speed?

In a controlled experiment, we made the bus speed faster from the default of 500 nsec to 350nsec to try to induce the hang-up.  This was inconclusive.

Unfortunately, at the customer site they ran out of patience and cannot risk production volume so we have not been able to try making it slower (2 usec).  This semiconductor manufacturer now requires that all hardware used is the GPIB-USB-HS because there is no problem.

Our goal and current production plan is to use the GPIB-PCI hardware.  This avoids the potential issues with overloading the serial bus of the USB.  However, the GPIB-PCI also exhibits the same hardware hang-up.

Note:  The device on the other end is a National Instruments STS GP3 tester.

[Albert.Geven]

Hi

I do have experience in that it really helps for older instruments. Ringing on the bus should be less with long cables and most of the older instruments don't react fast enough to see any difference in speed.

I don't know the instrument from NI but that should accept high speed normally, but give it a try and watch the speed in a test. You probably will be limited by the instrument more than the bus.