EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: EPICS problem
From: "Mark Rivers" <[email protected]>
To: "Marty Kraimer" <[email protected]>, <[email protected]>, "Andrew Johnson" <[email protected]>, <[email protected]>
Cc: <[email protected]>
Date: Thu, 9 Dec 2004 01:22:20 -0600
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  <20042005  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  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·