EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20212022  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  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Modbus & asynManager::queueLockPort queueRequest failed: port not connected
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: Keara Louise Soloway <kls286 at cornell.edu>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Fri, 4 Jun 2021 13:20:46 +0000
Hi Keara,


Sorry for not answering sooner.


This problem sounds like asyn has sometimes not yet connected to the PLC on port IP_PORT when it tries to do the first I/O operations.  That it unusual, normally socket connections on the local LAN are fast.


This is from the asyn documentation about the initial connection: https://epics-modules.github.io/master/asyn/R4-42/asynDriver.html#Overview_asynManager


  *   When the port registers its asynCommon interface, asynManager queues a connection request. It then waits for a short time for the connection callback to complete. The default time is 0.5 seconds, but this time can be changed with a call to the function pasynManager->setAutoConnectTimeout(double timeout). This function can be accessed from the iocsh shell with the asynSetAutoConnectTimeout(double timeout) command. This short timeout is designed to allow devices time to connect if they are available, but not to excessively slow down booting of the IOC by waiting, for example, for the system timeout on TCP connections. Note that this means that it is very likely that the pasynCommon->connect() call will occur as soon as the asynCommon interface is registered, which means that the driver must have already done all initialization required for the asynCommon->connect() callback before it registers the asynCommon interface. If the port does not connect initially, or if it subsequently disconnects, then asynManager will queue a connection request every 20 seconds. If autoConnect is true and port/device is enabled but the device is not connected, then queueManager calls calling asynCommon:connect just before it calls processCallback.

So by default it waits 0.5 seconds for the socket to initially connect.


There are 2 things you could try to fix the problem.


Before the call to drvAsynIPPortConfigure add this line:


asynSetAutoConnectTimeout(2.0)


Or right after the call to drvAsynIPPortConfigure add this line:


asynWaitConnect("IP_PORT", 2.0)


You could change the 2.0 second values above to the ones that result in reliable startup.


Mark



________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Keara Louise Soloway via Tech-talk <tech-talk at aps.anl.gov>
Sent: Thursday, May 20, 2021 3:40 PM
To: tech-talk at aps.anl.gov
Subject: Modbus & asynManager::queueLockPort queueRequest failed: port not connected

Greetings all,

I am having problems communicating with an Automation Direct BRX PLC. The problems are not consistently reproducible -- IOC starts without any error at all about 1 in 5 times. The errors only happen when starting the IOC, never when it's already running normally.

The IOC application uses:
EPICS base 7.0.2
alive R1-1-1
asyn R4-40
calc R3-7-3
modbus R3-0
sscan R2-11-3

Here are the errors and some context from the ioc shell:
## Register all support components
dbLoadDatabase("../../dbd/heatedprintbed.dbd")
heatedprintbed_registerRecordDeviceDriver(pdbbase)
< errordemo.cmd
drvAsynIPPortConfigure("IP_PORT", "192.168.182.136:502",0,0,1)
modbusInterposeConfig("IP_PORT",0,5000,0)
drvModbusAsynConfigure("MI_READ", "IP_PORT", 255, 2, 549, 11, 0, 250, "BRX")
drvModbusAsynConfigure("MC_READ",  "IP_PORT", 255, 1, 1999, 5, 0, 250, "BRX")
drvModbusAsynConfigure("MC_WRITE", "IP_PORT", 255, 5, 1999, 5, 0, 250, "BRX")
2021/05/20 15:58:50.578 drvModbusAsyn::doModbusIO port MC_WRITE error calling writeRead, error=asynManager::queueLockPort queueRequest failed: port IP_PORT not connected, nwrite=0/6, nread=0
## Load record instances
dbLoadTemplate("../../db/errordemo.substitutions")
iocInit
Starting iocInit
############################################################################
## EPICS R7.0.2
## EPICS Base built Apr  5 2019
############################################################################
2021/05/20 15:58:50.828 drvModbusAsyn::doModbusIO port MI_READ error calling writeRead, error=asynManager::queueLockPort queueRequest failed: port IP_PORT not connected, nwrite=0/6, nread=0
2021/05/20 15:58:50.828 drvModbusAsyn::doModbusIO port MC_READ error calling writeRead, error=asynManager::queueLockPort queueRequest failed: port IP_PORT not connected, nwrite=0/6, nread=0
iocRun: All initialization complete
## Start any sequence programs
#seq sncxxx,"user=kls286"
epics> 2021/05/20 16:01:25.169 drvModbusAsyn::doModbusIO port MI_READ writeRead status back to normal having had 124 errors, nwrite=6/6, nread=4
2021/05/20 16:01:25.175 drvModbusAsyn::doModbusIO port MC_READ writeRead status back to normal having had 124 errors, nwrite=6/6, nread=3

After a few minutes (variable, but usually less than 10), all of the read-only modbus ports put out a "back to normal" message like the one above. The claim of "back to normal" does indeed seem to be true -- all PVs reading from these ports do so as intended.
The write-only modbus ports also go back to normal as soon as I do a dbpf to any of the PVs that will write to the port. Like so:

epics> dbpf demoButton:write 1
DBF_STRING:         "Pushed"
epics> 2021/05/20 16:04:37.323 drvModbusAsyn::doModbusIO port MC_WRITE writeRead status back to normal having had 1 errors, nwrite=6/6, nread=5

Let me know if I can provide any additional details.

Thanks,
K. Soloway


References:
Modbus & asynManager::queueLockPort queueRequest failed: port not connected Keara Louise Soloway via Tech-talk

Navigate by Date:
Prev: Re: arv-tool-0.8 with FLIR-Blackfly camera Mark Rivers via Tech-talk
Next: Re: caRepeater w/ systemd? Ernesto Paiser via Tech-talk
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  <20212022  2023  2024 
Navigate by Thread:
Prev: Modbus & asynManager::queueLockPort queueRequest failed: port not connected Keara Louise Soloway via Tech-talk
Next: SNMP in EPICS Tomasz Brys via Tech-talk
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  <20212022  2023  2024 
ANJ, 04 Jun 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·