Hi Andrew and Luciano,
It does not really matter if parseLink or parseLinkMask generates the
error message. The error message clearly indicates that plink->type is
not INST_IO, but it clearly should be. Luciano has also used gdb to
establish that plink->type is 0, which it should not be.
His INP and OUT link syntax look fine to me, so I don't think parseLink
should be returning an error.
This is the start of initCommon:
pPvt = callocMustSucceed(1, sizeof(*pPvt),
"devAsynInt32::initCommon");
pr->dpvt = pPvt;
pPvt->pr = pr;
/* Create asynUser */
pasynUser = pasynManager->createAsynUser(processCallback, 0);
pasynUser->userPvt = pPvt;
pPvt->pasynUser = pasynUser;
pPvt->mutexId = epicsMutexCreate();
/* Parse the link to get addr and port */
/* We accept 2 different link syntax (@asyn(...) and @asynMask(...)
* If parseLink returns an error then try parseLinkMask. */
status = pasynEpicsUtils->parseLink(pasynUser, plink,
&pPvt->portName, &pPvt->addr, &pPvt->userParam);
if (status != asynSuccess) {
status = pasynEpicsUtils->parseLinkMask(pasynUser, plink,
&pPvt->portName, &pPvt->addr, &mask, &pPvt->userParam);
}
if (status != asynSuccess) {
printf("%s devAsynInt32::initCommon %s\n",
pr->name, pasynUser->errorMessage);
goto bad;
}
So the first thing it does is allocate pPvt and assign pr->dpvt to that.
It does that before it tries to parse the link.
That being the case, I don't understand why dbpr is showing the DPVT
field being (nil). It also shows a number of other dbCommon record
fields being (nil): ASP, PBRK, PPN, PPNR, SEVR. Do you understand how
that can happen?
I suspect some problem with the example.dbd file being used.
Luciano, can you execute the following "grep" command on example.dbd.
This is the output I get on the testAsynPortDriver.dbd file. You will
see that there are 5 device support entries for the ao record.
>grep "device(ao" testAsynPortDriver.dbd
device(ao,CONSTANT,devAoSoft,"Soft Channel")
device(ao,CONSTANT,devAoSoftRaw,"Raw Soft Channel")
device(ao,CONSTANT,devAoSoftCallback,"Async Soft Channel")
device(ao,INST_IO,asynAoInt32,"asynInt32")
device(ao,INST_IO,asynAoFloat64,"asynFloat64")
Mark
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Andrew Johnson
Sent: Tuesday, November 29, 2011 10:18 AM
To: [email protected]
Subject: Re: Asyn: "devAsynInt32::initCommon Link must be INST_IO"
Hi Luciano & Mark,
On 2011-11-29 Piccoli, Luciano wrote:
>
> Here is the output and the dbpr's.
> [lpiccoli@cdlx22 iocMksu]$ ./st.cmd
> #! ../../bin/linux-x86/example
> dbLoadDatabase("../../dbd/example.dbd")
> #dbLoadDatabase("HMSApp.dbd")
> example_registerRecordDeviceDriver(pdbbase)
> # Registering MKSU iocsh() functions
> drvMksu_init()
> # Registering MKSU iocsh() functions
> drvAsynIPPortConfigure("MksuServer", "194.168.0.21:56789 UDP", 0, 0,
1)
> initMksu("Mksu", "MksuServer")
> # Creating MKSU object
> asynSetTraceIOMask("MksuServer",0,4)
> asynSetTraceMask("MksuServer",0,255)
> dbLoadTemplate("mksu.substitutions")
> #dbLoadRecords("mksu.db")
> iocInit()
> Starting iocInit
>
########################################################################
###
> # ## EPICS R3.14.10-lcls1 $R3-14-10$ $2008/10/27 19:39:04$
> ## EPICS Base built Jul 15 2009
>
########################################################################
###
> KLYS:IN20:3130:MOD_TRIG_DELAY_READ devAsynInt32::initCommon Link must
be
> INST_IO
> KLYS:IN20:3130:WF_TRIG_DELAY_READ devAsynInt32::initCommon Link must
be
> INST_IO
> KLYS:IN20:3130:MOD_TRIG_DELAY_WRITE devAsynInt32::initCommon Link
must be
> INST_IO
> KLYS:IN20:3130:WF_TRIG_DELAY_WRITE devAsynInt32::initCommon Link must
be
> INST_IO
> iocRun: All initialization complete
Those error messages are printed by the initCommon() routine in
$(ASYN)/asyn/devEpics/devAsynInt32.c but most of the error string comes
from
from the parseLinkMask() routine in asynEpicsUtils.c. However the code
in
initCommon() calls the latter if it first gets an error from the call to
the
parseLink() routine, and unfortunately this results in the error message
from
the first call being overwritten.
I wonder if what's happening here is that the parseLink() routine is
returning
an error of some kind (there are lots of "goto error" statements in the
case
INST_IO: section), but the error reporting code is not telling us what
the
actual problem is, and instead is giving us a secondary error. That
looks to
me like a shortcoming of the code in initCommon().
- Andrew
--
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham
- Replies:
- RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
- RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
- References:
- Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
- RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Mark Rivers
- RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
- Re: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Andrew Johnson
- Navigate by Date:
- Prev:
Re: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Andrew Johnson
- Next:
Micro Research cPCI EVG support (request) Michael Davidsaver
- 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:
Re: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Andrew Johnson
- Next:
RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
- 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
|