04-05-2017 06:42 AM
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?
Solved! Go to Solution.
04-05-2017 06:57 AM
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
04-05-2017 07:21 AM
They are not both on the same machine. One each machine the interface is GPIB0.
04-05-2017 07:34 AM
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?
04-05-2017 08:38 AM
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.
04-05-2017 03:09 PM
11-27-2017 02:11 PM - edited 11-27-2017 02:12 PM
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.
11-28-2017 06:16 AM
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.
11-28-2017 12:16 PM
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!
11-29-2017 05:03 AM
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.