GPIB device (HP 8560e) does not respond

[Improbability]

I have 6 devices connected on GPIB which I control using C/C++ drivers that I made to tie into the NI GPIB drivers provided. I use the scripting language Tcl to control the C/C++ drivers which adds an amazing amount of flexibility to my system.

Every device is fully functional with C/C++ and with the Tcl as the top level controlling language.

This is where my problem starts. I decided to add in the convenience of having my C/C++ code find what devices were at what addresses. It uses the FindLstn command and queries the addresses with listeners with the "*IDN?;" command. Not all my devices respond to this. The HP 8560e doesn't respond to this as well as my HP 11713a doesn't either. Both I believe are around 20 years old and have the HP-IB syntax.

I think I'm missing something fairly critical but I don't have the experience to identify what I'm missing.

I have attached 3 Spy files.

"MAX (Working)": This file contains the setup done by MAX when you ask it to scan for devices and at the end I sent a query to my problematic device.

"Tcl (Working)": This file contains the setup with Tcl that simply opens the devices. At the end I sent a query to my problematic device.

"Tcl (NOT Working)": This file contains my setup queries to find the listeners and open the devices. At the end I attempt to send a query to my problematic device but the request times out.

[Dennis_Knutson]

Your instrument manuals will tell you whether the *IDN? command is supported or not. Prior to IEEE-488.2, an instrument could use anything or nothing.

[Improbability]

It doens't support it...but that's not the issue.

The issue is some GPIB command (or lack there of) is killing my communications with the device. I just don't know which.

The functions I don't use in my opinion don't seem to be of any real importance but I'm hoping someone will say otherwise. The reason I don't have them implemented is due to my inability to determine where GPIB0 comes from when passed to the function ibfind(). It seems to be the value returned by ibdev()

ibconfig() seems sort of redundant in my mind though since i think ibdev() takes care of all that stuff anyways? I think?

[Dennis_Knutson]

Then I am confused as to the actual issue. Both the TCL spy captures just have a IBFIND command.

[Improbability]

Basically when I use MAX to find the devices on the bus, I have full communication with the devices. But when I use TCL to find the devices on the bus, I'm locked out from communicating with that HP 8560e device on address 6.

The TCL (Working) spy file I provided was intended to show that it is possible in TCL to communicate with the device.

[Steven_T]

Hello Improbability,

You have both captures already.  My recommendation is to make the capture using your TCL look exactly like the MAX capture (which works correctly).  My guess is that the instrument at address 6 is unable to process the command "*IDN?;", but can respond to "*IDN?". 

Try to make the captures look the same and let us know what fixed it. 

On a side note, I noticed that at the end of the TCL captures, you open a reference to each instrument and use SendIFC on the bus.  There is no need to do this.  SendIFC sends IFC to the entire bus.  So you are performing this operation 5 times, when it could only be performed once.  Also, when using ibdev or ibfind, a handle is opened.  These handles should be closed at the end of your program using ibonl.

Thanks,

Steven T.

[Improbability]

Thanks Steven for the input. The device doesn't respond to "*IDN?" or "*IDN?;" but I don't think that's the issue. I think you're on the right track with the ibfind handle still being open. As for the multiple SendIFC commands, that's just one of the tradeoff's between flexibility and inefficiency I can live with I guess. I'll give your suggestions a try and let you know the outcome.