Detecting power off of remote ENET/100

[bicycle]

ibfind(gpib0) works if the ENET is on, but hangs if it is off.

It appears that embedded deeply in the NI488.2 software is the assumption that the remote ENET is always reachable through the network, and thus NI subroutines will wait forever for a response. This is BAD design and an update is called for. Please escalate the issue.

[bicycle]

Further speculation:

When the GPIB-ENET was designed it was building upon a design in which the board and the computer were initmately connected. If the power fails on an internal GPIB board, well the computer is also toast anyway, so who cares! But in a networked environment there are some new variables as well as the many new possibilities which attracted me to the ENET. For example, I may have a number of the controllers in various buildings, all of which may be accessed by a number of clients. In a distributed environment like this, networks can go down due on-the-fly modifications, circuit breakers popping, management of network cables, user or administrative error, etc.

It appears that a TCP/IP transport replaces PCI bus communication at the NI-488.2 driver level, but with insufficient allowance for the nature of distributed computing.

A mechanism for recovering from an unanticipated break in the TCP/IP transport mechanism is essential if a robust multi-point service is to be provided. If I get an error, I can try to re-establish communication with the controller in an orderly way, while continuing to service the other controllers which remain accessible.

Pinging a remote device checks that it is accessible at that moment, but this does not ensure that communication with the remote controller won't fail immediately thereafter and lead to a hang in the administering software. Thus it is insufficient for a robust solution. The drivers are at fault.

In particular,
(1) the timeouts which appear to be implemented in the remote ENET device need to be implemented in the local driver as well to avoid a permanent hang waiting for a never-to-be received response.
(2) the integrity of the TCP/IP connection should be checked before sending packets.
(3) Standard TCP/IP communication errors need to be acknowledged and if necessary, reported to the user.

This should not be so difficult for those who have access to the source code if they understand the TCP/IP protocols they are relying on.

[Sarah_R]

bicycle,

From the experiments that we have run, using ibfind at the beginning of the program will detect if a GPIB-ENET/100 connected and powered.  Since your program is hanging if you try to use an open handle to the device or board, you could use ibfind to detect if the GPIB-ENET/100 is still on the network.  This would be especially useful if it has been a while since your last GPIB communication.  

So, you can open a handle to the instrument using ibdev and use it throughout your program.  However each time you detect that it has been a while since the last GPIB communication (this threshold can be set by you), you should use ibfind to see if the GPIB-ENET/100 is online before running the call.  Be sure to close your opened handles if ibfind is successful (if the ENET/100 is on the network) using ibonl.

R&D will be looking into this issue.  We hope to reproduce the problem that you are seeing on your computer.

Thank you for your patience.

[Sarah_R]

bicycle,

R&D has looked into this issue. It was found that it could take up to 10 minutes to timeout, but it does eventually timeout and will give you the EDVR error.

Sorry for the inconvenience.

[bicycle]

You are correct - the timeout is around 9 minutes. Unfortunately, I can't leave process control and the GUI stuck for that long. I'll see what I can come up with on my own. Would be nice if the timeout could be reduced or modifiable.

For anyone reading this thread and wants a hack, you can get the IP address to GPIBn mapping by parsing the file /Library/Preferences/GPIB.INI (not that you should have to). As I mentioned earlier, the fact you can ping it doesn't mean the network couldn't fail by the time you do the NI488 call.

[Sarah_R]

bicycle,

You are always welcome to submit a product suggestion at Contact NI and go to the Product Feedback section.

Thanks