1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: PMAC asyn autoconnect issue |
From: | Bruno Martins <[email protected]> |
To: | Mark Rivers <[email protected]> |
Cc: | "[email protected]" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Mon, 12 Feb 2018 14:45:19 -0500 |
Hi Bruno,
I think your startup script contains this command, correct?
pmacAsynIPConfigure(portName, hostInfo)
This means that the pmac driver is not directly communicating with the drvAsynIPPort driver supplied with asyn. It is talking to the port created with the above command, which implements the asynInterposeInterface between the pmac motor driver and the underlying drvAsynIPPort driver. I have not studied that code carefully, but it is possible that it is doing something to prevent the reconnect feature from working correctly.
I have tested the asyn autoreconnect feature quite a bit recently, when I was trying to reduce the number of error messages that are printed when a device is powered off and then back on again. For example, look at the Modbus R2-10 release notes:
http://cars9.uchicago.edu/
software/epics/ modbusReleaseNotes.html
Mark
From: [email protected] [mailto:tech-talk-bounces@aps.
anl.gov ] On Behalf Of Mark Rivers
Sent: Monday, February 12, 2018 12:10 PM
To: 'Bruno Martins' <[email protected]>; [email protected]
Cc: [email protected]
Subject: RE: PMAC asyn autoconnect issue
Hi Bruno,
What version of asyn are you using?
What version of tpmac are you using?
Ø 2018/02/12 12:00:14.826 pmacController::
lowLevelWriteRead: Error from pasynOctetSyncIO->writeRead. command: #2 ? F P
2018/02/12 12:00:14.826 drvPmacAxisGetStatus: not all status values returned. Status: 3
Command :#2 ? F P
Note that Status: 3 is asynError, not asynDisconnected.
Are you sure that asyn really thinks the port is disconnected at this time? You should run asynReport on that port to see whether asyn thinks it is disconnected or not.
One problem is that when you power-off an IP device on Linux it takes quite a while before the OS decides the socket is disconnected. Before that time it returns an error like “Resource temporarily unavailable”. During this time asyn will not try to reconnect, because it thinks it is still connected.
This behavior is one reason that the drvAsynIPPort driver was enhanced in R4-29 to support the disconnectOnReadTimeout option. If this option is enabled then the port will automatically disconnect whenever there is a read timeout.
Mark
From: [email protected] [mailto:tech-talk-bounces@aps.
anl.gov ] On Behalf Of Bruno Martins
Sent: Monday, February 12, 2018 11:34 AM
To: [email protected]
Cc: [email protected]
Subject: PMAC asyn autoconnect issue
Hi,
I've been investigating an issue with the PMAC driver regarding reconnection via Ethernet. When the controller is powered off the IOC starts emitting messages like the following (as expected):
2018/02/12 12:00:14.826 pmacController::lowLevelWriteRead: Error from pasynOctetSyncIO->writeRead. command: #2 ? F P
2018/02/12 12:00:14.826 drvPmacAxisGetStatus: not all status values returned. Status: 3
Command :#2 ? F P
However, when the controller is powered on again, the IOC does not re-establish the connection (even though noAutoConnect is set to zero).
This is the sequence of calls that lead to these messages:
lowLevelWriteRead calls pasynOctetSyncIO->writeRead
pasynOctetSyncIO->writeRead calls pasynManager->queueLockPortpasynManager->queueLockPort calls pasynManager->queueRequest
queueRequest sets checkPortConnect = TRUE
Since the port is disconnected, queueRequest returns an error
https://github.com/epics-modules/asyn/blob/ 87e784335736de782980b7600bd7d6 e42179511a/asyn/asynDriver/ asynManager.c#L1505 If checkPortConnected was FALSE autoConnectDevice would be called later on and a new connection would be attempted. But for this particular call chain checkPortConnected is always set to TRUE.
Now, since queueRequest fails a request is never queued and pasynManager->portThread's autoConnectDevice is also not reached.
So my question is how to properly configure/trigger an auto connect?
PS.: I found this old thread that might be related:
https://epics.anl.gov/tech-talk/2012/msg01216.php
Thanks!
Bruno