iblck release after computer crash or network failure

[Tom-NG]

We are controlling equipment using ENET/1000 devices. The controlling computer has a redundant computer in case the primary fails. We use iblck to protect the bus when the equipment is under active control and need to restore service quickly if the computer fails. We have confirmed that the ENET/1000 does retain the lock after a failure however have not tested the duration of the timeout. How long does an ENET/1000 maintain a lock after it looses connection to the requesting thread and can this timeout be managed in any way?

[Tom-NG]

Additional information. The retained lock in the ENET/1000 is plocking the redundant computer from gaining access to the equipment until the failed connection finally timeouts in the ENET and the ENET releases the lock. Having to wait for the timeout is disruptive. Again we are seeking if the failed link lock timeout is consistent in behavior and also if the duration can be controlled. Thanks, Tom

[Spicy_Mystery]

Hi Tom-NG,

It sounds like your ENET/1000 and iblck are not cutting the lock after your computer crashes.  The best way to approach this seems to be to use some error handling that enables iblck to cut the connection when the computer crashes, rather than hoping it will cut the lock when the computer crashes.  Is there a way to tell whether the computer has crashed or not, and then control iblck from that?

[Tom-NG]

Error handling won't work in this case, unless there is something I missed in the documentation. Only the process/thread that issued the IBLCK to an ENET/1000 can release it. If the computer that crashes is the one that issued the IBLCK, then there is no error handling that can be done. Note we simulated the computer hard crashing by shutting down the network interface which effectively silently severs the connection to the ENET/1000 from that computer. When we start the application up on the backup computer we cannot start utilizing the ENET/1000 bus until the ENET releases the previous lock from the crashed computer. According to the NI 488.2 driver manual, only the thread issueing the IBLCK can release it. Since that computer effectively hard crashed, there is no way to clear the IBLCK from a command since that thread is gone. I see no error handling that can capture this. We appear to be at the mercy of the ENET/1000 to release the lock. So we are looking to understand if that timeout is consistent, what the duration is, and is there any way to modify the timeout? Thanks for your response, Tom

[Spicy_Mystery]

Hi Tom-NG,

Unfortunately I can't find any information about when it releases iblck.  According to this KnowledgeBase article ( http://digital.ni.com/public.nsf/allkb/52C6008A5BE5C33686256FF2006FB00F ). the only way to release it is from the machine that originally started the lock, and I wouldn't expect that the machine crashing would necessarily break the lock.  This seems like a problem inherent to the protocol that won't have a good answer, other than using a different protocol.

[Tom-NG]

Julian, Thanks for the info, I had found and reviewed that KB article. Unfortunately the NI 488.2 driver to ENET/1000 protocol is private to NI with no public access. I was hoping there may be some undocumented parameter in the gpib.ini file that would allow some control over the ENET/1000 TCP connection timeout, or at least something specifying what the expected duration would be. We will have to characterize the behavior in house and determine if it is acceptable or if we have to forego the protection of the IBLCK. Our implimentation is pretty much limited to the ENET/1000 solution so no other protocol is going to be available other than to not use IBLCK or live with the unavailability of the ENET until the lock releases (or power cycling the ENET which will not always be possible) Thanks for looking into this, Tom