Folks,
I'm having a strange EPICS problem that I can't figure out. This is
EPICS 3.14.6 on Linux.
I have a record that I have written that defines a number of array
fields of different types.
Let's just consider two of the fields, .PARM and .BHIST.
Here is how they are defined in dxpRecord.dbd
field(BHPTR,DBF_NOACCESS) {
prompt("Baseline history buffer pointer")
special(SPC_NOMOD)
interest(4)
size(4)
extra("unsigned long *bhptr")
}
field(BHIST,DBF_ULONG) {
prompt("Baseline History")
asl(ASL0)
special(SPC_DBADDR)
}
field(PPTR,DBF_NOACCESS) {
prompt("Parameter Buffer Pointer")
special(SPC_NOMOD)
interest(4)
size(4)
extra("unsigned short *pptr")
}
field(PARM,DBF_USHORT) {
prompt("DXP Parameters")
asl(ASL0)
special(SPC_DBADDR)
}
So BHIST is DBF_ULONG and will be accessed with BHPTR. PARM is DBF_SHORT
and will be accessed with PPTR.
Here is cvt_dbaddr in the record:
static long cvt_dbaddr(paddr)
struct dbAddr *paddr;
{
struct dxpRecord *pdxp=(struct dxpRecord *)paddr->precord;
MODULE_INFO *minfo = &moduleInfo[pdxp->mtyp];
if (paddr->pfield == &(pdxp->base)) {
paddr->pfield = (void *)(pdxp->bptr);
paddr->no_elements = minfo->nbase_histogram;
paddr->field_type = DBF_ULONG;
paddr->field_size = sizeof(long);
paddr->dbr_field_type = DBF_ULONG;
} else if (paddr->pfield == &(pdxp->parm)) {
paddr->pfield = (void *)(pdxp->pptr);
paddr->no_elements = minfo->nparams;
paddr->field_type = DBF_USHORT;
paddr->field_size = sizeof(short);
paddr->dbr_field_type = DBF_USHORT;
} else if (paddr->pfield == &(pdxp->bhist)) {
paddr->pfield = (void *)(pdxp->bhptr);
paddr->no_elements = minfo->nbase_history;
paddr->field_type = DBF_ULONG;
paddr->field_size = sizeof(long);
paddr->dbr_field_type = DBF_ULONG;
} else if (paddr->pfield == &(pdxp->trace)) {
paddr->pfield = (void *)(pdxp->tptr);
paddr->no_elements = minfo->ntrace;
paddr->field_type = DBF_LONG;
paddr->field_size = sizeof(long);
paddr->dbr_field_type = DBF_LONG;
} else {
Debug(1, "(cvt_dbaddr): field=unknown\n");
}
/* Limit size to 4000 */
if (paddr->no_elements > 4000) paddr->no_elements = 4000;
printf("recDxp:cvt_dbaddr, no_elements=%ld field_type=%d,
dbr_field_type=%d\n",
paddr->no_elements, paddr->field_type, paddr->dbr_field_type);
return(0);
}
So the parm field sets pfield to pptr, field_type to DBF_USHORT. hhist
field sets pfield to bhptr, and field_type to DBF_ULONG. These are both
consistent with the .dbd file.
Note that I print out the values of no_elements, field_type, and
dbr_field_type each time that cvt_dbaddr is called.
Now I start a soft IOC on Linux, and from another Linux terminal session
run the "cainfo" CA client on these fields. cainfo is from base in
3.14.6.
corvette> cainfo dxpLinux:dxp1.PARM
dxpLinux:dxp1.PARM
State: connected
Host: vincent:5064
Access: read, write
Data type: DBR_LONG (native: DBF_LONG)
Element count: 167
When I type that command I immediately get the following from iocsh on
the IOC:
epics> recDxp:cvt_dbaddr, no_elements=167 field_type=4, dbr_field_type=4
recDxp:cvt_dbaddr, no_elements=167 field_type=4, dbr_field_type=4
So the IOC is reporting that it set field_type and dbr_field_type to 4,
which is DBF_USHORT according to dbFldTypes.h. But cainfo is reporting
that the field type is DBR_LONG. Why?
Now do the same thing with the BHIST field.
corvette> cainfo dxpLinux:dxp1.BHIST
dxpLinux:dxp1.BHIST
State: connected
Host: vincent:5064
Access: read, write
Data type: DBR_DOUBLE (native: DBF_DOUBLE)
Element count: 4000
The IOC reports:
epics> recDxp:cvt_dbaddr, no_elements=4000 field_type=6,
dbr_field_type=6
recDxp:cvt_dbaddr, no_elements=4000 field_type=6, dbr_field_type=6
So the IOC is setting the field types to 6, which is DBF_ULONG, as
expected.
But cainfo is reporting that the field type is DBF_DOUBLE. Why?
The problem is not with the cainfo, all channel access clients are
reporting the same thing.
Note that I only noticed this problem because it thinks there is a
double field of length 4000, which does not work with my channel access
clients because it is too long. Other than that, the data for the arrays
is correct, so they are being converted correctly from the values in the
record when CA client receives them.
Can anyone explain what is going on?
Thanks,
Mark
- Replies:
- Re: EPICS problem Andrew Johnson
- Navigate by Date:
- Prev:
Re: Initial value readback from hardware into output records Benjamin Franksen
- Next:
RE: Initial value readback from hardware into output records Ralph Lange
- 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: Initial value readback from hardware into output records Benjamin Franksen
- Next:
Re: EPICS problem 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
|