Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

GPIB-ENET Converter locks up - improper setup/teardown?

Hi - I just joined this forum and it looks really helpful - hopefully I can eventually contribute too... 

 

I’m currently working on a VisualBasic.NET project that polls various groundstation equipment for their status using the 488.2 GPIB routines. I’m running into an error after my program has executed for some time and then I try to re-run it again. Somehow the GPIB-ENET converter locks up into an error state and the only way to remotely control it again is to manually toggle its power. The GPIB failure is either EHDL or EDVR and can be detected with the troubleshooting wizard.

 

Given the nature of when this occurs, I think I’m either not setting up or closing the converter properly. Here’s the series of commands I’m using. Can someone look this over and tell me if I should be setting up or tearing down the connections a certain way?

 

SendIFC() // a few times, as there are a couple converters
DevClear() // a few times, as there are multiple instruments per converter
For each device over a long period of time{
        Send()
        (sometimes I call ibdev and ibwait at this point so that I know when the response is ready)
        Receive()
}
(am I supposed to be ending the connection somehow at this point? I’ve seen example code that takes the device offline with ibonl, but I don’t want to call that if it will interfere with a separate program that is also using the devices)

 

The error is inconsistent and hard to replicate, so any advice would be helpful. Thanks so much!

 

Shane

0 Kudos
Message 1 of 7
(3,831 Views)

Hi Shane,

 

The errors you are describing are documented in the GPIB Error Codes and Common Solutions (Part 3). The errors could be related to either an invalid input handle to the GPIB instrument or the GPIB hardware might not configured properly.

 

Are any of the instruments getting powered down while the program is running?
What version of NI 488.2 and NI-VISA do you have installed?
Have you tried running an example to verify all the hardware is configured correctly, if so what were the results?
The ENET should be the only controller in charge on the GPIB bus, how are two programs accessing the instruments at the same time?

 

Regards,

Andy L.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 7
(3,807 Views)

Hi Andy - I appreciate your help. To answer your questions:

 

No instruments are powered down.

Version of 488.2 is 1.7...pretty old i'm beginning to learn. I'm not using VISA (i don't think..unless it's used by 488.2 somehow)

We've used other software, and everything seems to be working. I'm pretty sure it's my software that's causing issues.

I'm not sure how the other program works, but I think it's unrelated to this issue because we've seen this error when it was closed.

 

I spent lots of time today looking through these forums, and I've learned a lot. I've found some related posts about the converter locking up here and here, unfortunately they both don't appear to have solved the issue.

 

But I did uncover that the converter may lock up with >1024 calls to ibdev without closing the handle with ibonl. This could be happening in my application so I'll do further testing from that aspect. I also saw that newer firmware fixes another issue where the converter was locked up after some time.

 

So I think i'm going to try to stop calling ibdev whenever I want to get a handle so that I can wait on a response.  I'll also look into updating the drivers to 2.5 and the firmware to C9. And if it happens again I now know that I can pull an error code from the lights on the converter to further help diagnose the problem (this i'm very curious to see, because when the problem happened I always remember a solid red light, nothing flashing).

 

Do you think I'm on the right track? I have limited time with the equipment, and it's not available right now, so I'm just trying to gather as much ammunition as I can to make my time as efficient as possible.

 

In the meantime, I am also a little curious about whether I should be using ibdev and ib/ilwrite or just Send instead. Right now I'm mainly using Send by itself. Should I be calling ibdev before I call Send? Or does ibdev just create a handle for the other calls?

0 Kudos
Message 3 of 7
(3,803 Views)

Hi Shane,

 

The IBDEV function is used to open and initialize an unused device when the device name is unknown. If you know the device name I would recommend using the ibwrite function to write to the instrument using the instrument address. 

 

Regards,

Andy L.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 7
(3,767 Views)

Hi Shane,

 

I was thinking about your question and you should use ibonl to close every open handle when it is no longer used.  The use of ibonl is like a close.  It will only affect other threads if they try to use the descriptor that was closed without reopening it.

 

Regards,

Andy L.
Applications Engineer
National Instruments
0 Kudos
Message 5 of 7
(3,701 Views)

Thanks, Andy -

 

I've gathered several new approaches to try and will attempt the fixes in a couple weeks when I have access to the equipment. I'll update this thread with the results.

 

Thanks for your help!

Shane

0 Kudos
Message 6 of 7
(3,699 Views)

I wanted to post an update, as the issue has been resolved. It turns out that the problem did have to do with calling ibdev too many times without closing the handle. After exactly 147 calls, the converter consistently locked up and would need to be manually reset. I now open one ibdev at the beginning of the program and close it on program termination, instead of opening one every time I want to send it a message.

 

I also experimented between using Send and ibwrite, and ibwrite appears almost 2 times as fast. I will be replacing all of my send/receive calls with ibwrite/ibread calls.

 

Thanks!

Shane

0 Kudos
Message 7 of 7
(3,589 Views)