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

[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.