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
<2021>
2022
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
<2021>
2022
2023
2024
|