Experimental Physics and
Industrial Control System

William Lu <[email protected]> · Thu, 02 Dec 2010 16:17:34 -0500

I think that that would be a useful option. Actually I may prefer a
dedicated function for locking and one for unlocking. That way, users
can lock the devices for a certain period of time.
Thanks,
William
Eric Norum wrote:

Great. Thanks for testing thig.
1) Should we make this an option to the vxi11Configure command?
	Pro: Allows locking to be controlled
	Con: But only on a fairly coarse granulatiry and that command already has a lot of arguments to keep track of.
2) I can't explain why terminating the program with a ^C would leave the socket in any different state than terminating the program with an explicit exit. As far as I know the VXI-11 driver installs no 'atexit' handler to do anything special so the socket should end up getting closed by the kernel in either case.
On Dec 2, 2010, at 12:35 PM, William Lu wrote:

I set the crLinkP.lockDevice to 1 as Eric suggested, and it does the trick! My ioc locked the devices exclusively.
Additional findings:
1, the ICS 8065 Ethernet-GPIB controller has a configurable timeout for the communications with the TCP/IP clients. If the ioc does not communicate with any GPIB devices for the timeout amount of time, the 8065 will release all locks created by the ioc.
2, if the ioc is terminated by the iocshell "exit" command, the 8065 does not release the locks created by the ioc until the communication timeout expires.
3, if the ioc is terminated by ctrl-c in the iocshell, the 8065 releases the locks created by the ioc immediately. It seems that the ioc upon "exit" does not unlock the links nor close the sockets, whereas ctrl-c at least does one of them.
Thank you Eric and Mark for your help.
Best regards,

William

--
Weiwei Lu
757-269-7476
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System