Experimental Physics and
Industrial Control System

"Piccoli, Luciano" <[email protected]> · Tue, 29 Nov 2011 10:02:33 -0800

Hi Mark,

Just one more piece of information.

Here is part of my gdb session with the database using only one record. I had the pao->out printed out before getting into initCommon (called from the initAo function). The type is set to 0 at that point, which will cause the parseLink to fail later. Also in the value union the OUT string is not showing up in the instio field.

	Breakpoint 2, iocInit () at ../iocInit.c:81
	81          return iocBuild() || iocRun();
	(gdb) c
	Continuing.
	[New Thread -1214051424 (LWP 28693)]
	Starting iocInit
	############################################################################
	## EPICS R3.14.10-lcls1 $R3-14-10$ $2008/10/27 19:39:04$
	## EPICS Base built Jul 15 2009
	############################################################################
	[New Thread -1214452832 (LWP 28695)]
	[New Thread -1215247456 (LWP 28697)]
	[New Thread -1216304224 (LWP 28699)]
	[New Thread -1217360992 (LWP 28701)]
	[New Thread -1218417760 (LWP 28703)]

	Breakpoint 3, initAo (pao=0x8ca6668) at ../../asyn/devEpics/devAsynInt32.c:609
	609         status = initCommon((dbCommon *)pao,&pao->out,
	(gdb) p pao
	$4 = (aoRecord *) 0x8ca6668
	(gdb) p pao->out
	$5 = {value = {constantStr = 0x0, macro_link = {macroStr = 0x0}, pv_link = {pvname = 0x0, precord = 0x0, pvt = 0x0, getCvt = 0x8ca6918,
	      pvlMask = 0, lastGetdbrType = 0}, vmeio = {card = 0, signal = 0, parm = 0x0}, camacio = {b = 0, c = 0, n = 0, a = 0, f = 0,
	      parm = 0x8ca6918 "asyn(Mksu 0 1)WF_TRIG_DELAY_WRITE"}, rfio = {branch = 0, cryo = 0, micro = 0, dataset = 0, element = 0,
	      ext = 147482904}, abio = {link = 0, adapter = 0, card = 0, signal = 0, parm = 0x0}, gpibio = {link = 0, addr = 0, parm = 0x0},
	    bitbusio = {link = 0 '\0', node = 0 '\0', port = 0 '\0', signal = 0 '\0', parm = 0x0}, instio = {string = 0x0}, bbgpibio = {
	      link = 0 '\0', bbaddr = 0 '\0', gpibaddr = 0 '\0', pad = 0 '\0', parm = 0x0}, vxiio = {flag = 0, frame = 0, slot = 0, la = 0,
	      signal = 0, parm = 0x8ca6918 "asyn(Mksu 0 1)WF_TRIG_DELAY_WRITE"}}, type = 0}
	(gdb) where
	#0  initAo (pao=0x8ca6668) at ../../asyn/devEpics/devAsynInt32.c:609
	#1  0x0066a075 in init_record (pao=0x8ca6668, pass=1) at ../aoRecord.c:138
	#2  0x00e3014d in initDatabase () at ../iocInit.c:418
	#3  0x00e2f88e in iocBuild () at ../iocInit.c:123
	#4  0x00e2f75f in iocInit () at ../iocInit.c:81
	#5  0x00e3057c in iocInitCallFunc (args=0x8c47520) at ../miscIocRegister.c:25
	#6  0x00e97e02 in iocshBody (pathname=0x0, commandLine=0x0) at ../../../src/libCom/iocsh/iocsh.cpp:743
	#7  0x00e98043 in iocsh (pathname=0x0) at ../../../src/libCom/iocsh/iocsh.cpp:801
	#8  0x0804b0a6 in main (argc=1, argv=0xbfe779e4) at ../exampleMain.cc:25

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System