Hi,
This problem would have easily been caught if the configure/Makefile had the CHECK_RELEASE=YES. It was set to NO in the module I used as a starting point.
Luciano
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Piccoli, Luciano
Sent: Tuesday, November 29, 2011 13:56
To: Mark Rivers; Andrew Johnson; [email protected]
Subject: RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO"
Mistery solved.
With the help of Till Straumann we found that the epics base version used to build asyn and to build my application where different. The epics base version defined a different aoRecord:
(gdb) ptype *pao
type = struct aoRecord {
char name[61];
char desc[29];
char asg[29];
...
(gdb) ptype *pao
type = struct aoRecord {
char name[61];
char desc[41];
char asg[29];
...
This caused the contents of aoRecord to be shifted, making it seems like the link type had changed.
Thank you all for the help.
Luciano
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Piccoli, Luciano
Sent: Tuesday, November 29, 2011 09:52
To: Mark Rivers; Andrew Johnson; [email protected]
Subject: RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO"
I'll definitely try that soon. I started from another asyn example and possibly removed too much code :)
Thanks,
Luciano
-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: Tuesday, November 29, 2011 09:50
To: Piccoli, Luciano; Andrew Johnson; [email protected]
Subject: RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO"
That looks fine.
Did you see if the testAsynPortDriver application is working for you?
Try using that application as the starting point for your application?
If you are still stuck you could tar up your application and I'll try to
build and run it and see if I can see the problem.
Mark
-----Original Message-----
From: Piccoli, Luciano [mailto:[email protected]]
Sent: Tuesday, November 29, 2011 11:27 AM
To: Mark Rivers; Andrew Johnson; [email protected]
Subject: RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO"
Hi Mark,
Here is the grep example.dbd output:
[lpiccoli@cdlx22 initial2]$ grep "device(ao" ./dbd/example.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")
Thanks,
Luciano
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Mark Rivers
Sent: Tuesday, November 29, 2011 08:42
To: Andrew Johnson; [email protected]
Subject: RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO"
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" Andrew Johnson
- 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
- 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" Mark Rivers
- RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
- RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
- Navigate by Date:
- Prev:
RE: EPICS Base 3.14.12.2-rc1 available for testing Jeff Hill
- Next:
Re: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Andrew Johnson
- 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" Piccoli, Luciano
- Next:
Re: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Andrew Johnson
- 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
|