Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 29 Jan 2008 13:59:21 +0100

On Tuesday 29 January 2008 11:20, Dirk Zimoch wrote:
> Hi Ben,
>
> Please try to modify AsynDriverInterface.cc like this:
>
>  From lockRequest(unsigned long lockTimeout_ms) remove
>
>      if (!lockTimeout_ms)
>      {
>          if (!connectToAsynPort()) return false;
>      }
>
> And modify lockHandler():
>
> void AsynDriverInterface::
> lockHandler()
> {
>      int connected;
>      debug("AsynDriverInterface::lockHandler(%s)\n",
>          clientName());
>      pasynManager->blockProcessCallback(pasynUser, false);
>      connected = connectToAsynPort();
>      lockCallback(connected ? StreamIoSuccess : StreamIoFault);
> }
>
> Does this work?

No, the behaviour is the same as before, which I found is in fact quite 
predictable: The first time the E5810 reboots, the IOC will re-connect 
fine. The second time, it won't. Also, I found that when it doesn't 
re-connect, the last message is

2008/01/29 12:57:54.509 gpib0 vxiCreateDeviceLink abort channel TCP port 
changed from 1002 to 1005

while in case it /does/ re-connect, this message is followed by a similar 
one:

2008/01/29 12:57:22.225 gpib0 vxiCreateDeviceLink abort channel TCP port 
changed from 1002 to 1005
2008/01/29 12:57:22.231 gpib0,20 vxiCreateDeviceLink abort channel TCP port 
changed from 1002 to 1005

Also, in those cases where I can cause re-connect to happen by issuing e.g.

  asynSetTraceMask L3 20 0x0000

I get the 'missing' second message immediately afterwards:

epics> asynSetTraceMask ${GPIB_LINK} ${GPIB_ADDR} 0x0000                        
epics> 2008/01/29 13:35:59.379 gpib0,20 vxiCreateDeviceLink abort channel 
TCP port changed from 986 to 1005

Maybe this could be a hint to what's going wrong?

 ***

I said "in those cases where I can cause re-connect to happen..." because 
when today I checked the IOC in the morning, there was /no/ way I could 
convince the IOC to re-connect. I had to re-start it. OTOH, I cannot 
completely rule out the possibility that someone (or something) restarted 
the IOC while the E5810 was off, which would, I think, mean that 
asyn/vxi-11 never created a connection in the first place.

Anyway, we are now focussing on how to restart soft IOCs from the iocsh, so 
that we have at least a fallback inplace.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System