GPIB ENET/ locks up randomly

[Steve_Steiner]

I have a setup that has Labview drivers and C language drivers that control seperate instruments in the setup. At random times the GPIB ENET/100 locks up, and I cannot do anything on the GPIB until I cycle power on the ENET/100. According to NISPY, the C drivers all open the GPIB connection to the instrument using ibdev, send the instrument commands, the closes the GPIB with ibonl. The labview drivers all seem to leave the connection to the instrument open until the driver is closed. Which way is better? Is this possibly the issue? I saw another post that said the ENET/100 would lock up if there were too many calls to ibdev. Is this true? If so, what is the limit? Is there a way to reset this? Any help would be great.

[Anna_M]

Hi Steve,

It is recommended to use ibdev (as opposed to ibfind).  What is the link to the post that discussed using this command too often?  Going to compare the NI-Spy captures is a great step.  Have you been able to take a look at what the last commands were to be sent before the lock-up occurs by pulling up the NI-SPY file after the lock-up? 

Also, if you run just the C-portion of the program or just the LabVIEW portion, do the lock-ups stop occuring?  This may help us to determine whether the differences in the NI-SPY capture between the different programs is affecting this behavior.  And, although the lock-ups are not consistent, how often would you say they happen?

[Steve_Steiner]

http://forums.ni.com/ni/board/message?board.id=140&message.id=24621 is the posting that referenced the interface being overloaded by ibdev calls.  The lock-ups occur about once a week during heavy use of the system. I have not been able to determine if it is the Labview portion or the C portion yet, because the system is in production use, and requires both. I will try to see if I can set up a system where I can try to isolate which type it occurs with or if it is both. I just started using NISPY and have not had a lockup occur yet. My NISPY observations were just during normal use. Because of the posting I referenced, I thought it may have been a clue to my problem, since the two methods accessed the GPIB in different ways. Is there a prefered way? Should the GPIB connection to the instrument be closed after each GPIB command, or left open for future commands, or does it matter? Thank you for your response.

Steve

[Brian F.]

Hello Steve.

The recommended way is to usually close the session when you are done using the instrument.  If you open and close a session everytime you want to perform a task, the program will be much slower due to the overhead in opening and closing the task.  This idea spans almost all of our drivers (ie DAQ, GPIB, DMMs, etc) using the open/acquire/close architecture.

However, depending on the number of calls that you are making at the same time, you may be required to close the session before opening another session.  A fairly good example of this is when you are using VISA, the high level API for the 488.2 driver.  A great way to troubleshoot this and find out the maximum sessions that can be opened at once can be found at the following website:

VISA Troubleshooting Wizard
http://www.ni.com/support/labview/visa/verr5.htm

This resource may or may not directly apply to the issue that you are seeing.  However, it does illustrate some limitations that may be causing the issue that you are seeing.  So, in order to find out more about what you are doing, how many instruments are you controlling in the LabVIEW portion of the app?  How many in the C portion?  Are you using the VISA API or are you using the lower level calls such as ibdev?  When you say that the use is heavy in the system when the device stops responding, can you quantify this?  Are you using more instruments, making more calls, increasing the frequency of the calls, etc? 

Please let me know and we will continue looking into this until we find a solution!

Brian F
Applications Engineer
National Instruments

[Steve_Steiner]

I have 16 GPIB instrument in the setup. 4 instruments are controlled by C language drivers, the rest are Labview drivers. All of the C drivers use the lower level ib calls. The Labview drivers are mixed using some lower level calls, some VISA calls. Each instrument has its own driver application running in the system. The application talks to these instrument drivers through pipes in the linux OS. These instrument drivers all run continuously in the OS waiting for a command to be received on the pipes and then passes them along on the GPIB. If these drivers that use the VISA API die, will the VISA session close automatically or will it remain open? If so, is there a way to clean up these open sessions that have no process tied to them?

Steve

[Steve_Steiner]

Based on the last posting, I investigated the possibility of closing open VISA sessions. I have made adjustments to all of my drivers to close the open VISA session before opening a new one, but it still locks up. My Labview drivers do not run with the GUIs on, so it will be difficult to perform the diagnostics requested. I will try to create a test version of my driver to see if I can verify if the number of VISA sessions is the problem. Any other suggestions would be appreciated.

Steve