gpib hangs - any way to clear it programatically?

[fredette]

I have a test setup with an agilent power supply, tek scope, agilent function generator and agilent multimeter, all on gpib. I have the usb interface. My pc is xp, my program is c, very simple. It just issues ibwrt's and ibread's.

It runs for a long time (sometimes days), but eventually hangs. When it does hang, I can run the NI utility and see the gpib controller. But, scan for instruments times out and returns with none found.

I can free the gpib if I push the 'local' button on the power supply. Then everything works. The power supply is an agilent 3631.

I don't think there is anything wrong in my program. I think the power supply is jamming the gpib. Not sure what makes this happen.

Is there any way I can clear the gpib programatically? I mean other than pushing the 'local' button manually?

Any idea how to prevent the power supply from doing this?

mark

[Curt_C]

Hi,

On the 34001a meters you can use these diagnostic commands. Maybe they'll work with you power supply.

For some reason they're not listed in the user manual.

DIAG:LOCAL

and to get back to remote it's

DIAG:REMOTE

Hopes this helps

Curt

[fredette]

thanks Curt,

I think the commands you suggest are equivalent to ibloc() and maybe ibrem(). ibloc() does not get thru.

The problem is that the gpib seems to be hung in 'hardware' - I mean that commands don't go thru to the power supply or any of the other instruments. But, I can still talk to the gpib controller.

I was thinking maybe there is a way to clear the gpib from the controller without it having to get thru to any of the the instruments. Maybe like "ApplyHardReset" that would make the controller assert a reset line in the bus that would force the offending device(s) into a listen mode - to release the bus.

All this only makes sense if what is really happening is the device hanging the bus while in an illegal state (ie in the weeds). Which is what seems to me to be the case. Is it possible for this to happen on the gpib?

mark

[Curt_C]

Have you tried logging the gpib communication with NI-Spy?

Curt

[fredette]

thanks for following up on this Curt,

yes, I have tried Spy and InterActive Control.

Spy shows the commands but no responses. The gpib controller seems to have lost access to the gpib. None of the devices answer. I suspect they can't hear because the power supply has control of the bus and will not release it.

I had tried running Spy while my program runs, hoping to see if there is a particular command that causes the bus to hang. But, I have not captured this. I don't think it will help too much, though. The program runs will hour after hour, more than 2000 loops without hanging. Each loop probably has several hundred gpib transactions.

I have no idea why it decides to hang up sometimes. Maybe a windows thing. And, it seems very hard to find.

That's why I was hoping there is a HardReset command. If it happens, I'll just issue that and continue.

I tried the command iblines, which seemed to work and I think returned the state of the lines in the bus. I got [52ff].

mark

[Curt_C]

Have you tried writing a quick app using just the power supply to test the setup?

If you get stuck, use the power supply connected to a serial port and use Visa.

Curt

[smercurio_fc]

I'm not sure why you'd think it's a "Windows thing" if it appears that the power supply is hanging the bus. What does Windows have to do with the GPIB bus? Your iblines return value indicates that the bytes were accepted by the listener. You could try the ibclr command, but if there's a hardware problem I doubt this will help. Have you tried to replace the power supply, since you seem to have zeroed in on the likely culprit. Maybe you have a bad power supply.

[Curt_C · Accepted solution]

Post some of your source code, maybe there's something somebody else will see that's causing a problem.

Curt

[RayFarmer]

Not sure how Curt has solved this query, I see no source code or any solution that has fixed the problem!!!!

[fredette]

Thanks for paying attention. I basically marked the issue as solved to stop discussions. I don't think there is any problem with the source code because it runs through so many loops before it hangs. And, in fact, program itself does not hang - it's the gpib that gets captured by the agilent power supply. So, I did not want to bother anyone with reading the code.

I was really just looking for a way to clear the gpib from inside my program. I was thinking there is a command that I can send to the gpib controller that activates a reset line that makes any (all) devices release the bus. Since the bus itself is captured and blocked by a device, I cannot send commands to that device to have it release the bus, I have to issue a 'hard' reset. This would be equivalent to what I do now by pressing the 'local' button on the front panel of the power supply. Note that when I do this, everything works - I do not have to restart my program.

So, here is are the basics of my problem...

1. the program runs for a long time, thousands of loops

2. when the system hangs, i cannot see any of the devices on the gpib, i can see the controller just fine

3. if i press 'local' on the agilent supply, everything comes back to life

mark